Context Engineering for Claude 5: Fewer Rules, Better Judgment

Picture this: a team ships an agent that “followed all the rules.” It didn’t crash. It didn’t refuse. It produced something… and yet it felt off. The code style was slightly wrong, comments were missing where they shouldn’t be, and verification happened too often in one workflow and not at all in another.

That’s when context engineering stops feeling like prompt-writing and starts feeling like debugging. Because in agent systems, your prompt is only one slice of what the model sees.

What “context engineering” really means

In this setting, context is the full bundle of information the model receives to answer a request. In Claude Code, that includes your conversation, code files, and also persistent instruction layers like a system prompt, CLAUDE.md, skills, plus memory-like additions the system keeps track of.

A system prompt is the top-level instruction that shapes the model’s behavior across requests. CLAUDE.md is a repository of “always-on” guidance (often repo-specific gotchas). Skills are named capability modules that can be loaded on demand. Memory is persistent user- or project-relevant facts that the system may save automatically.

Context engineering is the practice of designing those layers so the model gets the right guidance at the right time—without flooding it with contradictions or noise. And yes, it becomes harder as models evolve.

Why do so many “prompt rules” stop working as models improve? Because those rules may have been compensating for older limitations. Newer models can do more, so the old guardrails can become guardrails you no longer need.

The headline change: less “system prompt”, more judgment

Anthropic’s Claude 5-generation guidance describes a concrete shift: they removed over 80% of Claude Code’s system prompt for advanced models such as Claude Opus 5 and Claude Fable 5, reporting no measurable loss on their coding evaluations. (claude.com)

The practical lesson isn’t “delete everything and hope.” The lesson is that overconstraining can create failure modes that are subtle: conflicting directives can sit in different layers (system prompt vs skills vs files), forcing the model to resolve contradictions rather than focus on the task. ()

In other words, context engineering needs a more human design goal:

• Reduce contradictions.
• Keep only the rules that truly must never be violated.
• Let the model infer the rest from surrounding code and conversation.

This is the idea behind “Unhobbling Claude”: remove some of the “don’t do X” machinery and replace it with guidance that matches real-world variation.

A concrete example: comment density beats “never write docstrings”

Older agent setups often hard-coded stylistic rules like “never write multi-paragraph docstrings.” That’s safer when the model is weak at style transfer—but it becomes wrong the moment you encounter a codebase where docstrings are the convention, or where documentation is necessary.

The updated approach described in the article is more adaptive: “write code that reads like the surrounding code,” including comment density and idiom. ()

So instead of trying to preempt every style edge-case with rules, you encode a principle that the model can apply once it sees the local signals.

“Then and now” for context engineering myths

The original post lays out several “myths” that used to work for earlier generations. Here’s how to translate each into an engineering mindset you can use with your own agents.

Myth #1: Give the model more rules

Now: Let it use judgment where the cost of being slightly wrong is low.

When rules conflict, the model spends effort reconciling them. When a rule is merely a preference (“docstrings style”), local context is usually better guidance than a global prohibition.

A good heuristic: if a rule is really just a team preference, it’s often better stored as examples inside the codebase (or a skill that’s invoked when documentation is required) than as a blanket prohibition.

Myth #2: Give examples for every tool

Now: Design tool interfaces so the model can choose correctly without being boxed into a specific demonstration.

Tool descriptions matter more than rote examples. The post argues that examples can constrain the model’s exploration space, while better tool parameters (inputs the tool accepts) communicate intent.

For example, a Todo tool can encode state using an enumeration like pending, in_progress, completed, and then include a behavioral constraint such as keeping only one item in in_progress. Instead of showing a multi-step worked example, the interface itself guides the behavior. ()

This is an important shift in thinking: you’re not only prompting a model—you’re shaping the action space.

Myth #3: Put everything upfront

Now: Use progressive disclosure.

Progressive disclosure means you don’t load all details into context immediately. You load the minimal “index” first, then pull in heavy material only when it’s needed.

Claude Code’s newer architecture does this in multiple places, including skills and tools. The post notes that verification and code review were moved into skills that Claude can selectively call, rather than keeping all of that detail in the global prompt. ()

And tools can be “deferred loading,” where the agent searches for full definitions only when it decides to use them.

The tool side of progressive disclosure: ToolSearch and deferred loading

If you’re building agents (or tuning Claude Code setups), deferred loading is one of the biggest practical wins.

In the Claude Platform docs, tool search works like this: you include a tool search tool in your tools list, provide tool definitions in the tools array, and mark some tools as deferred using defer_loading: true. Initially, Claude’s context contains only the search tool and non-deferred tools. When Claude needs more tools, it searches and receives tool references that get expanded into full definitions at that moment. (platform.claude.com)

In Claude Code specifically, MCP tool definitions are deferred by default and loaded on demand via tool search—so only tool names consume context until a tool is actually used. (code.claude.com)

Why does this matter for “context engineering” (not just cost)? Because loading fewer tools reduces noise and improves selection accuracy when tool libraries get large. The Claude Code docs explicitly describe tool search as a way to avoid context-window waste and degraded selection accuracy when many tools are loaded at once. (code.claude.com)

Designing your own “tree of files” and skills

The post also warns against another common trap: turning CLAUDE.md into a giant dumping ground of every practice you might need.

Instead, it suggests structuring your guidance so it can be loaded at the right time, including having a tree of files. ()

A mental model that works well:

• Put a small amount of “global orientation” in CLAUDE.md.
• Put deep, situational knowledge into skills or skills + referenced files.
• Only load the deep pieces when the task actually triggers them.

Auditing your context with Claude Doctor

Even careful teams accumulate stale rules over time. The article describes a command designed to rightsize your setup: claude doctor (invoked as /doctor in Claude Code), used to simplify and align your system prompt, skills, and CLAUDE.md to the expectations of newer model behavior. ()

Whether or not you use Claude Code, the underlying engineering idea is universal: treat your context layers like code.

• Remove dead instructions.
• Detect conflicts.
• Push variability into the model’s local inference signals (surrounding code, tool schemas, task-specific skills).

A “new rules” checklist for your agent context

When you update context engineering for Claude 5-class models, the goal is not fewer words—it’s fewer unnecessary constraints.

A practical checklist:

• Trim global prohibitions. Replace absolute “never” rules with style principles tied to surrounding code.
• Move situational logic into skills. Use progressive disclosure so verification and review aren’t always loaded.
• Treat tool interfaces as documentation. Tool parameter structure and constraints often beat examples.
• Defer heavy definitions. Use tool search / deferred loading patterns so the context window contains only what’s needed.
• Organize into a load-on-demand structure. Prefer a file tree of guidance over a single monolithic repository of everything.

Closing thought: context is a system, not a wall of text

The most useful takeaway from the “new rules” is surprisingly human: advanced models don’t need as many “do nots” to behave correctly. They need clarity about where to look, what tools are available, and which principles never change.

When context engineering shifts from commanding to curating, your agent stops feeling like a brittle machine and starts behaving like a thoughtful collaborator—one that can handle the messy, real variation of codebases.