What this article covers: Anthropic's official guidance for the Claude 5 generation (Opus 5 / Fable 5) is "fewer rules, trust the model's judgment." This is a procedure for auditing the custom rules (CLAUDE.md / rules files) you accumulated for older model generations against what the product itself loads, and deciding for each rule: keep, fix, or retire.
If you've been using Claude Code for a while, you probably share these worries:
- You wrote CLAUDE.md files and rules to compensate for older models' weaknesses, and you have no idea whether they still help with Claude 5
- The official guidance now says "cut your rules," but you can't tell which of your rules are the ones to cut
- Deleting everything at once and watching behavior degrade is scary, so you don't touch any of it
On 2026-07-25 I ran this audit on my own ~/.claude harness (my set of custom configuration: CLAUDE.md, rules files, agent definitions) and cut the resident rules — the part auto-loaded into every session — from 5,789 down to 2,463 words (measurement details at the end). This article documents the cross-checking procedure I used, in a reproducible form. The takeaway is not the reduction itself but the decision procedure: on what evidence, which rules, and how to dispose of them.
Background: the official guidance on rule-writing changed
On 2026-07-24 (the day Opus 5 launched), Anthropic published The new rules of context engineering for Claude 5 generation models. Two points matter here.
First, Anthropic itself deleted more than 80% of Claude Code's system prompt:
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.
Second, the post spells out the shift in context engineering as six Then → Now pairs.
| Then (older generations) | Now (Claude 5 generation) |
|---|---|
| Give rules | Trust judgment |
| Give examples | Design interfaces |
| Front-load everything | Progressive disclosure |
| Repeat yourself | Simple tool descriptions |
| Write memory into CLAUDE.md | Auto-memory |
| Sparse specs | Rich reference material |
The post names a concrete harm of over-instruction: conflicting instructions. System prompt, skills, and user instructions collide, so that "leave documentation as appropriate" and "DO NOT add comments" coexist in the same request.
In other words, the reason to cut rules is not just token savings. The problem is that your custom rules conflict with the product's own instructions, and you are forcing the model to resolve the contradiction. From here, the procedure is about finding which of your rules are the conflicting ones.
Premise: the ground truth is the system prompt and tool descriptions
What actually reaches the model in the same context as your custom rules is the system prompt and the tool descriptions. That is the ground truth to audit against, and the first step is simply to read it. Official docs and blog posts state recommendations, but they are not loaded at inference time.
The meaning of a mismatch changes with this distinction, so let's name the two layers.
| Layer | Contents | Loaded at inference time? | Name of the mismatch |
|---|---|---|---|
| Runtime layer | System prompt + tool descriptions | Yes (loaded into context alongside your rules) | Conflict (the model is forced to resolve a contradiction) |
| Guidance layer | Official docs and blog posts | No | Drift (you've merely diverged from official recommendations) |
A mismatch only qualifies as a conflict when both sides are in the same context (a tool description is only loaded in sessions where that tool is available).
All examples below come from my own
~/.claudeharness (Claude Code 2.1.220, audited 2026-07-25 to 07-26).Step 1: capture the current runtime layer from a live session
The first task is to know exactly what your custom rules are sharing context with. There is a trap here: the runtime layer is injected from outside your config repository too, so no amount of reading ~/.claude shows you the whole picture.
A concrete example. My session's system prompt contained this resident line:
"Do not call the AgentTool unless the user requested it"
Yet grepping ~/.claude finds this string in no file at all (I haven't identified the source; I suspect the harness itself or a plugin, but couldn't confirm). If you only audit config files, you miss this class of instruction.
So capture from a live session instead. There are two techniques.
For tool descriptions, get the real thing. Ask Claude Code to print the target tool's description:
Quote the description of the EnterPlanMode tool verbatim. Do not summarize.
For the system prompt, have the session quote itself. This is self-reported, so say "verbatim" explicitly to prevent summarizing:
From the system prompt currently loaded, quote verbatim the instructions
about plan mode / commit messages / scope handling.
The trick is to ask per theme. "Print everything" is too long and summaries creep in. Build the theme list from your own rules: open every custom rules file (rules / CLAUDE.md) first, assign each instruction to a theme (planning, commits, review, scope, ...), then query the runtime layer theme by theme. That way you at least eliminate audit gaps on your side of the comparison.
Two caveats. First, gaps in the other direction — runtime instructions you don't know exist — can't be fully caught by this procedure, so zero detections means "this question found nothing," not "no conflicts." Second, both capture techniques are model-mediated self-reports, with no guarantee of exactly matching the actual input. Treat the captures as a screening pass; before acting on a rule's disposition (retire / invert), confirm the same wording reproduces in a separate session.
Step 2: cross-check against your rules and sort into 3 categories
Cross-check the captured runtime layer against your custom rules and sort each mismatch into three categories.
| Category | Meaning | Detected in my harness |
|---|---|---|
| Conflict | An instruction or claim that contradicts the runtime layer is loaded at the same time | 2 |
| Redundant | The runtime layer already says nearly the same thing | 1 |
| Drift | Diverged from guidance-layer (official docs) recommendations | 3 |
Conflict example 1: a no-plan-mode rule
My planning.md contained this, written as a countermeasure to older generations' habit of not planning:
On direct implementation instructions, execute immediately. Do not enter plan mode.
Meanwhile, the EnterPlanMode tool description loaded in the same context (Claude Code 2.1.220) says:
"Prefer using EnterPlanMode for implementation tasks unless they're simple."
"If unsure whether to use it, err on the side of planning"
Two instructions pointing in exactly opposite directions were loaded into the same context, and the model was silently picking one every time.
Conflict example 2: a rule referencing a ghost setting
The second one was a nastier pattern. Background: by default, Claude Code appends a Co-Authored-By: Claude ... trailer to commit messages — the attribution that shows Claude as a co-author on GitHub. On whether to emit that attribution, my git-workflow.md said:
Note: Attribution disabled globally via ~/.claude/settings.json.
But checking the actual settings.json, the relevant key (includeCoAuthoredBy) did not exist:
python3 -c "import json; print('\n'.join(sorted(json.load(open('settings.json')).keys())))"
# includeCoAuthoredBy is not in the output
Whether I deleted the setting at some point or the note was wrong from day one, there's no way to tell anymore. What I can say for certain: a rule cannot detect that its own justification has vanished. Code errors out when its referent disappears; a rule keeps asserting "disabled" while sitting in context, contradicting the runtime layer's instruction to append the Co-Authored-By trailer to commit messages.
Strictly speaking, this line is not an instruction ("don't add the trailer") but a (false) statement of fact ("already disabled"). But since it kept riding along in the same context as information contradicting a runtime-layer instruction, I counted it on the conflict side.
How the unresolved conflict was actually being resolved (a model-dependent observation, with limits)
Digging through session logs from the period when this ghost-setting conflict sat unresolved, I found an interesting split. Same Claude Code version (2.1.220), same rules: two Opus 5 sessions added the trailer to commits, one Fable 5 session did not. Within each session, behavior was 100% consistent.
So when you leave contradictory instructions in place, how they get resolved is up to the model — and when the model changes, the behavior can change too.
The limits, stated plainly: this is a natural observation, not a controlled comparison (5 commits with differing tasks and user instructions). The most I can claim is "likely model-dependent." Also, the observed difference — attribution — is harmless; whether conflicts with real consequences split the same way is unverified.
Redundancy example: a scope-adherence rule
Separate from conflicts, some rules had simply become unnecessary to say. My custom rule "when a scope is specified, adhere to it strictly" exists almost verbatim in the Claude 5 generation system prompt:
"The requested scope is the deliverable — don't quietly narrow, widen, or transform it."
No collision, so the harm is small — but I was paying resident tokens to repeat what the product already says. It was exactly the official post's "Repeat yourself → Simple tool descriptions" shift.
Drift example: a confidence threshold for review
I detected three drift items. I'll cover one representative case here; the other two — the handling of pre-commit verification steps and the rule splitting review into a separate agent — get different verdicts, so they're covered in Step 3 and the pitfalls section respectively.
The representative case: my review-agent definition said "only report findings you are at least 80% confident in" (a number unrelated to the 80% system prompt reduction above). The official Opus 5 prompting guide warns against exactly this kind of suppression instruction, using it as an example (it does not mention the number 80% specifically):
If your review prompt says "only report high-severity issues" or "be conservative," the model may follow that instruction literally and report less; ask it to report everything and filter in a separate pass instead.
This is not a load-time conflict, but with the official docs explicitly saying the model may follow this kind of instruction literally and under-report, leaving it in place means dropped findings. I haven't verified how much damage it did on older generations, but since it's the exact pattern the current generation's docs warn against by example, I classified it as drift.
Step 3: don't treat "conflict = bad" — run each item through a decision frame
Once the three-way sort is done, decide dispositions. The important part: do not mechanically mark conflicts and drift for deletion. Some of your custom rules were written precisely to override product defaults on purpose. "Points the opposite way" alone cannot distinguish an accident from a deliberate choice.
I judged each item on four axes.
| Axis | Question |
|---|---|
| Intent | Did you write it to override the product default, or was it simply not conflicting at the time? |
| Evidence | Is there a record of why it was written — an ADR, an incident note? |
| Freshness | Does the product behavior it assumed (an old generation's weakness, etc.) still hold? |
| Expiry condition | Have you defined what would trigger revisiting this rule? |
Three example dispositions.
Retire (freshness expired): The no-plan-mode rule (conflict example 1) was a countermeasure to older generations' "start running without planning" weakness. In the Claude 5 generation the product itself now recommends planning; the premise is gone. There was no reason to keep it as an intentional override, so I retired it.
Retire (conflict + redundancy): Beyond the ghost-setting line (conflict example 2), git-workflow.md contained nothing but content the model and the runtime layer already cover — commit message format, how to write PRs. Fix the conflicting line and the rest is still redundant. So the whole file had no reason to exist, and I retired it.
Keep (intent and evidence alive): On the other hand, I kept my rule "run review in a separate agent process from the implementer." The official guide contains the line "do not use subagents to verify or double-check your own work," which at first glance collides with this rule.
But read in context, this is not a rejection of division-of-labor review. That line is one phrase in an example prompt developers can add to control subagent spawning, in a section about cost containment. The official premise is that Opus 5 verifies its own work without being told — explicit verification instructions just cause over-verification and should be cut — and that the new generation, which also delegates more, would otherwise reflexively spawn "just in case" double-check subagents and burn cost. That's the brake being illustrated. The same doc also positively cites the writer–verifier pattern — separating the writer from the verifier — as a strength of Opus 5.
My rule has two tiers. The base: never let review happen in the same context as the implementation (same-context review inherits the implementer's blind spots). On top of that, for important changes, a different model (in my case, Codex CLI) does the review, decorrelating the blind spots. The latter was an easy keep — cross-model review is a capability Claude Code itself structurally cannot provide no matter how much it evolves, so there is nothing for the product to absorb it into. The design decision is recorded in an ADR.
The former (separate-process review on the same model) may still overlap with the "added verification passes" the official guidance wants to suppress. This is the interpretive part: if Opus 5's self-verification turns out to solve even the blind-spot-inheritance problem, the base tier may become unnecessary. It stays — as a keep with an expiry condition: revisit when the premise changes.
Running this decision frame taught me one thing: rules with recorded evidence (ADRs, incident notes) are fast to judge, and the judgments are more confident. Having a record doesn't prevent retirement (the plan-mode rule had a known rationale and was retired anyway, on expired freshness). What the record changes is not the outcome but the cost of deciding. For rules with no recorded rationale, even the question "is it safe to delete?" turns into git log archaeology.
Pitfall: mechanically applying the official advice misdiagnoses
The official guide says verification steps added by legacy harness scaffolding are also candidates for removal. Applying that mechanically will misdiagnose.
My custom rules had an 8-item pre-commit Verify step (build / type check / lint / tests / secret scan / dependency audit / doc sync check / git status check). Taken literally, "cut verification steps" makes all eight look like deletion targets.
But what the official guidance objects to is instructions that increase the model's self-verification. Most of the eight items are deterministic command runs — builds, tests — that add zero model judgment. The axis is:
- The verification is done by a machine (command, hook) → fine to keep
- The verification is done by the model, on its own judgment → the official guidance's target; consider cutting
The other pitfall: cases where deletion isn't enough and you need an inversion. If you simply delete the "only report at ≥80% confidence" line, the section it lived in (a noise-suppression framework) survives and keeps pushing in the suppressive direction. I rewrote the section to: "Do not suppress by confidence. Report everything; the caller filters in a separate pass." An instruction whose correct direction has flipped must be rewritten in the opposite direction, not merely removed.
Results and numbers
The center of gravity is the procedure, but for reference, my harness before and after (measured with wc -w, resident total of CLAUDE.md + rules):
| Point in time | Resident words | Files |
|---|---|---|
| Before the audit | 5,789 | 20 |
| After (as of 2026-07-26) | 2,463 | 14 |
Note that I am not claiming "resolving the conflicts improved performance." My environment has no instrument for measuring the cost of contradiction-resolution; the quantitative case rests on Anthropic's measurement quoted at the top (80% deletion, no degradation). What this article demonstrates is not the effect but real examples of config drift, and a procedure for finding and disposing of it.
Summary: what you can do next
- Capture the runtime layer (system prompt + tool descriptions) from a live session. Reading your config repository alone doesn't show the whole picture
- Cross-check against your custom rules; sort into conflict / redundant / drift
- Don't treat "conflict = bad" — judge keep / invert / retire on the four axes of intent, evidence, freshness, and expiry condition
- Apply the official reduction advice with the distinction between model self-verification and machine verification
And one lesson to add from this round: when you write a rule, record its rationale and its expiry condition. I'll confess I wasn't doing this systematically either. Rules with an ADR (design decision record) took minutes to judge; rules without one turned into git log archaeology; and for the ghost setting, I couldn't even pin down when it disappeared. A rule cannot detect that its own justification has vanished — so whether you'll be able to judge your rules at the next generation change will be decided by the notes you leave now.
Postscript (2026-07-26)
The lessons from this article have already flowed back into my harness.
- Every resident rule file now carries
rationale:andreview-when:metadata, and my rules-audit skill rules-stocktake reads these fields during audits - The procedure in this article (collect the runtime layer → cross-check → judge with the decision frame) has been generalized into a skill called generation-audit, published as a standalone repo, so it can be re-run as-is at the next model generation change
Related links
- The new rules of context engineering for Claude 5 generation models — Anthropic official blog (2026-07-24)
- Prompting Claude Opus 5 — Claude Platform Docs — official recommendations on confidence thresholds, verification steps, and subagents
- generation-audit — this article's procedure packaged as a skill (standalone repo)
- rules-stocktake — resident-rules audit skill (now reads rationale / review-when metadata)
- github.com/shimo4228 — the author's GitHub (harness-related repositories)
Top comments (0)