Why I Moved House Rules Out of MEMORY — How rules and MEMORY.md Actually Differ
Prologue
Most Chinese-language tutorials on Claude setup will cover this comparison:
CLAUDE.md vs CLAUDE.local.md
The former is for team-shared settings, the latter for personal preferences. Clean, easy to grasp, and intuitive given how Git's "shared vs local" pattern works.
But Cowork (and newer Claude Code) has another comparison that's worth more attention, and almost nobody in the Chinese-language space writes about it:
MEMORY.md vs .claude/rules/*.md
Both auto-load on session start, both appear in the context window every time. They look like similar features, and getting one in the wrong place seems harmless.
But they're fundamentally different in nature. Mixing them creates trouble. This piece is about why I moved the "household rules" out of MEMORY.md and into .claude/rules/.
Two auto-load mechanisms
MEMORY.md (auto-memory)
- Written and maintained by Claude itself
- Content nature: accumulated learning — what was done each session, what trap got stepped on, new preferences, new decisions
- Changes (every session may append)
- Has a size cap: 25 KB / 200 lines, silent truncate (anything over gets quietly cut, no UI warning)
- Needs a prune rule, since it grows
.claude/rules/*.md
- Written and maintained by you (the user)
- Content nature: stable conventions — who you are, how to talk to me, what procedures the household has
- Rarely changes (write once, leave it for a long time)
- No size cap
- No prune needed
Both auto-load into context on session start — from Claude's side, it reads them as one combined block; but from a maintainer's side, they're two different kinds of files.
Looks similar, mixing them hurts
In RTbase's early weeks, everything was stuffed into a single MEMORY.md. Including:
- Work milestones / handoffs (accumulated learning — belongs in MEMORY)
- Who's who in the household (identity — actually belongs in rules)
- How I want Claude to talk to me (register — actually belongs in rules)
- Entry procedures / end-of-session SOP (procedure — actually belongs in rules)
- Writing conventions (publishing standards — actually belongs in rules)
The first few weeks were fine. Then on 2026-06-08, MEMORY.md hit 24.4 KB — 600 bytes from the 25 KB cap. Claude started dropping entries on session start. Not all of them, just the last few, silently truncated, no warning at all.
First reaction: prune. But pruning ran into a thorny question:
What can actually be pruned?
Old work milestones can be archived, handoff summaries can be compressed — those are "accumulated learning" and naturally decay anyway.
But "who's who at home," "how to talk to me," "what to read on entry" — those don't decay, they're always valid, they shouldn't be pruned. Yet they were eating the cap, getting squeezed alongside work entries.
The result: the cap was pushing me to prune things I shouldn't prune.
The fix isn't pruning harder. It's moving. Separate things of different nature into different places.
Why split, four engineering reasons
Moving the household rules out of MEMORY and into .claude/rules/ has four engineering reasons:
1. Different size caps
MEMORY.md silent-truncates at 25 KB. .claude/rules/ has no cap. Stable things go in rules; MEMORY's cap is reserved for actually-changing working memory.
2. Different prune logic
MEMORY needs pruning (grows, needs to decay old data). rules shouldn't be pruned (the whole point is stability). Mixed together, when you write a prune script you'd hesitate: is this accumulated learning, or is this identity? Separated, prune only needs to care about MEMORY.
3. Different authors
MEMORY gets appended by Claude itself (it writes its own learning). rules are written by you (you define the household's conventions). If both live in MEMORY, Claude ends up modifying user-defined household rules inside its own learning file — you could frame it as a prompt-injection risk if you want, but more practically: you and Claude editing in the same file blurs the boundary.
4. Splittability
MEMORY.md is a single file (auto-memory system limitation). .claude/rules/ is a directory and can hold multiple files. Splitting household rules across different aspects — persona.md / voice.md / sop.md (covered in the previous topic) — isn't possible inside MEMORY.
A common trap: new rules default to the wrong layer
Another piece in this workshop covers this too; here's another angle:
Claude writing to MEMORY is the default behavior. You writing to rules is an explicit action.
When you tell Claude "don't respond to me like that anymore," Claude defaults to appending that line to MEMORY.md (it appends to its own learning file). But that line actually belongs in voice.md (it's a stable register convention).
If you don't catch this actively, all register rules quietly accumulate in MEMORY, eat the cap, and when you go to prune later, you'll find yourself wondering "huh, why is this rule in MEMORY?"
Countermeasure: when you notice Claude putting a voice rule into MEMORY mid-conversation, correct it on the spot: "move this to voice.md, don't put it in MEMORY."
My .claude/rules/sop.md has a rule that handles exactly this — "new rule needs to go in which file? Here's the decision flow." Made explicit for Claude to see, so it doesn't silently default to the wrong layer.
The other side, after moving
After moving the household rules into .claude/rules/, two effects I didn't anticipate:
1. MEMORY actually looks like "work notes" now
Before, MEMORY on session start read like a hybrid of résumé + work log + household rules + personal notes mixed together. Claude had to spend attention figuring out "what should I align to right now."
After the move, MEMORY only has work accumulation — on session start it reads as "where I left off, what baggage I'm carrying forward." Much cleaner.
2. rules become something you can show someone else
Once moved out, household rules become a standalone directory — you can inspect them, grep them, diff them.
When you want to ask "how is our household interacting with Claude?", there's something to point at — not "scattered across MEMORY" but "the four files in .claude/rules/."
A side benefit: thinking clearly about "what do our household rules look like" also gets easier. While it was all one file, I never managed to articulate "the household rules" as a thing — they were tangled with work notes. Once split out, they became a shape.
You don't have to split
If your MEMORY hasn't hit the 25 KB cap and Claude isn't dropping entries, split-or-not doesn't matter much.
But if you see any of these signals:
- MEMORY past 20 KB (less than 5 KB from cap)
- You want to prune but find "identity / household rules" tangled with "work accumulation" — hard to start
- Claude writes user voice rules into MEMORY (things that should be in rules ending up in the wrong layer)
Consider splitting.
How to decide what moves: take a "household rule" or "identity rule" and ask "will this change as work progresses?" No → move to rules. Yes → keep in MEMORY.
One line
MEMORY is the work notebook. rules is the household's way of doing things.
Existing Chinese-language tutorials cover the former pair (CLAUDE.md vs CLAUDE.local.md) extensively. The latter (MEMORY vs rules division) is barely written about. The first pair manages "who maintains it"; the second pair manages "what nature it is" — two different concerns.
Claude (spring 2026) · session 81e1a3cd-6161-48f4-b17b-20777f3b6ea4 · 2026-06-09