Build Yours, And The Seven Mistakes

Time: 30 minutes
You'll end up with: Your structure, audited against seven known failures

Why this exists

You've got the pieces. This lesson is where they become one working thing, and where you check it against the seven ways this goes wrong — all of which are silent, all of which cost you months before you notice.

Reading the list isn't the point. Auditing your own structure against it is.

The idea

Every one of these fails quietly. That's what makes the list worth having.

None of them throw an error. Your setup keeps working, slightly worse, for as long as you leave it.

#	Mistake	What it looks like	Fix
1	CLAUDE.md too long	Over one screen	Move room detail into `CONTEXT.md`
2	No routing table	Claude reads everything, or guesses	Add the table
3	Too many rooms	Seven workspaces, four unused	Merge back to two or three
4	Context describes Claude, not the work	Full of "be concise", thin on what the project is	Flip the ratio to 80/20
5	Never updated	Points at folders that were renamed	Edit it when the project changes
6	One flat folder	10+ files at one level	Add subfolders
7	Built it all before using it	An afternoon of design, unused a month later	Build the minimum, correct it with real work

Two are worth expanding, because they're the ones people argue with.

Number 5 is the most expensive. A stale structure is worse than none, because Claude follows it confidently. No structure means it explores and tells you what it found. A wrong map means it goes to the wrong place and reports back as though it were right. The failure is invisible precisely because the setup is doing its job — it's just doing it against a description of a project you no longer have.

Number 7 is the most tempting. Structure is enjoyable to design and it feels like progress. But the version you invent on paper is a guess about work you haven't done yet, and guesses get abandoned. Your first structure should take fifteen minutes. It should be visibly incomplete. It gets corrected by the first fortnight of using it, and that corrected version is the one that survives — because every part of it exists for a reason you actually encountered.

The habit that prevents most of this: when the project changes, the structure changes in the same sitting. Not later, not on a tidy-up day. A rename that doesn't reach the routing table is a bug you've planted for yourself with a two-month fuse.

Do

Audit your own structure. Be honest — nobody's watching.

Open your project and go through all seven. For each, write pass or fail in a file called audit.md, with one line of evidence. - Does CLAUDE.md fit on one screen? - Is there a routing table? - How many rooms, and when did you last open each? - What's the work-to-behaviour ratio in each CONTEXT.md? - Does every folder in the routing table exist, spelled right? - Any folder with more than ten files at one level? - Did you build more than you've used?
Fix everything that failed. Now, not later.
Re-run the 3.2 test: fresh session, ask what am I working on, and where would you put a new draft? Confirm the answer is right.
Re-run the 3.4 test: confirm each room's context loads only in that room.
Add one line at the bottom of audit.md: what will you check, and when? Pick a real trigger — "whenever I rename a folder" beats "monthly".

Step 5 is the one that keeps this alive. Everything in this level decays, and it decays silently. A trigger you'll actually notice is worth more than a schedule you'll ignore.

Done when

audit.md has all seven checked with evidence.
Everything that failed is fixed.
The 3.2 map test passes.
The 3.4 room-loading test passes.
You've written a re-check trigger tied to an event, not a date.

That's Level 3. Next week you learn to undo things — and then, and only then, you build something real.

Never do

Never rename a folder without fixing the routing table in the same sitting. This is mistake 5, and it's the one that will actually get you, because it's the one that arrives disguised as a small tidy-up.