This guide distills the Anthropic blog post The new rules of context engineering for Claude 5 generation models (2026-07-24).
What changed
Context engineering used to mean instructing more precisely and more often. Don’t write comments. Document it this way. Call the tools in this order. When the model slipped, you added another rule.
With Claude 5 generation models, that backfires. 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 our coding evaluations.” The reason is simple: overconstrained instructions frequently conflict with what the user actually wants, and the model burns resources resolving the conflict.
The post frames the old state plainly — “we were overconstraining Claude Code, both through our system prompt and in our CLAUDE.md files and skills.” A rule like “default to writing no comments. Never write multi-paragraph docstrings” is simply wrong for a subset of prompts. Meanwhile the user asks Claude to “leave documentation as appropriate.” The model is left arbitrating between the two.
The six shifts
The heart of the post is six then-versus-now pairs. Compressed:
| Area | Then | Now |
|---|---|---|
| Instructions | Rigid rules | Model judgment |
| Tool use | Lots of examples | Interfaces with expressive parameters |
| Information | Everything upfront in the system prompt | Progressive disclosure, loaded when needed |
| Repetition | Same instruction in prompt and tool description | Tool instructions only in tool descriptions |
| Memory | Users save with the # hotkey | Claude saves relevant memories automatically |
| References | Simple markdown plans | Code references, test suites, HTML artifacts |
All six collapse into one idea: stop writing down what not to do, and instead leave good material for the model to judge with.
Three things to do today
1. Cut your CLAUDE.md down.
“Keep your CLAUDE.md lightweight and briefly describe what your repo is for, but spend most of the tokens on gotchas inside of the codebase.” Gotchas are the things reading the code won’t reveal — this function touches a cache, so reset it before tests; the billing module is legacy, so don’t apply the new pattern there; builds have to run from web/. Drop directory listings and file structure — “avoid stating ‘the obvious’ things Claude should know by looking at your file system or your repo.”
2. Split your skills. “Think of skills as lightweight guides to let Claude find information when needed. Avoid making them overconstrained, except in highly important areas.” For long skills, “use progressive disclosure as much as possible — divide it into many files and split them out.”
3. Say it once. Keep tool instructions in tool descriptions. When the same directive is scattered across the system prompt, CLAUDE.md, and skills, they drift apart and the model spends its turn arbitrating.
The system prompt is where the product lives
The post separates the layers clearly. “A system prompt is heavily tied to the product context. It tells Claude what product it’s operating in and what it’s doing.” If you use Claude Code, “you will likely never modify this, but if you are building your own agent harness, this is where you should spend a lot of time.”
Next steps
Open your current CLAUDE.md and strike out everything Claude could learn by reading the repo itself — usually about half of it goes. According to the blog, these best practices ship inside claude doctor, so you can run /doctor in Claude Code to rightsize your skills and CLAUDE.md files.
For the writing principles themselves, see CLAUDE.md best practices; for splitting skills, see Build your own skill. The full post is on the Anthropic blog.