Context Engineering

Summary

Context engineering is the practice of assembling the full context a model receives — system prompt, skills, CLAUDE.md, memory, references — rather than just the user’s prompt. Anthropic removed ~80% of Claude Code’s system prompt for Claude 5 models (Opus 5, Fable 5) with no measurable loss on coding evaluations, revealing that older best practices had become myths.

Core Insight

The prompt is only a small part of what the model sees. Most context comes from system prompt, skills, CLAUDE.md files, memory, and other sources. How you assemble this “general context” (used across many requests, not specific to one) has a bigger impact than the prompt itself.

Then vs Now — Six Rule Changes

1. Rules → Judgement

Then: Strong guardrails to avoid worst-case scenarios (e.g., “never write multi-line comments”)
Now: “Write code that reads like the surrounding code: match its comment density, naming, and idiom”
Newer models have better judgement; over-constraining causes conflicting messages (e.g., “leave documentation as appropriate” vs “DO NOT add comments”)

2. Examples → Interface Design

Then: Give Claude examples of how to use tools
Now: Design expressive tool interfaces — enum values in parameters hint at usage patterns without examples
Examples actually constrain the model’s exploration space

3. Upfront → Progressive Disclosure

Then: Pack all guidance into the system prompt
Now: Use skills that Claude selectively loads; some tools use “deferred loading” (must search for full definitions via ToolSearch)
Common myth: make CLAUDE.md a central repository for every known practice. Instead: a tree of files loaded at the right time

4. Repetition → Simple Tool Descriptions

Then: Repeat instructions in both system prompt and tool descriptions (older models needed it)
Now: Put tool usage instructions in tool descriptions only, not duplicated in system prompt

5. Manual Memory → Auto-Memory

Then: Users manually save to CLAUDE.md via # hotkey
Now: Claude automatically saves memories relevant to the work and user

6. Simple Specs → Rich References

Then: Markdown plan files, simple specs
Now: HTML artifacts, code references, test suites as specs, rubrics with verifier agents
Code references give higher-fidelity instructions than descriptions or screenshots

Applying This to Your Context

System Prompt: Tied to product context; spend time here if building your own agent harness
CLAUDE.md: Lightweight — describe repo purpose, focus tokens on gotchas. Avoid “obvious” things Claude can discover from the filesystem. Use progressive disclosure for detailed instructions.
Skills: Lightweight guides, not overconstrained. Encode opinions, knowledge, or best practices particular to your team/product. Split long skills into many files.
References: @ mention files for in-depth context. Prefer code (HTML mockups, test suites) over descriptions or screenshots.

`claude doctor`

Anthropic shipped /doctor in Claude Code to automatically rightsize skills and CLAUDE.md files — removing redundancy that newer models don’t need.

Open Questions

How fast do these rules evolve? Will Claude 6 need even less context?
What’s the optimal skill granularity for progressive disclosure?
How does auto-memory interact with user privacy expectations?
Can the “unhobbling” principle be applied to non-coding domains (writing, research, data analysis)?

My Brain Wiki

探索