Somewhere in your business there is a set of AI instructions nobody has reread since they started working. The custom GPT the sales team uses, the system prompt behind the support inbox, the CLAUDE.md instruction file in a developer's repository, the automation that rewrites product descriptions every night. They were written for the models of the day, and often written defensively: NEVER do this, ALWAYS do that, follow these nine steps in order. Anthropic now says, in its own documentation for the Claude 5 models, that instructions of that kind can make a newer model worse. Usually nothing throws an error. The output can just get flatter and more literal, and nobody connects it to a file written a year ago.
Instructions have a shelf life.
Anthropic says it most plainly in the Fable 5 guide, in a list of recommended changes for teams moving to the new model: "Skills developed for prior models are often too prescriptive for Claude Fable 5 and can degrade output quality."[3] A skill, in Anthropic's vocabulary, is a saved instruction file the model loads for a particular job. The sentence carries over to every saved prompt, assistant instruction and automation rule a business runs, because they are the same artifact: text written to steer a model, tuned against whichever model was current when someone wrote it. The guides describe Claude models only: if your custom GPT runs on another vendor's model, treat the audit below as a method to test, not as a finding about that model.
The mechanism is simple. Older models needed hand-holding, so people wrote it in. They spelled out the steps because the model skipped steps. They wrote "double-check your answer" because the model did not. They wrote "never use bullet points" because the model buried every answer in bullets. Newer models, by Anthropic's account, do these things on their own, and in places now lean the other way. The Opus 5 guide says the model "verifies its own work without being told to", and that explicit verification instructions "cause over-verification".[2] The Fable 5.1 guide says the model now uses bold less and reaches for lists less often, and tells you to remove anti-formatting rules or replace them with a rule about when a format fits.[4] An instruction that once corrected a weakness now pushes against a strength.
That is the business problem. A broken automation announces itself. A degraded one keeps running.
The one deletion to make this week.
Most of the audit is judgment. One part is not, and it comes first because it is about correctness rather than polish. The Fable 5 guide says that prompts, skills or harness instructions that tell the model "to echo, transcribe, or explain its internal reasoning as response text may trigger the reasoning_extraction refusal category", and that server-side fallback "doesn't retry requests declined with reasoning_extraction; that refusal is returned to you."[3] The Opus 5 guide now carries the same warning.[2] In plain terms: a line like "walk me through your reasoning at each step" does not just make the answer a little worse. It can get the request refused outright, with no automatic retry on another model.
Lines like that are common in prompts written a year or two ago, because asking a model to show its work used to help. The fix is a search, not a project. Go through every saved instruction for phrases that ask the model to narrate or replay its thinking: "your reasoning", "your thinking", "thought process", "out loud", "chain of thought", "show your work". Read each hit in context. A request for a one-line rationale, or for the assumptions the model made, is fine: that is a deliverable. A request to replay the reasoning itself is the line to rewrite. If your application really does need to see the reasoning, Anthropic's answer is to read the model's structured thinking output through the API, not to ask for it in the reply.
Keep the consequence, cut the method.
Past that one deletion, this is where a summary of the guides can go wrong, even a careful one: the relay that sent us to them did.[6] The tempting reading is a find-and-replace: strip every NEVER, every ALWAYS, every numbered list. That is not what Anthropic's pages say, and doing it can remove the lines that protect you.
Take the vendor's own example. Under "Add context to improve performance", the cross-model guide shows a weaker instruction and a stronger one:[1]
NEVER use ellipsesYour response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them.The stronger version still says never. What changed is that the rule now carries its reason, and the guide adds that the model "is smart enough to generalize from the explanation". The remedy for a hard rule is to add the why, not to soften the word. The same page still tells you to "provide instructions as sequential steps using numbered lists or bullet points when the order or completeness of steps matters."[1] Steps are not banned. Steps imposed where order does not matter are the problem, because they swap the model's breakdown of the task for yours.
So the audit question for each rule is narrow: does this line encode a consequence, or a method? The cross-model page also offers a test for the whole file: "Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too."[1]
What our own audit found.
We ran the audit on our own toolkit on 12 September 2026: 163 instruction files, about 200,000 words, most written earlier in the year against the previous generation of models. 116 of the live files are ones we wrote ourselves; the rest come from upstream projects, which we counted and left alone. Those 116 files hold 1,092 lines containing never, always, must or do not. A hand-coded random sample of 50 of those lines found 35 real instructions, the rest being descriptions, table cells and quotations. Scaled up, that is about 760 hard rules.
Roughly half the rules already said why, and those are fine. The rest split unevenly. About a quarter of the bare rules were guardrails: no invented figures, no client documents sent to hosted services without consent, no production merge without a human, nothing sent without approval, no guaranteed-ranking claims. Those keep the word never. They need the consequence written next to them, because a model that knows a rule exists to prevent a privacy breach applies it more sensibly at the edges than one that only knows the rule exists. The other three quarters were method: always produce all six sections, do not show code right away, always preserve usability. Those are the cut-or-explain candidates, and they are the prescription the Fable 5 guide warns about.
Two findings mattered more than the counts. First, the densest files earned their density. The two files with the most rules per word were ordered pipelines where the wrong order had already shipped a bug, and nearly every rule in them carried its reason inline. That is the pattern the cross-model page endorses. Second, the bare rules came from one place. The template we use to create new tools had a mandatory "Hard rules" section and said nothing about stating a consequence, and 57 live files had inherited the block. Fixing the template stopped the pattern from spreading. The files already written needed a pass of their own.
What one careful pass changed.
We ran that pass the same day on the eleven files we wrote that had the most bare rules (two more on the list are maintained upstream and were left alone). The instruction for each file was one sentence long: for every bare rule, write the consequence or delete the line, and keep numbering only where order matters. Bare rules were counted by eye before and after.
Read the length column the right way round. The pass made the files longer, 8% overall, and that is the point. What the guides ask for is prompts that say why, and those run longer. The largest growth was in the two pen-test files, which are mostly guardrails and stated almost no reasons before the pass: the added words are the reasons. A rewrite that comes out shorter and tidier should make you suspicious. The usual failure of a bulk rewrite is a set of files that reads better and has quietly lost its guardrails.
Where the vendor's guides disagree.
One more reason not to treat these pages as a rulebook to copy: two of them, both still listed among Anthropic's current models, give opposite instructions on the same question. The question is verifier subagents, meaning a second model instance asked to check the first one's work.
| Guide | What it says about verification |
|---|---|
| Opus 5 | Remove explicit verification instructions, including "use a subagent to verify"; removing them "reduces wasted tokens with no loss in quality". Its sample prompt adds: "do not use subagents to verify or double-check your own work."[2] |
| Fable 5 | "Make self-verification explicit in long-run prompts. Separate, fresh-context verifier subagents tend to outperform self-critique."[3] |
The relay we watched folds the two into one rule (delete the double-checks), which is the Opus 5 half applied everywhere.[6] Apply it to a long autonomous job on Fable 5 and you remove something Anthropic recommends for that model. The pages themselves point the way through. The cross-model guide says that where a technique names a specific model, you should "treat it as measured on that model and re-check it against your own evals before applying it to another."[1] The two cases also differ in shape: a short, bounded task getting a redundant second pass, against a long run where errors pile up and a checker with fresh context catches what self-review misses. That last point echoes our note on AI judges: a model checking its own output is the least independent checker you can hire.
Our working read: on a short, bounded task on Opus 5, drop the extra verifier, as its guide says; on a long autonomous run on Fable 5, keep it and give it fresh context, as that guide recommends. On any other model, test both. Treat that as a reading rather than a rule. It also makes the larger point: these pages are migration notes for specific models, written by a vendor that revises them without notice. Test what they tell you on your own work.
What this does not prove.
The four guides publish no numbers. "Reduces wasted tokens with no loss in quality" (the Opus 5 guide, on removing verification instructions)[2] and "drop substantially with no measurable change in task success" (the Fable 5.1 guide, on unrequested additions once a scope instruction is added)[4] are claims about Anthropic's internal evaluations, with no figures shown. They are credible as a direction, and the pages themselves tell you to check them against your own evals. The same vendor also says Opus 5 "performs well out of the box on existing Claude Opus 4.8 prompts": the degradation warning is strongest in the Fable 5 guide, and how much it bites depends on the model you run.[2]
Our audit counts instructions, not outcomes. We measured how many rules lacked a reason and what one pass did to them. We did not measure whether our tools do better work afterward. That needs a before-and-after on real tasks, which we have not run.
The 46% is a sample estimate. It rests on 35 instructions found in a random sample of 50 lines, with a margin of about ±16 points. "Roughly half" is the finding; the decimal is not.
Our files are not yours. About 160 files written by one team, mostly for development and marketing operations. A business with three saved prompts will see a different mix. The questions to ask of each line are the same.
Model names date fast. Everything here describes Opus 5, Fable 5 and Fable 5.1 as documented on 12 September 2026. Since then the cross-model page has added guides for Opus 5.5 and Sonnet 5.5, which this note does not cover.[1] Each release brings its own migration note, and some of today's correct instructions will end up on one of those lists.
reasoning_extraction passage no longer carried its earlier "elevated fallbacks" wording; quoted here as rechecked. Section quoted: recommended scaffolding changes. If your team runs saved prompts, custom assistants or automations written before this year's models, the contact form is the fastest way in. Tell us what you run, and we will send back a written read on where to start the audit, free.