Anthropic deleted 80% of Claude Code's system prompt. Here is what replaced it | Aravind Arumugam
ai7 min read
Anthropic deleted 80% of Claude Code's system prompt. Here is what replaced it
Anthropic removed more than 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.
Here is every change they made, with the actual before and after in each case.
What did the old prompt actually say?
This is what was in the Claude Code system prompt, quoted from the engineering post:
In code: default to writing no comments. Never write multi-paragraph docstrings or multi-line comment blocks — one short line max. Don't create planning, decision, or analysis documents unless the user asks for them — work from conversation context, not intermediate files.
This is the line that replaced it:
Write code that reads like the surrounding code: match its comment density, naming, and idiom.
A paragraph of prohibitions became one sentence about matching context.
Anthropic explain why the original was there. When Claude Code first rolled out they needed to be sure Claude avoided worst case scenarios, such as deleting files, so they gave particularly strong guidance that might not always be true. They are explicit that the guidance was sometimes wrong: in the case of documentation, the user may have their own preferences, or specific parts of very complex code might need multi-line comment blocks. Without the guardrails, older models wrote incorrect comments in many cases, and they accepted that tradeoff.
What did the conflict look like in practice?
They read transcripts of their own internal Claude Code usage. In a single request they found instructions like "leave documentation as appropriate" sitting alongside "DO NOT add comments", as the system prompt, skills and user request pulled against each other.
Their conclusion is worth quoting because it is more precise than saying the model got confused:
Generally, Claude can interpret the user's intent to get to the right answer, but Claude must think more carefully about these overlapping and conflicting messages before deciding what to do.
Six shifts, with the example for each
Then: give Claude rules. Now: let Claude use judgement
Covered above. The comment rule is the worked example.
Then: give Claude examples. Now: design interfaces
Giving Claude examples was, in their words, the number one rule for tool usage. They now find examples constrain the newer models to a certain exploration space.
Their example is the Todo tool. Listing status as an enumeration between pending, in_progress and completed hints to Claude how to use it. The instruction to keep one item in_progress defines the behaviour they want. The parameter design does the teaching, so no example is needed.
Then: put it all upfront. Now: use progressive disclosure
Because Claude Code was focused on coding, the system prompt carried detailed information on how to do code review and verification. That was not always needed, but when it was, it was crucial.
Two concrete moves came out of this.
They moved verification and code review into their own skills that Claude Code calls selectively.
They also applied it to tools. Some tools are now "deferred loading", which means the agent must search for their full definitions using ToolSearch before using them. That lets them ship more tools, such as their Task tools, without those tools taking up context until they are needed.
On your own files, they name the myth directly: that CLAUDE.md and Skill.md should be a central repository for every practice you might run into, because Claude would not find it otherwise. Their alternative is a tree of files that can be loaded at the right time.
Earlier Claude models sometimes needed repeated instructions, and were more likely to follow instructions at the end of their context window than at the start. So the system prompt would carry references to tools as well as the instructions already in the tool description.
They deleted the repeats and put instructions on how to use a tool in the tool description rather than the system prompt.
Then: memory in CLAUDE.md. Now: auto-memory
They used to encourage saving things to memory with the # hotkey, which writes to your CLAUDE.md automatically. Claude now saves memories that are relevant to the work and to you, on its own.
Then: simple specs. Now: rich references
In plan mode, Claude Code relied heavily on markdown files with plans, and storing specs in the codebase was a similar best practice.
They list four things Claude can take as a reference now instead:
An HTML artifact created by the artifacts feature
A detailed test suite, as the spec
A function in a different codebase that Claude might port
A rubric
The rubric example is specific. Rubrics let Claude verify your taste in a particular field, for example what a good API design looks like, by using dynamic workflows and spinning up verifier agents with those rubrics.
Where should each instruction live?
The article closes with a placement guide. This is their advice, not a summary of it.
System prompt. Heavily tied to product context. It tells Claude what product it is operating in and what it is doing. In Claude Code you will likely never modify this. If you are building your own agent harness, this is where you should spend a lot of time.
CLAUDE.md. Keep it lightweight. Briefly describe what your repo is for, then spend most of the tokens on gotchas inside the codebase. Their example of a gotcha: you may organise your code to keep types in one monolithic file and nowhere else. Avoid stating the obvious things Claude should know by looking at your file system or your repo.
They pair this with a progressive disclosure example. If you have several unique instructions on how to verify your work, create a verification skill and reference it from your CLAUDE.md.
Skills. Lightweight guides that let Claude find information when needed. Avoid making them overconstrained, except in highly important areas. For long skills, divide them into many files and split them out. Skills work best when they encode opinions, knowledge or best practices particular to you, your team or your product.
References. You can @ mention files. Prefer files that are in code, because that gives clear, high-fidelity instructions in a language Claude knows very well. Their comparison: an HTML mockup of a design will generally produce better results than a description of the design, or a screenshot of it.
Is there a command for this?
Yes. Anthropic put these practices into claude doctor. Run /doctor inside Claude Code to rightsize your skills and CLAUDE.md files.
Summary
Anthropic cut more than 80% of Claude Code's system prompt for Claude Opus 5 and Claude Fable 5 with no measurable loss on coding evaluations. A paragraph banning comments became one line: write code that reads like the surrounding code. Examples gave way to interface design, shown by the Todo tool's pending / in_progress / completed enum. Code review and verification moved into skills, and some tools became deferred loading behind ToolSearch. Duplicate instructions were deleted in favour of the tool description. The # memory hotkey gave way to auto-memory. Specs became rich references: HTML artifacts, test suites, a function in another codebase, or a rubric with verifier agents. Keep CLAUDE.md to gotchas such as types living in one file, keep skills unconstrained and split across files, prefer references that are already code, and run claude doctor.
