Claude Opus 5 Prompting: Delete Before You Write

Two authoritative sources say opposite things about this model, and nobody has reconciled them.

Anthropic's own prompting documentation states that Claude Opus 5 "completes full tasks rather than leaving stubs or placeholders." Developers who switched on day one reported the exact opposite — that it stops early, declares itself finished, and argues when you push back.

Both are true. And the thing that reconciles them is the single most useful fact about Claude Opus 5 prompting: this model follows your constraints far more literally than any Claude before it. The instructions you wrote to stop a weaker model from going off the rails are now actively suppressing work you wanted done.

So the migration is not a rewrite. It's a deletion, in a specific order, and the shortest useful version of it is this: delete verification instructions, delete scope-limiting hedges, demote everything long into files that load on demand, and re-run your effort sweep from high downward instead of xhigh upward.

I'll show you exactly how I found that in my own setup — including a contradiction sitting on two specific lines of a 98,733-character instruction file I wrote myself, and never noticed until I went looking with grep.

The 80% Cut, and What It Actually Signals

On July 24, 2026 — launch day — Thariq Shihipar of the Claude Code team published new context engineering guidance alongside the model. The number that traveled: Anthropic removed over 80% of Claude Code's system prompt for Opus 5 and Fable 5, with no measurable loss on their coding evaluations.

The example they published is worth reading twice, because the delta is the whole lesson.

Old:

"In code: default to writing no comments. Never write multi-paragraph docstrings or multi-line comment blocks — one short line max."

New:

"Write code that reads like the surrounding code: match its comment density, naming, and idiom."

Same intent. A fraction of the tokens. But token count is the least interesting part of that swap.

Look at what the old rule was. It was a blunt instrument written to prevent a specific worst case — a weaker model burying a function under a wall of generated docstrings. Anthropic's team knew the rule would sometimes be wrong. They shipped it anyway, because a rule that's wrong 20% of the time beat a model that produced unusable comments 40% of the time.

That trade has now flipped. And the rule that used to be a net positive is now a net negative, because it fires in the 20% of cases where it's wrong and adds nothing in the 80% where the model would have gotten it right unprompted.

Anthropic framed the change as a set of shifts. The full list, from their guidance:

I covered the mechanics of auditing that scaffolding in my Claude Code doctor skill audit — that piece is about the tool that finds the bloat. This one is about what to do with the sentences once you've found them, which turns out to be a different and harder problem.

Because here's what the coverage of that 80% figure keeps missing.

Why "It Stops Early" and "It Finishes Everything" Are the Same Bug

Go back to the contradiction in the opening, because resolving it changes how you write every instruction from here on.

Anthropic's Opus 5 prompting guide contains this line, in the section on code review:

"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."

Read that carefully. It is not a note about code review. It's a confession about the model's general disposition.

On Opus 4.8, "be conservative" was a soft nudge. The model weighed it against everything else in the prompt and mostly produced whatever the task actually needed. On Opus 5, "be conservative" is an instruction that gets followed. So the developer who wrote it eighteen months ago to stop a chatty model from flagging every unused import now gets a review that misses real bugs — and reports that Opus 5 "stops early."

The model didn't stop early. It did what you said.

This is the mental model I'd hold above every other piece of Claude Opus 5 prompting advice: your prompt's failure modes have inverted. On older models, the risk was that your instructions were too weak to steer the output. On this one, the risk is that they're strong enough to steer it somewhere you no longer want to go.

Every hedge you added is now load-bearing. "Only if necessary." "Keep it minimal." "Don't over-engineer." "Report only what's critical." Each of those was insurance against a model that over-produced. Each of them now caps a model that would have calibrated on its own.

The argumentativeness developers reported fits the same frame, though I want to be careful here — I could not verify that particular claim against any primary source, and I'll come back to what I couldn't confirm. But the mechanism is coherent: a model that treats your constraints as binding and also has better independent judgment will push back when the two disagree. That reads as resistance. It's closer to a conflict report.

Which raises an uncomfortable question about your own files. How many contradictions are actually in there?

I decided to count mine.

What I Found in 98,733 Characters of My Own Instructions

My content system runs on a single agent definition — an inline system prompt covering brand voices, article architecture, SEO rules, publish gates, and two scoring rubrics. It was written against Opus 4.x, in the era when exhaustive upfront instruction was how you got consistent output.

Here's what it measures, on this machine, today:

$ claude --version
2.1.220 (Claude Code)

$ wc -w -c .claude/agents/aria.md
   15018   98733 .claude/agents/aria.md

15,018 words. 98,733 characters. Roughly 24,700 tokens, loaded before the agent reads a single word of the actual task.

For scale, my two CLAUDE.md files — the ones every migration guide tells you to go slash — total 953 words and 6,898 characters between them. About 1,700 tokens. The file nobody tells you to check is fourteen times larger than the two everyone does.

But size is the boring finding. The interesting one came from counting instruction types:

Sixty-four prohibitions. Eighty-six checkboxes. In a file whose entire job is to produce blog posts.

Under the old rules that was defensible — every one of those lines was added because something went wrong once. Under Opus 5's disposition toward literal compliance, that file is 64 opportunities to suppress work I wanted done.

Then I found the actual contradiction.

The word-count rule that says two different things

I grepped for the word-count rule expecting one canonical statement. I found nine:

$ grep -n "3,000\|3000" .claude/agents/aria.md
225:**Length:** 3,000–6,000+ words
231:**Length:** 3,000–5,000+ words
238:**Length:** 3,000–5,000+ words
252:**Length:** 3,000–6,000+ words
266:**Length:** Preserve existing word count floor (3,000+)...
464:**Word Count:** Minimum 3,000 words. No hard upper limit...
1012:- [ ] Body word count ≥ 3,000 (or ≥ cluster floor of 2,000)...
1189:5. **Never** go below 3,000 words
1249:- [ ] Word count: 3,000+ (as long as every section earns its place)

Now put line 1189 next to line 275, which I'd written months apart:

• Line 1189: "Never go below 3,000 words"
• Line 275 (cluster expansion posts): "Length: 2,000–4,000 words"

One line says never below 3,000. Another explicitly authorizes 2,000. A third (line 1012) splits the difference with a conditional floor. All three are in the same file, all three are stated with the same authority, and no line tells the model which one wins.

That is precisely the failure mode Anthropic described: layers of instruction that contradict each other, forcing the model to burn attention resolving the conflict rather than doing the work. On an older model that resolution mostly landed somewhere reasonable. On a model tuned toward literal compliance, it's a coin flip — and I'd have no way to know which side came up except by reading the output closely enough to notice.

The FAQ placement rule was the same story in miniature: ten separate mentions across the file, of which four are the same instruction restated in slightly different words. Repetition was a reinforcement technique. It's now a consistency liability, because every restatement is a chance to drift.

None of this was carelessness. Every one of those lines solved a real problem on the day it was written. That's exactly why the file grew — and exactly why nobody audits it, because each addition felt like an improvement.

The Four-Minute Audit You Can Run on Your Own Stack

Before changing anything, measure. These are the exact commands, and they work on any Claude Code setup.

Step 1 — size the whole stack, not just CLAUDE.md.

# Memory files everyone checks
wc -w -c ~/.claude/CLAUDE.md ./CLAUDE.md

# Agent definitions almost nobody checks
wc -w -c .claude/agents/*.md

# Skill bodies (these load on invocation, but bloat here still costs)
wc -c ~/.claude/skills/*/SKILL.md | tail -1

If any single file clears ~40,000 characters, that file is your problem, whatever the guides told you to look at first.

Step 2 — count your prohibitions.

F=.claude/agents/aria.md
echo "Never:   $(grep -io 'never' $F | wc -l)"
echo "Always:  $(grep -io 'always' $F | wc -l)"
echo "MUST:    $(grep -o 'MUST' $F | wc -l)"
echo "Do NOT:  $(grep -io 'do not\|don.t' $F | wc -l)"

There's no universal threshold here, and I'd distrust anyone who gives you one. What the count is for is comparison: run it before and after your migration. If the number doesn't fall substantially, you rearranged furniture instead of removing it.

Step 3 — find the contradictions. This is the highest-value step and the one no tool does for you. Pick the five or six rules you consider load-bearing — word count, tone, output format, whatever governs your domain — and grep each one:

grep -n "3,000\|3000" $F        # my word count rule
grep -n -i "faq" $F             # my FAQ placement rule
grep -n -i "schema\|frontmatter" $F

Any rule appearing more than twice deserves a read. Any rule stated with different numbers in different places is a live contradiction, and it's costing you output quality right now, on every run.

Step 4 — get a real token count. Everything above is a character estimate. Run /context in a live session for the actual breakdown across system prompt, tools, MCP, memory files, and skills. Character counts divided by four are a serviceable heuristic and a bad thing to make decisions on. That distinction matters more than it sounds, and it's the same discipline I applied when working through Claude token limits and context rot.

Now for the part that actually changes your output.

The Three-Pass Migration: Delete, Demote, Rewrite

Do these in order. The order matters, because pass one is free and passes two and three are not.

Pass 1 — Delete outright

These categories go straight in the bin. No replacement, no rewrite.

Verification instructions. Anthropic's guidance is unambiguous: "If your prompt contains explicit verification instructions ('include a final verification step for any non-trivial task,' 'use a subagent to verify'), remove them: instructions like these cause over-verification on Claude Opus 5, and removing them reduces wasted tokens with no loss in quality."

That includes harness-level scaffolding, not just prompt text. If your pipeline has a separate verification stage bolted on after generation, that stage is now redundant work you're paying for twice.

Self-correction nudges. "Double-check your answer." "Re-verify before responding." Same mechanism, same outcome — these compound with behavior the model already has.

Instructions telling the model not to think. This one is a genuine gotcha. Per the docs, if your system prompt contains a rule instructing the model not to think or not to reason, remove it — that instruction increases the leakage of <thinking> tags into visible output when thinking is disabled. The rule causes the symptom it was written to prevent.

Delegation encouragement. Opus 4.8 under-reached for subagents, so a lot of us added "delegate more" guidance. Opus 5 reaches freely. That instruction now multiplies your cost, because each subagent re-establishes context from scratch.

Scope hedges you no longer need. Every "be conservative," "only if necessary," "keep it minimal," "report only critical issues." Read each one and ask: was this written to stop a weaker model from over-producing? If yes, it's now a cap.

I want to flag what pass one did to my own file, honestly: it isn't the biggest reduction. Deleting the verification and delegation language cut maybe 400 tokens out of 24,700. The value isn't the token count — it's that those 400 tokens were the ones actively steering output in the wrong direction.

Pass 2 — Demote to progressive disclosure

Everything long that's only relevant sometimes moves out of the always-loaded layer and into a file that loads when the work requires it.

In my case that's the four brand voice profiles, the SEO ruleset, and the publish-gate rubric. When I'm writing a security post for one brand, the other three brand voice sections are pure overhead — loaded, paid for, and irrelevant. Split into referenced sub-files, the root instruction states the goal and the constraints; the specifics arrive on demand.

Anthropic's guidance on skills says the same thing from the other direction: split lengthy skills across multiple files rather than maintaining one central repository of every known practice.

This is where the real reduction lives, and it's a restructuring job rather than an editing one. Budget an afternoon, not ten minutes. It's the same context-over-configuration argument I made in my Claude Code token management playbook — and it got a lot stronger the day Anthropic shipped a model built around it.

Pass 3 — Rewrite rules as judgment

What survives passes one and two gets converted from constraint to intent. The pattern:

That third row is the point. Not every rule should become judgment. Anything that's a genuine interface contract — a required field, a schema, an exact output format your CMS parses — stays a rule, because "use your judgment about how many tags to emit" produces a broken pipeline, not a better article.

The test I've settled on: if a downstream system breaks when the model gets it wrong, keep the rule. If a human would just think the output was slightly worse, convert it to intent and let the model calibrate.

For the constraints you do keep, Anthropic publishes replacement blocks worth using verbatim. For scope control:

Deliver what was asked, at the scope intended. Make routine judgment calls
yourself, and check in only when different readings of the request would lead
to materially different work. If the request seems mistaken or a better
approach exists, say so in a sentence and continue with the task as asked
rather than quietly narrowing, widening, or transforming it. Finish the whole
task, and stop short of actions that are clearly beyond what was asked.

For subagent spend, if your harness supports delegation:

Delegate to a subagent only for large tasks that are genuinely independent and
parallelizable, such as a wide multi-file investigation. Do not delegate work
you can finish yourself in a handful of tool calls, and do not use subagents to
verify or double-check your own work. If one subagent can complete the task,
use one rather than several, and keep spawn counts low.

Notice what both blocks have in common — they describe a disposition and give the model room to apply it. Neither enumerates cases.

One setting is left, and it moved in a direction almost nobody has noticed.

The Effort Recommendation Quietly Reversed

Put the official guidance for consecutive Opus releases side by side. I haven't seen anyone do this, and it's the clearest evidence that the prompting model genuinely changed rather than being tweaked.

Two consecutive releases told you to start at the second-highest setting and justify coming down. Opus 5 tells you to start at the default and reach for the two lowest settings freely. The docs add an instruction that reads like it was written for people exactly in your position: "If you carried effort settings over from an earlier model, run a fresh effort sweep on your evals rather than reusing them."

There's a mechanical trap sitting under this, and it's the most common misconception I've seen about Claude Opus 5 prompting.

Lowering effort will not shorten Opus 5's responses. Effort controls thinking volume, not visible output length. If your model is too verbose and you drop from high to medium expecting shorter answers, you'll get less thinking and the same wall of text — which is the worst of both trades.

Verbosity is a prompting fix. The docs give you the instruction:

Keep responses focused, brief, and concise. Keep disclaimers and caveats short,
and spend most of the response on the main answer. When asked to explain
something, give a high-level summary unless an in-depth explanation is
specifically requested.

And for a long system prompt, they recommend pairing it with a short reminder near the end:

<tone_preference>
Keep outputs reasonably concise.
</tone_preference>

Files written to disk are a separate axis again — reports and Markdown documents run longer on this model independent of conversational verbosity, and need their own length calibration instruction if your product generates documents.

Three separate controls, three separate levers, and reaching for the wrong one is why a lot of people concluded the model was worse. The cost consequences of getting this wrong compound fast, which is the throughline of my Opus 5 vs Fable 5 cost testing — the model that spends more tokens per task isn't the one with the higher sticker price.

What Not to Trim — The Case Against Over-Correcting

This is where I'd push back on most of the coverage, including some that's more enthusiastic than the evidence supports.

That 80% figure was measured on Anthropic's evals, not your repo. Claude Code's system prompt describes a general-purpose coding agent operating across arbitrary codebases. It is exactly the kind of prompt where model judgment substitutes well, because the model has seen a million repositories that look like yours. Your instruction file probably encodes things it hasn't seen — a client's naming convention, a compliance requirement, a deployment quirk that will bite you at 2 AM.

Anthropic's own CLAUDE.md guidance points at this: briefly describe what the repo is for, then spend the remaining tokens on genuine gotchas — the things Claude can't infer from your file tree. The corollary matters as much as the rule. Content that is genuinely non-derivable is exactly the content you should keep, and trimming it because a blog post told you prompts should be short is a straightforward downgrade.

Legacy codebases carry more risk from over-trimming than from bloat. A repo with unusual conventions, a half-finished migration, or a framework used against its grain gives model judgment less to work with. Trim aggressively there and you don't get faster output — you get output that looks right and fails review, which is more expensive than the tokens you saved.

The right unit of measurement is review overhead, not token count. If your context shrank 60% and the amount of time you spend fixing output went up, you lost. Trim in increments. Watch what comes back. Add rules back one at a time, and only the ones that earn their place.

I'd apply that same skepticism to my own file. I cut it substantially, and I have not yet run enough articles through the restructured version to tell you the quality held. Anyone claiming a clean before/after on this two weeks after launch is telling you a story.

What I Measured, What I Sourced, and What I Couldn't Confirm

The gap between "I read this" and "I watched this happen on my machine" is the whole reason to read a practitioner write-up instead of a press release. So, precisely:

Measured first-hand, on August 1, 2026: every number about my own setup. claude --version returning 2.1.220. The 98,733-character agent file and 15,018-word count. The 64 prohibitions, 86 checklist items, 1,343 lines. The nine word-count statements and the contradiction between lines 1189 and 275. The ten FAQ mentions. All reproduced from wc and grep on this machine, with the commands above so you can run the same audit on yours.

Sourced from primary documentation, read rather than recalled: the verification-deletion guidance, the literal-instruction-following note in the code review section, the scope and subagent replacement blocks, the conciseness instructions, the thinking-tag leakage behavior, and the full effort recommendation tables for Opus 4.7, 4.8, and 5.

Sourced from Anthropic's engineering post: the 80% reduction figure, the before/after comment rule, and the six shifts table. That's a vendor claim about a vendor benchmark. It's credible and it's still a vendor claim.

Reported but not verified: that developers found Opus 5 argumentative, that it declares completion prematurely, and that it was more error-prone than Fable 5 on complex legacy tasks in the first days. I could not corroborate any of these against a primary source. The mechanism I proposed — literal constraint-following surfacing as apparent resistance — is my reasoning, not a documented finding. Treat it as a hypothesis that fits the evidence, and hold it loosely.

Not verified at all: any claim that this migration improves output quality on your stack. I restructured mine. I don't have enough runs through it to prove the quality held, and I'd rather say that than quote a number I invented.

If you want the benchmark side of this properly picked apart — including the evals Opus 5 loses that nobody screenshots — that's in my Claude Opus 5 benchmarks breakdown.

The Sentence That Was Wrong for Months

Line 1189 of my agent file says "Never go below 3,000 words." Line 275 says cluster posts run 2,000 to 4,000.

I wrote both. I read that file more times than I can count. And I found the contradiction not by reading it again, but by running a four-character command against it — because reading a document you wrote yourself is the least reliable way to audit it. Your eye slides over your own intent.

That's the actual argument for auditing your Claude Opus 5 prompting stack now rather than when something visibly breaks. Nothing in that file errors. Nothing warns. It just quietly gives a model that takes you literally two irreconcilable orders, and the model picks one, and you read the output and think the model had an off day.

Tonight, open your largest instruction file and run grep -c -io 'never' against it. Then pick the one rule you'd defend hardest and grep for that. You'll be done in four minutes, and I'd take a bet on what you find.

The question isn't whether your prompts are too long. It's whether they still say what you meant when a model finally started listening.

Run the Audit, Then Steal the Patterns

The four-minute audit above tells you what to delete. What to write in its place is the harder half, and the fastest way to calibrate is reading prompts that already survived contact with real work. I keep my working library public — 854 prompts, each one built, used, and revised against actual output rather than imagined use cases. Browse the prompt library, find the category closest to your stack, and compare how those prompts state constraints against what your instruction files do today. The difference you notice is your migration plan.