Anthropic removed more than 80% of Claude Code’s system prompt for its newest models, Claude Opus 5 and Claude Fable 5, and reports no measurable loss on its coding evaluations. Context engineering for Claude 5 differs from the prompting habits most developers have built over the past two years. Strict rules, worked examples, repeated instructions and an overloaded CLAUDE.md file used to be best practice. For this generation of models they mostly get in the way.
Anthropic technical staff member Thariq Shihipar recently laid out the new rules behind this change, together with a new claude doctor command that helps you rightsize your own setup. The lessons apply to Claude Code users and to anyone building their own agents.
What context engineering means
When you send a message to Claude, your prompt is only a small part of what the model sees. The rest is assembled from the system prompt, skills, CLAUDE.md files, memory and other sources. That assembly work is context engineering, and it has a large impact on the results you get, whether you use Claude Code or build your own agent harness.
Unlike a prompt, context is reused across many requests, so it cannot be as specific. You are writing general guidance without knowing what any given user will ask. That is surprisingly hard to do well, and it gets harder as models improve, because guidance written for an older model’s weaknesses becomes dead weight for a newer one.
Why Anthropic removed 80% of the system prompt
When Anthropic read transcripts of its own internal Claude Code usage, it found conflicting instructions stacked inside single requests. One layer said “leave documentation as appropriate” while another said “DO NOT add comments”. Claude can usually interpret the user’s intent and reach the right answer, but it has to spend extra attention untangling the contradictions first.
Many of those constraints existed for a reason. Early models needed strong guardrails to avoid worst case scenarios like deleting files, and some incorrect output was simply the accepted tradeoff. Newer models have better judgement, so Anthropic found it could delete much of that scaffolding and let the model use surrounding context instead.
The tooling also changed. CLAUDE.md used to be the main store of memory, information and guidance. Claude Code now has memory, artifacts and skills, which give the model new ways to load and share context across sessions. Treating one markdown file as the center of everything no longer fits the product.
The new rules of context engineering for Claude 5
From rules to judgement
The old system prompt contained absolute bans such as “default to writing no comments” and “never write multi-paragraph docstrings or multi-line comment blocks”. For a real subset of tasks that guidance was simply wrong. Complex code sometimes needs a longer comment block, and users have their own documentation preferences.
The new instruction reads “write code that reads like the surrounding code: match its comment density, naming, and idiom”. That is local, adaptive and checkable against the repository.
From examples to interface design
Giving worked examples of tool usage used to be rule number one. With the newest models, examples actually narrow the exploration space. Anthropic now recommends thinking about the design of your tools, scripts and files instead. Ask which parameters the model has and how they could be more expressive.
The Todo tool shows how this works. A status field defined as an enum of pending, in_progress and completed, plus the note to keep exactly one item in_progress, teaches the desired behavior through schema rather than through paragraphs of example calls.
From upfront loading to progressive disclosure
Claude Code’s system prompt used to embed detailed playbooks for code review and verification. Crucial when needed, but not needed on every turn. Those playbooks now live in skills that Claude loads selectively. The same idea applies to tools. Some are deferred, meaning the agent searches for their full definitions via ToolSearch only when they become relevant, so a larger toolset fits without a permanent context cost.
You can apply the same pattern to your own CLAUDE.md and skill files. Instead of one central repository for every practice you might ever need, keep a tree of files that loads at the right moment.
From repetition to simple tool descriptions
Older models paid more attention to instructions at the end of the context window than at the start, so important guidance got duplicated between the system prompt and the tool descriptions. Anthropic found it could delete the repeats. Usage guidance now lives once, inside the tool description.
From manual memory to automatic memory and richer references
The old habit was pressing the # hotkey to write everything into CLAUDE.md. Claude now saves memories that are relevant to you and your work on its own. Plan mode also leaned heavily on markdown plan files, but the model now handles more complex references, including HTML artifacts.
References can be code as well. A spec might be a detailed test suite or a function in another codebase that you want ported. Rubrics are another form: they let Claude spin up verifier agents that score output against your taste, such as what a good API design looks like in your organization.
How to apply the new rules to your own setup
The system prompt is tied to the product. It tells Claude what product it operates in and what its job is. Claude Code users will rarely touch it, but if you build your own agent harness, this is where most of your effort belongs.
Keep your CLAUDE.md lightweight. One short paragraph on what the repository is for, then spend the rest of your tokens on gotchas. A good example is a convention that types live in one monolithic file and nowhere else. Skip anything Claude can discover by reading your file system. A practical audit is to search your files for words like never, always and do not, then delete rules that duplicate each other, contradict each other or restate generic good practice the model already knows.
Treat skills as lightweight guides that encode the opinions and best practices specific to you, your team or your product. Split long skills into multiple files with a thin entry point, and only overconstrain the areas where mistakes are genuinely expensive.
For references, @ mention files and prefer code over prose. An HTML mockup of a design generally produces better results than a written description or a screenshot, because it gives Claude high-fidelity instructions in a language it knows well. Finally, run /doctor in Claude Code to review your skills and CLAUDE.md files, and accept the simplifications you agree with.
Caveats before you delete half your configuration
“No measurable loss” refers to Anthropic’s own coding evaluations. After cutting your context, re-run your private evals rather than trusting the claim blindly. Teams in finance, healthcare or other regulated environments will also want to keep explicit hard rules where compliance demands them.
Progressive disclosure only works if the model actually finds the material, so keep skill names obvious and discoverable. Automatic memory is more contested than the announcement suggests. Practitioners report that it sometimes stores details that only mattered for one task, or generalizes feedback that was meant for a single location. Periodic review remains sensible, and there is a portability argument too: a CLAUDE.md file can be read by any agent, while vendor-specific memory ties your context to one product.
More model judgement also means less determinism. Executable checks like tests, linters and type systems stay the real safety net, because they verify behavior instead of requesting it.
Less context, better aimed
The direction of context engineering for Claude 5 mirrors good software design: constraints move out of prose and into structure. Enums replace example calls, tool descriptions replace repeated instructions, and verification skills replace always-on playbooks. What remains in your written context is what the model cannot infer on its own, namely your taste, your gotchas and your definition of done. The strongest context is increasingly not prose the model must obey, but code it can run.
