How to Rebuild Your CLAUDE.md for Claude Opus 5 and Fable 5

Anthropic's Claude Code team stripped over 80% out of their own system prompt for Opus 5 and Fable 5. Measured the coding evals before and after. No measurable loss.

Same team that wrote it, tested it for two years. If they had that much dead weight, most CLAUDE.md files built by individual developers have more.

The cause was contradiction. "Leave documentation as appropriate" sitting next to "do not add comments," both live in the same context window, both technically instructions the model is supposed to follow. Claude untangles it, most of the time. But that's effort spent on your file instead of your task.

Six use cases below. Each one is something to go do this afternoon, not a principle to nod along with and forget by tomorrow.

Open your current file. Every "never," "always," "default to" is a candidate. Anthropic's own old line:

Wrong the instant someone actually wants documentation, or a piece of logic is genuinely tangled enough to need real explanation. It existed because older models needed a hard floor - without it they'd get the call wrong too often to risk leaving open. Opus 5 and Fable 5 don't fail that way as much anymore, so the rule now blocks more good outcomes than it prevents bad ones. Here's the replacement:

One sentence instead of a list of exceptions. Trusts the model to look at the file it's actually editing and match what's already there, rather than apply a rule that's right in some files and wrong in others.

Template that comes out of this:

Most rewrites land somewhere between a third and a tenth of the original length. Nobody's file needs to be zero lines. It needs to stop repeating itself.

Code review, testing, deployment - if all three live in one file and load into every session regardless of what the task actually is, that's the shape to fix.

A bug fix never touches deployment-verification.md. A PR review never loads test-writing.md unless it's actually running tests. The model reasons over less at any given moment, and what it does reason over is relevant to the thing in front of it.

This gets worse the bigger the project gets. A CLAUDE.md that made sense at 2,000 lines becomes a mess at 20,000, because the file keeps growing while any single task only ever touches a slice of what's in it.

Split early and the structure scales alongside the codebase. Wait, and you end up rewriting the whole thing later anyway, except now there's three times as much to untangle.

There's a naming instinct worth resisting here too. People tend to name skill files after the tool underneath instead of the job being done, pytest.md instead of test-writing.md. Name them for the task.

Tools change, the job usually doesn't, and Claude matches intent to filename more reliably when the name describes what's happening rather than what's running it.

The old move was showing Claude examples of how to use a tool. Turns out examples narrow what it explores rather than expand it - it pattern-matches to the example even in cases where a different approach would've served the task better.

The fix isn't dropping the guidance. It's moving it into the tool's own shape. A status field defined as a plain string invites guessing, Claude has to infer valid values from context.

The same field as an enum, pending, in_progress, completed, teaches correct usage on its own. Nobody has to explain it. Add one line on top, "keep exactly one item in_progress at a time," and the behavior is fully specified. No example anywhere in sight.

If you're building tools for your own agent, this is the real question worth asking: are you explaining the tool with prose and examples, or does the structure teach the usage by itself? A well-built interface needs fewer words around it, not more.

The # hotkey used to be how you told Claude to remember something across sessions. That habit isn't broken now, it's just redundant. Opus 5 and Fable 5 pull what's relevant from the work itself and save it without being asked.

Run a session without touching the hotkey once. Afterward, check Settings, then Memory. Most of what you used to save by hand is already sitting there.

If something's missing, that's a different signal than it looks like. It doesn't mean going back to manual saves. It means that fact probably belongs in CLAUDE.md as a stated gotcha - something Claude should know as baseline about the project, not something it has to notice mid-session and decide is worth keeping.

Quality calls are the hardest thing to write down accurately. "Make the API feel clean" means something different to everyone who reads it, and it means nothing checkable to a model trying to verify its own output against it.

Four lines, each one either true or false about whatever Claude just built. It checks its own work against a list like this before handing anything back to you. It can't check its work against an adjective, there's nothing there to test.

The same idea travels past API design. Anywhere you'd normally describe "good" in a sentence, try turning it into four or five specific, checkable lines instead. It holds up in practice better than the sentence ever did, and it stops the slow drift where everyone's idea of "clean" quietly diverges over a few weeks of work.

Writing the first rubric is the hard part. You'll probably get the first draft wrong, too vague in one line, too specific in another.

That's fine. Run it for a week, notice which line Claude keeps satisfying technically while missing the point, and rewrite that one line. The rubric gets sharper the same way the CLAUDE.md does, through actual use, not through getting it right on paper the first time.

Once the five use cases above are done, run this:

Anthropic built it specifically for this kind of cleanup. It reads through your CLAUDE.md and skill files and flags what's still oversized, redundant, or written as a rigid rule where a lighter principle would do the same job.

Run it once right after the rebuild. Run it again whenever the file starts growing back, which it will, files always do. Not on a schedule. Just when it happens.

The file you had before this was probably built for a model that needed every instruction spelled out in advance, on the off chance any part of it ended up mattering on some future task. Opus 5 and Fable 5 don't need that anymore.

They need to know what the project actually is, what's genuinely non-obvious about it, and where to look when a specific task calls for something specific.

That's a much shorter list than most people are currently maintaining, and shorter tends to win.

If this changes how you think about your CLAUDE.md, send it to one person still stacking rules on top of rules in a file that's fighting itself.

That's all I'm asking.

Become a paying subscriber to get access to this post and all other premium content.