3.4
CONTEXT.md — The Rooms
Why this exists
Your map is short because you kept it short. But all the detail you cut has to live somewhere, or you're back to explaining it every session.
This is where it goes. And the reason this layer exists at all — rather than one big file — is the thing that makes the whole structure worth building.
The idea
One file per room, read only when you're in that room.
A CONTEXT.md sits inside a workspace folder and describes that kind of work: what happens here, how it's done, what finished looks like. Claude reads it when the routing table sends it there, and not otherwise.
That last clause is the entire point. Your writing context doesn't load when you're building. Your build context doesn't load when you're writing. Everything you know stays available; almost none of it is in the room at once.
Compare the two ways of doing it:
| Everything in CLAUDE.md | Split into rooms | |
|---|---|---|
| What Claude knows | All of it | All of it |
| What loads per session | All of it | The map, plus one room |
| Cost of adding detail | Every session gets heavier | Only that room gets heavier |
| Answers as project grows | Gradually worse | Unchanged |
Same knowledge, different loading. That third row is the one that matters long-term: with rooms, you can be as detailed as you like about a kind of work without taxing every other kind of work.
What goes in one:
- What this workspace is for. One or two sentences.
- The process. How this kind of work actually gets done here, in order.
- What's in this folder and what belongs where.
- What good output looks like. Standards, format, tone, the things you'd otherwise say every time.
And the ratio to hold onto: roughly 80% about the work, at most 20% about how Claude should behave. The instinct is to write behavioural rules — be concise, don't do this. Resist it. Describing the work well is what produces good behaviour; a pile of rules about tone is what you write when you haven't described the work well enough.
The other thing to get right is what deserves a room. The test from 3.1 still holds: if you think differently between two kinds of task, they're two rooms. A room is a mental mode, not a folder you happen to have. Two rooms with near-identical contexts should be one room. A room you haven't opened in a month probably shouldn't exist.
Start with two. Add a third when a real piece of work proves it needs one.
Do
Use the project from 3.2 and the rooms from your routing table.
- Pick your two most different kinds of work. Only two.
- Make a folder for each, matching the names in your routing table exactly.
- In each, write a
CONTEXT.mdwith four things: what this workspace is for, the process, what's in the folder, and what good output looks like. - Check your ratio. Roughly how much is about the work versus about Claude's behaviour? If behaviour is more than a fifth of it, cut it back and describe the work better.
- Now prove it loads correctly:
- Fresh session, run
/context, note the number. - Ask something that routes to room one. Run/contextagain. Note it. -/clear. Ask something that routes to room two. Run/context. - Confirm room one's context is not loaded in that third session. - Write the three numbers into
rooms.md, and one line on what you'd expect if all this had gone inCLAUDE.mdinstead.
Step 5 is the lesson. Everyone believes "it only loads what it needs" when they read it, and nobody quite trusts it until they've watched the number stay low.
Done when
Never do
Don't write a CONTEXT.md about Claude instead of about the work. It's the most common failure in this whole level and it produces files full of instructions that don't help, in place of a description that would have.
Don't start with more than two rooms. Every first structure has seven and four of them are dead within a month. A room earns its existence by being used.