Less Is More: Context Engineering Practices After Claude Opus 5 and Fable 5

Claude Opus 5 was released last week, offering performance comparable to Fable 5 at half the price and with fewer safety guardrails. This launch moves the entire Claude family (except Haiku 4.5) to the fifth generation, including Sonnet, Opus, Fable, and Mythos.

Context engineering is the dynamic management of what content occupies a model's context window during inference. The author notes that a single user prompt occupies only a tiny fraction of the window; the bulk consists of system prompts, Skills, CLAUDE.md, and memory.

The author’s own CLAUDE.md is only 31 lines (1,036 characters), but the accompanying rules/common directory contains ten files exceeding 14,000 characters, covering coding style, test requirements, safety checklists, and agent orchestration. Adding a project‑level CLAUDE.md brings the total injected context to 43,973 characters per session, which feels bloated for Opus 5.

The Claude blog introduces the term “overconstraining.” By examining internal Claude Code session logs, the author found contradictory directives: one rule forces immediate code‑reviewer calls, while the system prompt says “Do not call the AgentTool unless the user requested it.” Such conflicts force the model to resolve contradictions before acting.

Because newer models have stronger judgment, many of these constraints can be removed. The blog lists six before‑after rule groups:

Annotation rule: from a strict prohibition on multi‑line comments to a single sentence that code should match the surrounding style.

Tool usage examples: instead of enumerating three usage examples that lock the model into a narrow space, redesign the tool interface (e.g., a Todo tool with an enum status field) so the model can infer the correct usage.

Progressive disclosure: move rarely needed verification details from the system prompt into separate Skills that the model loads on demand.

Duplicate instructions: eliminate repeated guidance in both system prompts and tool descriptions.

Memory handling: rely on Claude’s automatic memory storage rather than manual # shortcuts.

Reference diversification: replace extensive markdown plans with richer references such as HTML artifacts, test suites, or external functions that the model can directly consult.

The author’s takeaway for CLAUDE.md is to keep it lightweight: a one‑sentence description of the repository’s purpose, and focus token budget on real code issues rather than exhaustive rule listings.

For Skills, the recommendation is to treat them as lightweight, on‑demand guides. Split long Skills into multiple files, load them only when needed, and encode team‑specific judgments instead of generic best practices.

References should be added via @‑file syntax, preferring code‑shaped artifacts (HTML mockups, test suites, functions) because they preserve fidelity for the model.

Finally, Claude now includes these practices in the /doctor command, allowing users to automatically slim down Skills and CLAUDE.md during a session.