The new rules of context engineering for Claude 5 models
Core thesis
- The prompt is only a small slice of what Claude sees; the rest ("context") is assembled from system prompt, skills, CLAUDE.md, memory, and other sources. Engineering that context matters more than the prompt.
- The newer models (Opus 5, Fable 5) have better judgement, so old context-engineering habits now backfire. Anthropic removed 80%+ of Claude Code's system prompt with no measurable loss on coding evals.
- They were over-constraining Claude, system prompt, skills, and CLAUDE.md issued conflicting instructions (e.g. "leave docs as appropriate" vs "DO NOT add comments") that Claude had to waste effort untangling.
- New /doctor command in Claude Code auto-rightsizes your skills + CLAUDE.md.
The 7 "Then → Now" shifts
1. Give Claude rules → Let Claude use judgement. Drop blanket rules like "never write comments"; new prompt says "write code that matches the surrounding code's comment density, naming, and idiom."
2. Give examples → Design interfaces. Examples now over-constrain the model. Instead, design expressive tools/parameters (e.g. a Todo status enum of pending/inprogress/completed, plus "keep one item inprogress") that imply correct usage.
3. Put it all upfront → Use progressive disclosure. Load the right context at the right time. Move things like verification and code review into their own skills; use "deferred loading" tools (found via ToolSearch) so they don't eat context until needed. Applies to your CLAUDE.md/skills too — a tree of files beats one giant file.
4. Repeat yourself → Simple tool descriptions. No need to restate instructions in both the system prompt and tool descriptions. Put usage guidance in the tool description only.
5. Memory in CLAUDE.md → Auto-memory. Instead of manually saving with #, Claude now auto-saves memories relevant to the work and to you.
6. Simple specs → Rich references. Claude can handle richer references: HTML artifacts, code, detailed test suites, a function in another codebase to port.
7. (Related) Rubrics as references. Rubrics let Claude verify your taste in a domain (e.g. "what good API design looks like") via dynamic workflows + verifier agents.
Applying it to your own context
- System prompt: heavily tied to product context (what product Claude is in, what it's doing). In Claude Code you won't touch it; if building your own agent, spend real time here.
- CLAUDE.md: keep it lightweight - briefly say what the repo is for, then spend most tokens on gotchas (e.g. "types live in one monolithic file"). Don't state the obvious Claude can see from the filesystem. Push details into progressively-disclosed skills (e.g. a verification skill referenced from CLAUDE.md).
- Skills: lightweight guides that let Claude find info when needed. Don't over-constrain (except in critical areas). Split long skills into many files (progressive disclosure). Best when they encode your specific opinions/knowledge/best practices.
- References: @-mention files for in-depth context (specs, mockups, whole codebases). Prefer code/artifacts over prose — an HTML mockup beats a screenshot or a text description of a design.
Bottom line
- Simplify across system prompt, skills, and CLAUDE.md. Delete constraints, trust the model's judgement, and lean on progressive disclosure. Use claude doctor to do it automatically; see the Fable field guide for advanced-model prompting.
Video
Thariq (@trq212)
We removed ~80% of the Claude Code system prompt for our newest models, this is what we've learned about writing system prompts, skills and Claude.MDs for them.
Article
The new rules of context engineering for Claude 5 models
I’ve written previously about how to best prompt the newest generation of Claude 5 models and work with them iteratively to discover what you want to build.
But when you send a message to Claude, the
— https://nitter.net/trq212/status/2080710971228918066#m