The new rules of context engineering for Claude 5 models

What happened

The team behind Claude Code has published a detailed account of how it rewrote the rules for assembling context when using Claude Opus 5 and Claude Fable 5, Anthropic's newest generation of models. The core finding, shared by Thariq (@trq212) in a post that drew 465 replies, 1,903 reposts, and 16,278 likes across nearly 4.8 million views, is striking: the Claude Code system prompt was cut by over 80% with no measurable loss on coding evaluations.

This piece unpacks what changed, how the new approach is structured, and what any developer building on Claude Code or shipping their own agent harness should audit before assuming their existing context setup still reflects best practice.

On July 24, Thariq published a long-form article on X outlining what the Claude Code team learned while adapting its prompting approach for Claude Opus 5 and Claude Fable 5. The central act was removing more than 80% of the Claude Code system prompt. The team ran internal coding evaluations before and after the cut and found no measurable regression. That result prompted a broader rethink of every layer of context — system prompt, CLAUDE.md files, skills, memory, tools, and references — and the lessons were distilled into a new command called claude doctor, accessible in Claude Code via the /doctor command.

How it works

The post also references a companion resource called the Fable field guide for teams wanting more detailed guidance on prompting the most capable models in the Claude 5 family.

The old system prompt constrained Claude with explicit rules designed to prevent worst-case behavior, such as instructions like "never write multi-line comment blocks" or "do not create planning documents unless asked." For Claude Opus 5 and Claude Fable 5, the team replaced those rigid rules with a single principle: write code that reads like the surrounding code, matching its comment density, naming, and idiom. The model now uses judgment and surrounding context rather than checking a list of prohibitions.

Why it matters

The new architecture also separates concerns across layers. Tool instructions now live in tool descriptions rather than being repeated in the main system prompt. Memory is handled automatically by the model rather than requiring the user to write to CLAUDE.md via the # hotkey. Code review and verification steps moved into dedicated skills that Claude Code loads selectively, rather than occupying permanent space in the system prompt. Some tools use deferred loading, meaning the agent must call ToolSearch before accessing their full definitions, keeping unused tools out of the active context window.

The result overturns several widely held context-engineering assumptions. Giving Claude examples to constrain its tool usage — once considered best practice — now actively limits the model's exploration space. The team found that designing expressive tool interfaces, such as enumerating a Todo status field as pending, in_progress, or completed, gives the model more actionable signal than worked examples. Likewise, the idea that a CLAUDE.md file should be a comprehensive repository of every known practice has been retired; the recommendation now is to keep it lightweight, focused on gotchas specific to the codebase, and to delegate depth to linked skill files.

Progressive disclosure replaces the old "put it all upfront" model. Context that was once permanently loaded into the system prompt — code review checklists, verification steps, detailed tool documentation — is now fetched on demand. This reduces token consumption during the majority of requests where those resources are irrelevant, and keeps the active context window tighter and more focused.

Who is affected

Developers using Claude Code directly are the most immediately affected, because the /doctor command now audits their existing skills and CLAUDE.md files and recommends cuts. Teams that have invested significant time building elaborate CLAUDE.md files or verbose skills based on earlier guidance will likely find that much of what they wrote is counterproductive for Claude Opus 5 and Claude Fable 5. The behavior changes are not theoretical: the internal Claude Code team itself found conflicts in its own transcripts where system prompt instructions, skill instructions, and user requests issued contradictory guidance — for example, "leave documentation as appropriate" colliding with "DO NOT add comments" in the same request.

Developers building their own agent harnesses on top of Claude 5 models face a different version of the same challenge. The system prompt advice here is to focus on product context — what the agent is, what it does — rather than behavioral guardrails. For these builders, the shift from examples to interface design and from monolithic context to progressive disclosure has direct implications for how they structure tool definitions, load reference documents, and organize skill trees.

What to watch next

The Fable field guide mentioned in the post is the clearest next document to track for anyone working with Claude Fable 5 specifically, as it promises model-specific prompting detail that the July 24 article only gestures toward. The claude doctor command is also worth running repeatedly as the Claude Code team continues to update its recommendations; the underlying model for what constitutes a well-formed skill or CLAUDE.md file has already shifted once and will likely shift again as Claude 5 family capabilities are better understood through production use.

Builders should also verify whether their existing tool descriptions are doing the work previously done by system prompt repetition, and whether CLAUDE.md files contain advice that overlaps with what Claude Opus 5 or Claude Fable 5 can infer from the codebase itself. The key verification question for any instruction in context is whether removing it would produce a measurable difference — which is exactly the test the Claude Code team ran, and which yielded an 80% reduction.