3128 words
16 minutes
Context Engineering for Claude 5: The Six New Rules (and How to Find the Rules You Can Delete)

For about a year, the accepted way to get better output from a coding agent has been to write more rules. Longer CLAUDE.md files. More defensive instructions. More few-shot examples. The same guidance repeated in three places so the model could not possibly miss it. Anthropic has now published the opposite advice, and it ran the experiment on its own flagship product before telling anyone else to: “We 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” [1].

Read that carefully before it becomes a slogan. The evaluations are Anthropic’s own internal coding evaluations. The post names no benchmark, publishes no suite, and reports no score, so “no measurable loss” is a vendor’s self-reported result on its own product, and nobody outside Anthropic has replicated it. What survives the caveat is still one of the more consequential claims made about agent harnesses this year: a heavily tuned production system prompt, on the vendor’s flagship coding agent, lost more than 80% of its content and did not get worse. Many of the rules you have been adding for a year were written for a model generation that has since been replaced.

Figure 1 - Diagram of a tall stack of agent rules shrinking to a short stack, the cut portion labeled over 80% and the remainder labeled gotchas

Figure 1 - The deletion, in one picture: The instructions that vanished were compensating for gaps a newer model closed. The ones that stayed encode what no model can derive by reading your repository. Telling the two apart is the whole job.


The Deletion Is a Quality Argument, Not a Token Argument#

The obvious reading is a budget one. Every always-loaded rule occupies context in every session forever, an argument we made in Your 1M-Token Context Window Is a Lie After 120K [2]. Standing cost is real, and it is the smaller half of this story.

The larger half sits in a section of Anthropic’s post that most summaries skip, titled “Unhobbling Claude”. The diagnosis there is about quality: “when we read transcripts of our own internal usage of Claude Code, we see several conflicting messages in a single request” as “our system prompt, skills, and user requests clash with each other,” so that “Claude must think more carefully about these overlapping and conflicting messages before deciding what to do” [1]. An over-specified harness is paid for in the model’s attention, spent resolving your contradictions rather than solving the problem.

That reframe turns a news item into an engineering decision. A merely long rules file wastes money. A long and internally inconsistent one, which is what a year of accretion reliably produces, suppresses judgment the current model already has.

Boris Cherny, who created Claude Code, said the same thing on stage at Y Combinator’s Startup School shortly after Opus 5 shipped: “a lot of the stuff in the system prompt was correcting for these behaviors that the model should have known, but it didn’t. Now Opus 5 just does it. So yeah, we deleted 80% of the system prompt” [3], [4].

One precision point, easy to get wrong in a summary. Thariq Shihipar wrote the post, Cherny gave the talk, and both work at Anthropic. That is a second authoritative voice, not independent verification. No confirmation of the over-80% figure exists from anyone outside the company.

Figure 2 - Diagram of three instruction sources labeled system prompt, skills, and user request converging on a single conflict node before the task begins

Figure 2 - Where the quality goes: Anthropic’s transcripts showed guidance from three surfaces arriving in one request and disagreeing. The model resolves the contradiction before starting the task, and that resolution is not free.

KEY INSIGHT: Over-constraining a current-generation model is a quality problem before it is a cost problem. Contradictory rules do not just take up room, they take up judgment.

Our teardown in The Pi Comparison [5] is the contrast case: a rival agent built around a minimal system prompt from day one.


The Six Shifts, in Anthropic’s Own Words#

The post frames the change as six paired reversals. The wording below is the post’s own, because paraphrases of this list have already started drifting [1].

1. Then: Give Claude rules. Now: Let Claude use judgement. The old prompt carried hard prohibitions written to prevent worst-case behavior. The replacement is one line of intent: “Write code that reads like the surrounding code: match its comment density, naming, and idiom” [1]. Do differently: for every absolute in your rules file, ask whether it prevents a catastrophe or corrects a habit. Catastrophe rules stay. Habit rules become one sentence describing the outcome you want.

2. Then: Give Claude examples. Now: Design interfaces. Anthropic found that “giving examples actually constrains them to a certain exploration space” [1], and redirects the effort into tool design. The worked example is the Todo tool, whose status enum of pending, in_progress, and completed plus a one-item-in-progress constraint teaches correct usage without a sample call. Do differently: delete the few-shot blocks from your skills and spend that budget on parameter names, enums, and constraints that make wrong usage hard to express.

3. Then: Put it all upfront. Now: Use progressive disclosure. Verification and code-review guidance moved out of the always-loaded prompt into skills Claude Code calls selectively [1]. The same principle runs at the tool layer: MCP tool search “keeps MCP context usage low by deferring tool definitions until Claude needs them,” loading only tool names and server instructions at session start, on by default [6]. Do differently: stop asking what your agent should know and start asking what it should be able to find. Beyond root and nested CLAUDE.md files and skills, the memory docs confirm a fourth destination, .claude/rules/ files with a paths frontmatter key, loading only when the agent touches matching files [7]. Never move a prohibition into a lazily loaded file, since a prohibition that is not loaded is not a prohibition.

4. Then: Repeat yourself. Now: Simple tool descriptions. Older models attended unevenly across a long context, so instructions were duplicated into both the system prompt and the tool description. Anthropic deleted the duplicates and left the guidance in the tool description alone [1]. Do differently: grep your harness for the same rule stated twice, and keep the copy closest to the thing it governs.

5. Then: Memory in CLAUDE.md files. Now: Auto-memory. The old advice was to press a hotkey and write memories into CLAUDE.md by hand. “Instead, Claude now automatically saves memories that are relevant to the work and to you” [1]. It is on by default, and its loaded scope is published: “The first 200 lines of MEMORY.md, or the first 25KB, whichever comes first” [7]. Do differently: stop hand-curating session notes into your rules file, and treat that 200-line ceiling as a real budget.

6. Then: Simple specs. Now: Rich references. Plans no longer have to be plain markdown. A spec can be an HTML artifact, a test suite, a function in another codebase to port, or a rubric a verifier agent grades against [1]. Do differently: when the artifact you want is code, hand over code. A working mockup beats a paragraph describing one.

Figure 3 - Two-column chart listing the six then-and-now context engineering shifts, old practice beside current practice

Figure 3 - The six reversals: Four shrink what is always loaded, one automates it, and the sixth enriches what loads on demand. Together they describe a harness carrying pointers rather than paragraphs.

There is a seventh move none of the six describes, and Anthropic publishes a live example. Its release notes carry the current system prompt for claude.ai and the Claude mobile apps, whose Claude Opus 5 section pins a short factual notice about the June 2026 export-control suspension of Fable 5 and Mythos 5 access and the July restoration: “These events are after Claude’s training-data cutoff, so Claude knows about them only from this notice” [8]. Simon Willison’s post surfaced it for most readers and links back to Anthropic’s page as the source [9]. Scope it carefully, since that is claude.ai’s published prompt and not Claude Code’s. Everything else here moves content out of the always-loaded layer. This move pins one narrow, dated fact into it, because it must be present in every session regardless of task.


The Audit You Can Run Today#

Anthropic shipped the audit as a command. First, clear a naming trap: there are three names and one is a different command.

InvocationWhat it isCan it fix anything
/doctorIn-session. The canonical name. Full setup checkupYes
/checkupRegistered alias of /doctor, identical behaviorYes
claude doctorTerminal subcommand. Read-only install and settings diagnostics, no session startedNo

Anthropic states the relationship from both directions. The CLI reference entry for the terminal subcommand points elsewhere for anything actionable: “For the in-session setup checkup that can also apply fixes, run /doctor” [10]. The /doctor entry returns the favor, noting that claude doctor prints read-only diagnostics without starting a session [11].

Worth saying plainly: the blog post that started all of this gets this wrong, telling readers Anthropic “rolled out a new command called claude doctor” that “will help you do this automatically” [1]. The product docs say that subcommand cannot fix anything. In a piece about conflicting instructions, we follow the docs. Run /doctor in a session.

Figure 4 - Diagram of three similarly named commands showing which two apply fixes in session and which is read-only

Figure 4 - Three names, two commands: The in-session command and its alias run the full checkup and apply fixes after you confirm them. The terminal subcommand reads your install and settings files and reports.

The docs describe nine distinct checks [11]:

  1. Installation health, including duplicate or leftover installs and PATH problems
  2. Unparseable settings files
  3. Unused skills, MCP servers, and plugins, measured against their context cost
  4. Slow hooks, flagged
  5. Version currency against your release channel
  6. Deduplication of local CLAUDE.md files against checked-in ones
  7. Trimming checked-in CLAUDE.md files by cutting content Claude could derive from the codebase
  8. Migration of the always-loaded guidance that remains into skills and nested CLAUDE.md files that load on demand
  9. Offers to make auto mode your default permission mode and to pre-approve frequently denied read-only commands

Two operational facts belong with that list. It is a report-then-confirm flow rather than an autofix, since the docs state it “Reports findings first and asks for confirmation before changing anything” [11]. It also has a version floor: the CLAUDE.md trim check requires Claude Code 2.1.206 or later [11]. This article was written against 2.1.220.

Figure 5 - Checklist of the nine setup checkup items, grouped into install health, extension cost, and memory files

Figure 5 - The nine checks: Three cover your installation, three cover what your extensions and permissions cost every session, and three cover your memory files, where accumulated rules live.

Item 7 is worth doing by hand as well, because the rule behind it is the sharpest sentence in the source set. The memory docs describe the trim as cutting “content Claude can derive from the codebase, such as directory layouts, dependency lists, and architecture overviews,” while keeping “pitfalls, rationale, and conventions that differ from tool defaults” [7]. Anthropic’s post gives the same instruction: “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” [1]. There is a published budget too, stricter than most repositories we see: “target under 200 lines per CLAUDE.md file” [7].

Figure 6 - Two-column diagram sorting rules-file content into a cut column for derivable material and a keep column for gotchas

Figure 6 - The sorting rule: Directory trees, dependency lists, and architecture overviews are reconstructible by reading the repository, and a hand-maintained copy drifts from the day it is written. A convention that contradicts a framework default survives however generic it sounds.

KEY INSIGHT: Keep the rule if it contradicts what the codebase would teach a competent reader. Cut it if it merely restates what the codebase already shows.

This is a chore worth repeating, and we run our own version on a schedule in Garbage Collection Day [12]. One prerequisite: get the harness into version control first, the argument of Your Agent Harness Belongs in Git [13]. Deletion is only safe when it is revertible.


Two Safety Rails and One Instrument#

Advice to delete most of your harness is reckless without the discipline that came with it. Three parts, none optional.

The rebuild rule. Cherny does not stop at “delete”. He describes ablation as a method borrowed from research: “you delete the entire system prompt and then bring it back line by line to figure out the impact of each individual line” [3], [4]. Applied to your own setup the loop is slow on purpose. “The first step is you delete. The next step is you use it” [4]. Then: “Only when you see it repeatedly stumble on the same thing, that’s when you add it back” [4]. The trap it guards against is guessing. Restoring a rule pre-emptively puts you back where you started, holding instructions you never confirmed were needed.

Figure 7 - Loop diagram of four steps, delete, use, observe, add one line back, with the shortcut from deletion straight to restoration struck out and labeled guessing

Figure 7 - Delete, use, observe, restore one line: The loop only produces information if the middle step is real work over real time. Skipping from deletion to restoration reproduces the file you started with.

The reasoning-versus-convention split. Cole Medin ran the ablation as an A/B on his own Archon repository, stripping a 1,000-line rules file and a 350-line skill to almost nothing, then running both configurations against real issues from that repo. His reported result splits by task type: architectural-reasoning tasks held up fully stripped, while convention-compliance tasks broke. His summary: “Rules that fix reasoning have decayed because LLMs have gotten good enough at reasoning. But rules that direct attention and customize things, those are just as important” [14]. That is one practitioner’s self-reported test on one codebase rather than an audited benchmark, and should be weighed as such. It is also the most useful sorting heuristic available, and it agrees with the vendor’s trim rule.

Figure 8 - Two-panel comparison marking reasoning-repair rules as decayed and convention-teaching rules as still earning their place

Figure 8 - Which rules decayed: Rules written to patch a weaker model’s reasoning are the ones a stronger model made redundant. Rules that teach your project conventions were never about model capability, so a new generation retires none of them.

The same line fences off one category we would not touch. Enforcement rules, deny lists, and destructive-command blocks are not scaffolding a model outgrows, and we argued for treating them as architecture rather than instruction in Delete the Bash Tool [15]. A capability the agent does not have needs no rule at all.

The instrument, and what it is not. Claude Code ships a flag that strips the harness for measurement. The CLI reference describes --bare as “Minimal mode: skip auto-discovery of hooks, skills, plugins, MCP servers, auto memory, and CLAUDE.md so scripted calls start faster,” setting CLAUDE_CODE_SIMPLE [10]. Cherny’s line about it travels widely: “the model is actually a little bit more intelligent without these prompts” [4].

The sentence he said immediately afterward travels much less, and every relay we found dropped it: “when you use Claude Code as a product, you do actually want some of these prompts because it helps you use the product and it helps the product behave and the model behave in the way that you would want when you’re using it as a person” [4]. Quoting the first half without the second misrepresents him. --bare is an instrument for finding out whether a prompt earns its place, not an operating mode.

KEY INSIGHT: Ablation is an eval you run by subtraction. If deleting something changes nothing you can observe over a week of real work, it was never doing anything.

One counterweight, since the six shifts are a default rather than a law. --append-system-prompt adds text instead of replacing the default prompt [10], and practitioners spend that budget deliberately to buy back tone control. Anthropic’s memory docs recommend the flag for exactly that, with a limit: “This must be passed every invocation, so it’s better suited to scripts and automation than interactive use” [7].


Conclusion#

The news framing here will expire. A newer model generation will arrive, new guidance will follow, and the over-80% deletion will read like a dispatch from a previous era. The mechanism underneath will not.

Harness instructions have a shelf life, and the model sets it, not you. Every rule in your setup was written on a specific day to compensate for a specific gap. Some of those gaps closed without anyone telling you, and the compensating rule stayed, competing for attention with the rules that still matter. Nothing flags that, which is why the accumulation stays invisible until you go looking.

The durable discipline outlives the announcement. Keep the harness in version control so deleting is revertible. Sort rules by what they were written to fix, so reasoning patches go first and convention teaching stays. Delete in batches, work normally long enough to notice a pattern, and restore one line only when the same stumble repeats. Run /doctor in a session on a schedule, not when something feels slow. Treat --bare as a measuring device.

Anthropic did all of this to its own flagship product and published the result. The reasonable response is not to copy the figure, it is to run the measurement on your own harness, since the only number that matters is the one you get.


References#

[1] T. Shihipar, “The new rules of context engineering for Claude 5 generation models,” Anthropic, Jul 2026. https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models

[2] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Your 1M-Token Context Window Is a Lie After 120K: Budgeting Sessions with /handoff,” 2026. /insights/claude-code-14-context-lifecycle/

[3] Y Combinator, “Boris Cherny: We Cut 80% of Claude Code’s Prompt,” YouTube, Jul 2026. https://www.youtube.com/watch?v=qyPCVqFUyDo

[4] Root Access, “Boris Cherny: Building Claude Code,” Y Combinator, Jul 2026. https://www.ycrootaccess.com/p/boris-cherny-building-claude-code

[5] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “The Pi Comparison: What Claude Code’s Open-Source Rival Reveals About Harness Design,” 2026. /insights/claude-code-10-pi-comparison/

[6] Anthropic, “Connect Claude Code to tools via MCP,” Claude Code Documentation, 2026. https://code.claude.com/docs/en/mcp

[7] Anthropic, “How Claude remembers your project,” Claude Code Documentation, 2026. https://code.claude.com/docs/en/memory

[8] Anthropic, “System Prompts,” Claude Platform release notes, Jul 2026. https://platform.claude.com/docs/en/release-notes/system-prompts

[9] S. Willison, “A quote from Claude Opus 5 system prompt,” Simon Willison’s Weblog, Aug 2026. https://simonwillison.net/2026/Aug/9/claude-opus-5-system-prompt/

[10] Anthropic, “Claude Code CLI reference,” Claude Code Documentation, 2026. https://code.claude.com/docs/en/cli-reference

[11] Anthropic, “Claude Code commands reference,” Claude Code Documentation, 2026. https://code.claude.com/docs/en/commands

[12] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Garbage Collection Day: A Weekly Ritual for Reducing Agent Slop,” 2026. /insights/claude-code-08-garbage-collection-day/

[13] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Your Agent Harness Belongs in Git: The Case for Declarative Harness State,” 2026. /insights/claude-code-12-bootstrap-framework-harness-iac/

[14] C. Medin, “The Creator of Claude Code Said to Do What Now?!,” YouTube, Aug 2026. https://www.youtube.com/watch?v=VnyGs43eiAA

[15] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Delete the Bash Tool: Five Levels of Agentic Security,” 2026. /insights/claude-code-11-delete-bash-tool/

Context Engineering for Claude 5: The Six New Rules (and How to Find the Rules You Can Delete)
https://dotzlaw.com/insights/claude-code-19-context-engineering-claude-5-rules/
Author
Gary Dotzlaw, Katrina Dotzlaw, Ryan Dotzlaw
Published at
2026-08-27
License
CC BY-NC-SA 4.0

Building production AI, or modernizing a legacy system?

That is the kind of work we do at Dotzlaw Consulting. Book a free 20-minute intro call and tell us what you are trying to build, or what is slowing you down.

← Back to Insights