Context Engineering for Claude 5 — What to Delete from Your CLAUDE.md

What context engineering actually is

Start with the terms. The prompt is the one line you just typed. The context is everything that rides along with that line when it reaches the model — assembled from the system prompt, CLAUDE.md files, skills, memory and other sources, with your prompt as the very last line of the bundle.

The original puts it precisely: when you send a message, the prompt is only a small part of the context the model gets. Designing that bundle is context engineering, and it moves the quality of the result a great deal.

By analogy, the prompt is today's assignment handed to a new hire; the context is the entire manual that hire is carrying. However clear the assignment, a messy manual produces messy work.

And the manual has an expiry date, because last year's model and today's model are not the same. Hand a new-hire manual to a ten-year veteran and it does not help — it gets in the way. That is exactly the point of this announcement.

What changed, and by how much

Anthropic removed over 80% of Claude Code's system prompt for models like Claude Opus 5 and Claude Fable 5, with no measurable loss on their coding evaluations. That is the opening paragraph of the original, verbatim in substance.

The name they gave it is "Unhobbling Claude" — a self-diagnosis that they had been overconstraining Claude Code in three places: the system prompt, CLAUDE.md files, and skills.

Six pairs changed. The original lays them out side by side as "Then" and "Now."

Rule one — stop giving rules, let it judge

The old system prompt contained this: "In code: default to writing no comments. Never write multi-paragraph docstrings or multi-line comment blocks — one short line max."

The trouble is that such a rule is not always right. Genuinely complex code sometimes needs a long comment, and a never clause means the model cannot write one even when it should. The older model lacked judgment, so the side effect was worth the constraint.

What remains now is one line: "Write code that reads like the surrounding code: match its comment density, naming, and idiom." Ten lines of prohibition became one line of standard.

Open your own CLAUDE.md. There will be several sentences ending in never do this. A few months ago that was the recommended practice. Much of it is now better deleted.

Rule two — design interfaces instead of examples

The old orthodoxy for building tools was to attach plenty of usage examples: use it this way in this situation, that way in that one.

With the newest models, examples fence the model in instead. The original says giving examples actually constrains the model to a certain exploration space. What was meant as a reference becomes a boundary.

So the new approach is to say less and let the tool speak for itself. The original's example is a todo tool: define status as an enumeration of pending, in_progress and completed, and that alone hints at how the tool is used. Add one line about keeping a single item in_progress and the desired behaviour is defined too.

A well-made door handle tells you whether to push or pull without a manual. Spend the time you would have spent on the manual making a better handle.

Rule three — don't front-load it, let it fetch

This is progressive disclosure: loading the right context at the right time.

Claude Code itself changed this way. Code review and verification — not always needed, but crucial when they are — moved out of the system prompt and into their own skills. Tools followed: some are deferred loading, meaning the agent must find their full definitions through ToolSearch before use. That lets the product carry more tools without spending context on them until they are needed.

CLAUDE.md gets the same treatment: a reception desk rather than a warehouse. Say briefly what the repo is for, then point — verification is in this file, deployment in that one. Split the detail into separate files or skills and open them only for that work.

So what stays in CLAUDE.md? The original says spend most of your tokens on gotchas. For instance, this repo keeps all types in one monolithic file and nowhere else. Conversely, avoid stating the obvious things Claude can see by looking at your file system.

Rules four and five — stop repeating, let memory run itself

Older models forgot the start of a long conversation, so repeating important instructions was orthodoxy — and Anthropic itself had the same tool instructions in two places, the system prompt and the tool description.

The newest models get it after being told once. So the duplicates went, and tool instructions live only in the tool description. Your CLAUDE.md almost certainly repeats a rule two or three times; deleting the copies saves tokens and improves results.

Memory takes less handwork too. You used to save things yourself — a line starting with # in the chat wrote straight into CLAUDE.md. Now Claude saves what is relevant to the work and to you on its own.

Automatic does not mean explicit is pointless, though. For the things that genuinely must persist, telling it clearly to remember is still the surer path.

Rule six — hand over deeper material than markdown

Plans, specs and design docs have been written in markdown by default because it is light and simple.

But the newest models handle far richer references, so there is no reason to blur the information on the way in. The original recommends preferring files that are code, because that is a language the model knows very well and the instruction lands clearly.

Concretely: instead of writing "the button is blue with rounded corners" in markdown, hand over an HTML mockup. A spec can be a detailed test suite — nothing states a requirement more clearly than make this pass. A function in another codebase that Claude should port is also a spec.

Rubrics are another form of reference. Give a scoring table for what good API design looks like and Claude can spin up verifier agents that score its own output against it. Rather than describing your taste, you hand over the scorecard.

So how do I rearrange my own files

The original closes by splitting this into four seats, each with a different job.

The system prompt is heavily tied to product context: it tells Claude what product it is operating in and what it is doing. As a Claude Code user you will likely never touch it; if you are building your own agent harness, that is where to spend real time.

Keep CLAUDE.md lightweight. Say briefly what the repo is for and spend most of the tokens on gotchas. If verification is complicated, make a verification skill and have CLAUDE.md merely reference it.

Treat skills as lightweight guides that let Claude find information when needed. Avoid overconstraining them except in highly important areas, and split long ones across files. Skills pay off most when they encode opinions and know-how particular to you, your team or your product.

References are files you @ mention — spec files, mockups, even entire codebases. Prefer files that are code.

You do not have to fix it all by hand

After reading this you will wonder where to start on your own files. Anthropic put the best practices into the tool.

Update Claude Code and run /doctor. It rightsizes your skills and CLAUDE.md files against these rules — rightsize being the original's word.

Six lines, then. Cut rules and leave judgment. Design interfaces instead of examples. Don't front-load; let it fetch. Don't repeat yourself. Let memory run itself. Hand over code, HTML and tests rather than markdown.

One message runs through all of it: the model became a senior while we were still handing it the new-hire manual. The thing to do today is open CLAUDE.md and delete the never-do-this lines and the duplicated paragraphs. Then run /doctor.