David Yin
This is the English version of a Chinese original.
On July 24, Anthropic’s official blog updated a piece about context engineering. Buried in it is one sentence that should make anyone who builds AI workflows sit up:
For the Claude Opus 5 and Claude Fable 5 generation, they deleted more than 80% of Claude Code’s system prompt — and measured no observable loss on their own coding evaluations.
Not a rewrite. Not an optimization. A deletion. Eighty percent gone, and the scorecard didn’t move.
What makes that sentence devastating is that the entire craft the industry accumulated over the past two years — stuffing in every caveat, listing every counterexample, repeating each rule three times — was just falsified by the official product itself, at scale.
First, be clear about which part was deleted
People use “prompt” and “context” interchangeably, but what’s being discussed here is not the sentence you type into the chat box.
What you type is only the smallest piece. What actually reaches the model is a whole bundle: the system prompt, Skills, CLAUDE.md, memory, reference files pulled in with @ — all of it combined is what the model actually reads this round. Anthropic calls managing that bundle context engineering.
The difference? A prompt is one-shot and can be extremely specific. Context has to be reused across hundreds of requests, and you have no idea what the user will ask next — so it can only be written “generally.”
And “generally” is exactly where it goes wrong — because you can’t resist pre-emptively blocking every situation you can imagine.
In their own words: we had Claude straitjacketed
The article uses the word unhobbling — literally, removing the shackles. Reviewing their own internal Claude Code conversation logs, the team kept finding instructions that fought each other inside a single request:
The system prompt says “keep documentation where it belongs,” some skill says “don’t write comments,” and the user says “just follow the existing style.”
Three sentences from three sources, none of them wrong — but stitched into one context they become a reading-comprehension problem. Sure, the model can guess what you really want; the cost is that it first spends a round of effort reconciling the contradictions, and only then starts working.
Here’s a cause-and-effect that’s easy to miss: those constraints weren’t added for nothing. Older models didn’t have enough judgment — without hard rules they really would write a screen of nonsense comments, really would “normalize” docs across the whole repo. So the team accepted “sometimes constrains the wrong thing” to block the worst case.
What changed is the model, not the principle. Once the new generation can exercise judgment on its own, the same rule flips from “insurance” to “cost.”
Six old best practices, crossed out one by one
The most striking part of the article is a comparison table — six former best practices, all now marked as outdated.
One: from “give rules” to “give judgment.”
The old system prompt said things like: no comments by default, never multi-paragraph docstrings or multi-line comment blocks, one line at most; unless the user asks, don’t produce planning/decision/analysis documents.
The new version replaces it with a single line: write code that reads like the surrounding code — comment density, naming, habits all follow context.
The former is a hard deadline; the latter is a standard of judgment. The former is right in 90% of cases and ugly in the remaining 10% (a genuinely complex piece of logic may truly need a long explanation). The latter hands that 10% back to the model.
Two: from “give examples” to “design the interface.”
This one is the most counterintuitive. The old first rule of tool-calling was: always provide examples. Now Anthropic says examples box the model into the handful of usages you demonstrated.
The alternative is to design the tool itself — what the parameters are named, what values they take, how the fields relate.
Their example is their own Todo tool: the status field is just the enum pending / in_progress / completed, and the model understands the transitions on its own; add one line — “only one item may be in progress at a time” — and the behavioral constraint is sealed.
No examples needed. The interface itself is the best instruction manual.
Three: from “everything up front” to “progressive disclosure.”
Early Claude Code stuffed everything into the system prompt — including how to do code review and how to verify — content that isn’t needed every time but is crucial when it is.
Now all of that is split into separate skills, loaded only when needed. The same applies to tools: some were switched to “deferred loading,” where the model must first call ToolSearch to retrieve the full definition. The benefit: you can have many tools, and the unused ones cost zero tokens.
Incidentally, the article calls out a widespread misconception: many people think CLAUDE.md and skill files must be written as big all-in-one central repositories, or the model “won’t find it.” The right approach is a file tree it can load on demand.
Four: from “say important things three times” to “say it once, in the tool description.”
Older models had a quirk: an instruction placed at the end of context was heard more reliably than one at the start, so the team got in the habit of duplicating key rules in both the system prompt and tool descriptions. Those duplicates can now be deleted outright — the instruction living in the tool description is enough.
Five: from “manually write it into CLAUDE.md” to “automatic memory.”
You used to use the # shortcut to write things into CLAUDE.md by hand. Now the model judges for itself what’s worth remembering.
Six: from “minimal spec” to “rich reference.”
Plans and specs used to be distilled into a markdown file. Now Anthropic says the model can digest far richer references: a thorough test suite can serve as the spec; a function in another repo can serve as the spec; an HTML prototype can serve as the design.
Even a scoring rubric counts as a reference — write “what counts as good API design” as a rubric, and let the model spin up a verification agent to grade against it.
So how should you actually write it
The end of the article assigns each of the four locations its own role — arguably more practical than the six points above.
System prompt: it’s bound to the product context — telling the model which product it lives in and what it’s doing. Claude Code users basically never touch it; but if you’re building your own agent, this is where the most effort belongs.
CLAUDE.md: keep it light. Say briefly what the repo is for, then spend most of the space on the pitfalls — e.g., “all type definitions live in this one file; don’t look elsewhere.” Anything the model can learn from glancing at the file structure: don’t write a single word.
Skills: treat them as “a light guide it can look up when needed,” not regulations that must be obeyed. Unless the domain is truly critical, don’t write a skill too rigidly. If it gets long, split it into files. A skill’s greatest value is carrying the specific insight of you, your team, your product — general knowledge the model already has.
Reference files: prefer code for whatever you @ in. In their words: an HTML version of a design usually beats a text description — and a screenshot too.
They also shipped a small tool along the way: type /doctor inside Claude Code and it gives your existing skills and CLAUDE.md a slimming checkup.
The honest reaction of someone who builds workflows
I maintain a content-production pipeline with a few dozen skills, and my first reaction to this article wasn’t “learned something” — it was mild embarrassment.
Because every called-out pattern exists in my own files: afraid the model would drift, every rule ends with “never,” “must,” “or it counts as incomplete”; afraid it wouldn’t find things, a single skill ballooned to hundreds of lines; afraid it would forget, the same sentence duplicated in three files.
That’s not laziness — it’s conditioned reflex trained by the models of the past two years. Every one of those rules corresponds to a real incident.
The problem is that reflexes update slower than models. Those constraints existed to plug capability gaps; once the gap is closed the constraint doesn’t auto-expire — it stays in the file, still fighting against the judgment the model has now. And context is additive by structure: things go in and don’t come out. A year of that and it’s sedimentary rock, layer on layer.
So what this article is really saying is not “write less,” some slacker’s blessing. It’s saying your rule files need a periodic deletion mechanism — every time the model generation turns over, go back and ask of each rule: which shortfall was this compensating for? Is that shortfall still there?
One more line worth pulling out on its own: the job of a constraint is to prevent the worst case, not to lift the average. Preventing the worst case has a price — the price is that you pin down the best case along with it. That trade used to be worth it. It isn’t necessarily anymore.
As for how much to cut — they cut 80% themselves; you don’t have to copy the number. But if you’ve never deleted anything, the right answer probably isn’t zero.
Sources
- Anthropic official blog: “The new rules of context engineering for Claude 5 generation models” (July 24, 2026, by Thariq Shihipar)
- Anthropic official blog: “A field guide to Claude Fable: finding your unknowns”
- Claude Code official docs (code.claude.com/docs)
How many lines is your CLAUDE.md or rules file by now? When did you last delete something from it?