Context engineering for Claude 5: what changes for teams

What did Anthropic change in Claude Code's system prompt?

It deleted most of it. The opening claim: “We removed over 80% of Claude Code's system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on our coding evaluations.”

The reason given is not token cost. It is that instructions collide. When the system prompt, a skill, and the user each say something slightly different, “Claude must think more carefully about these overlapping and conflicting messages before deciding what to do.” Rules written to correct an older model's habits become friction for a newer one that did not have the habit.

This follows Anthropic's September 2025 essay on effective context engineering, which set the goal as “the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome.” The July post is the same idea applied to their own prompt, with a number attached.

What should go in CLAUDE.md now?

Less. The post's advice is specific: “Keep your CLAUDE.md lightweight and briefly describe what your repo is for, but spend most of the tokens on gotchas inside of the codebase.”

A gotcha is something the model cannot infer from the tree. That the test command is pnpm test is inferable from package.json. That payment webhooks must dedupe on the provider's event ID before any write, because of a double refund your team argued about in #eng-payments, is not. The first line is noise. The second is the reason the file exists.

The docs back this with tooling. /doctor now proposes trims for a checked-in CLAUDE.md: it cuts directory layouts, dependency lists and architecture overviews Claude can derive, and keeps “pitfalls, rationale, and conventions that differ from tool defaults” (Claude Code 2.1.206 or later, per the memory docs, checked 2026-09-23).

Judgment over rules: what does that look like?

The post shows an old line from Claude Code's own prompt. It told Claude to default to writing no comments and never to write multi-line comment blocks, one short line at most. Its replacement: “Write code that reads like the surrounding code: match its comment density, naming, and idiom.”

The first is a rule that is wrong wherever the codebase disagrees with it. The second tells the model what to look at and trusts it to look. For team files the move is the same. “Never use any” is a fine rule. “Always put handlers in src/api/handlers/” is fine until the day someone moves them, after which it is a rule that fights the code.

The post also warns off examples: “giving examples actually constrains them to a certain exploration space.” Where you need precision, it prefers code: “Generally you should prefer files that are in code as it provides clear, high-fidelity instructions to Claude in a language it knows very well.” A test that fails on a missing dedupe check says more than a paragraph about idempotency.

What is progressive disclosure in Claude Code?

Loading detail only when the task needs it. The post: “Use progressive disclosure heavily, for example if you have several unique instructions on how to verify your work, create a verification skill and reference it from your CLAUDE.md.” Claude Code itself does this with tools: some are “deferred loading,” so the agent searches for their definitions before it uses them.

In practice there are three layers. CLAUDE.md is always on. Path-scoped rules in .claude/rules/ arrive when Claude reads a matching file. Skills send a name and description every turn and the body only when invoked. The trade is that anything behind a trigger can be missed when the trigger does not fire; which layer suits which rule is laid out in CLAUDE.md vs skills vs hooks.

Does auto memory replace CLAUDE.md?

For personal learnings, yes. The post: “We used to encourage users to save things to Claude's memory, by using the # hotkey to write to their CLAUDE.md automatically. Instead, Claude now automatically saves memories that are relevant to the work and to you.”

For the team, no, and the docs say why. Auto memory lives in ~/.claude/projects/<project>/memory/. It “is machine-local” and its files “are not shared across machines or cloud environments.” The first 200 lines or 25KB of its index load each session. Claude writes it; no one approves it.

What does this leave for teams?

The post is written for one developer and one model, and for that reader it is complete. A team has a problem it does not address: who decides what the team knows.

Follow the advice and you get a short committed file, plus one auto memory per engineer per machine. Five engineers, five memories, each learned from different corrections, none visible to the others, none approved by anyone. When your team reverses the webhook decision in Slack, the engineer who was in the thread corrects their Claude. The other four keep the old rule in memory, and Cursor never heard about the change at all.

• Minimal files push knowledge out of the repo, which is right, but somewhere else has to hold it.
• Judgment over rules works for style. It does not work for a decision the model has no way to infer, like a retention window your legal team set.
• Progressive disclosure needs someone to know which fact belongs to which task.
• Auto memory captures what one session learned and keeps it on one machine.

How to apply the post this week

• Run /doctor and accept the trims you agree with.
• Delete rules the current model follows without being told. Test by removing one and running a task that would have tripped it.
• Rewrite rigid style rules as “match the surrounding code” where the codebase already shows the answer.
• Move procedures into skills, and reference them from CLAUDE.md.
• Move must-never rules into hooks or permission rules.
• Read every instruction file on the path together, and delete one side of each contradiction.