Anthropic's new guidance for Claude Opus 5 and Fable 5.1 flips old prompting rules. Here's what to remove and what to add instead.
Why did prompting rules change for Claude Opus 5 and Fable 5.1? #
Anthropic’s own documentation for Opus 5 and Fable 5.1 says the models perform best with a complete task specification handed over up front, not a step-by-step script. Older prompting habits, breaking tasks into numbered steps, telling the model to double-check its work, adding words like “always” or “never” in caps, were built for models that skipped instructions unless you spelled everything out. The newer models were trained to handle a job end-to-end, so heavy scaffolding now narrows their judgment instead of guiding it, and Anthropic explicitly warns that skills and prompts written for older models “can degrade output quality” on Fable 5.1.
TL;DR #
- Step-by-step instructions now backfire : Anthropic’s Opus 5 guide says the model performs best when given the complete task up front and left to run, rather than walked through a numbered sequence.
- Old skills need a rewrite, not a patch : Anthropic directly advises reviewing prompts and skills written before Fable 5.1 and stripping out prescriptive instructions that used to be necessary.
- Context and intent matter more than steps : giving the model the “why” behind a task, who it’s for, what the output enables, lets it make the dozens of small judgment calls a task usually requires.
- Defining “done” replaces telling it what to do : because Opus 5 tends to expand scope on its own, adding charts, dashboards, or extra steps you didn’t ask for, you now need to state length, format, and stopping conditions explicitly.
- Hard constraint language over-triggers the model : words like “critical,” “must,” or “always” in all caps now cause over-triggering rather than compliance, and Anthropic’s fix is plain instructions like “use this tool when.”
- Asking it to “think carefully” or “double-check” wastes tokens or worse : Opus 5 already reasons by default, and asking Fable 5.1 to reproduce its reasoning in the response can actually trigger a refusal.
- For big, undefined builds, let the model interview you : Anthropic’s Claude Code best practices recommend a minimal starting prompt that asks Claude to interview you about goals, edge cases, and trade-offs before building.
What’s wrong with step-by-step prompts now? #
For roughly the last year, detailed step lists were the standard fix for models that missed instructions. A typical prompt might read: open the spreadsheet, calculate this week’s numbers, compare to last week, write a summary, draft an email. That structure made sense when models needed hand-holding. Anthropic’s guidance for Opus 5 reverses that advice. The model is trained to handle a task end-to-end, so a rigid step list becomes a ceiling rather than a floor: it forces the model into your specific interpretation of the job, which may be worse than what the model would have worked out on its own from a broader goal.
The fix is to replace the step list with an outcome and a way to measure success. Instead of listing six operations on a spreadsheet, a prompt can simply state the goal (compare this week’s leads, spend, and cost per lead against last week) and the deliverable (a drafted client email). The model handles the arithmetic and comparisons itself.
For genuinely quick tasks, Anthropic also recommends adjusting the “effort” setting down to low or medium rather than adding more instructions. According to Anthropic, Fable 5.1 running on low effort remains competitive with older Opus models on cost per task, so a more capable model at lower effort can still be cheaper than an older model working harder.
Why does intent matter more than instructions? #
Trimming step lists doesn’t mean trimming context. Older prompting advice pushed for tight, minimal prompts that left out backstory. Anthropic’s newer guidance for Fable 5.1 includes a section explicitly on giving the model the reason, not just the request, because the model performs better when it understands intent.
The logic: any real task involves dozens of small decisions that a prompt rarely spells out. Is a 4% dip in a metric a problem or noise? Should an email lead with spend or cost per lead? A model that knows why the output matters, and to whom, can make those calls the way a competent employee would.
Anthropic’s template for this has two parts. First, context: what larger task this fits into, who it’s for, and what the output enables (a report the client uses to make budget decisions, for example). Second, the specific request: the exact metrics, the exact deliverable, and the definition of done.
How do you stop Claude from doing too much? #
Older Claude and Sonnet models often did too little, requiring users to keep re-prompting them to continue. Opus 5 tends toward the opposite problem: left with an open-ended request, it can expand scope, adding a dashboard, a chart, or extra research nobody asked for. Anthropic’s own guide for Opus 5 states this directly, describing the model as by default expanding scope and adding unrequested steps.
One coffee. One working app. #
You bring the idea. Remy manages the project.
The fix is stating what “done” looks like and constraining scope explicitly for narrow tasks. That means specifying format (a client email under a set word count), what it should lead with, and what supporting detail to include (say, a short table of top reasons behind a metric shift). The more precisely the output shape is defined, the less room the model has to wander.
What if you don’t know the definition of done yet? #
Not every task is small enough to fully specify up front. For larger builds, Anthropic’s Claude Code best practices suggest a different approach entirely: rather than trying to write a more detailed prompt, have the model interview you first.
The pattern is to give a minimal starting prompt describing the larger feature or project, then ask Claude to use its interactive questioning tool to dig into goals, audience, edge cases, and trade-offs, including parts you haven’t considered. The output of that interview becomes the brief, and that brief is what kicks off the actual build. This effectively offloads the work of writing a complete specification to the model itself, using targeted questions instead of guesswork.
Do “must,” “always,” and “critical” still work in prompts? #
No, and this is one of the sharper reversals in the new guidance. Capitalized emphasis words and hard constraint language used to be the standard way to make sure a model actually followed an instruction. Anthropic’s current best practices say these models are responsive enough that such language now over-triggers them, causing erratic or excessive compliance rather than precise behavior.
The recommended fix is replacing hard constraints with plain conditional language. Instead of “CRITICAL: you must use this tool always,” the guidance suggests something as simple as “use this tool when [condition].” This states the desired behavior directly rather than forbidding the unwanted one, and it avoids creating friction with the model’s own system prompt. Anthropic reportedly used this same approach to cut a large share of Claude Code’s own system prompt length, replacing rigid rules with judgment and reasoning.
The same logic applies to formatting instructions. Telling a model “never use bullet points” adds an extra constraint that can conflict with instructions already baked into the system prompt, since Fable 5.1 is already tuned to use fewer bullets, less bold text, and fewer tables than earlier models by default.
Should you still tell Claude to double-check its work? #
Generally, no. Two habits that were considered best practice just months ago now cost time, money, or accuracy. Asking a model to “think carefully” is redundant on Opus 5, which already reasons before answering by default, controlled through the effort setting rather than through prompt phrasing. Adding “think carefully” on top just triggers extra, unnecessary reasoning.
Asking Fable 5.1 to walk through its reasoning or double-check its output in the response is riskier: Anthropic’s guidance warns against instructing the model to reproduce its reasoning in its response, noting that it can trigger an outright refusal of the task. The safer approach is to leave default reasoning behavior alone and use the effort setting to manage cost, rather than adding verification language into the prompt itself.
Frequently Asked Questions #
What is the biggest prompting mistake people carry over to Claude Opus 5?
#
Plans first. Then code.
Remy writes the spec, manages the build, and ships the app.
Writing out detailed, numbered step lists. Anthropic’s guidance says Opus 5 performs best with a complete goal and definition of done handed over up front, and that prescriptive step lists from older prompting habits can actively degrade output quality.
Does this mean prompts should be shorter overall?
Not necessarily shorter, but differently weighted. Cut the step-by-step instructions and rigid constraint language, but add context: who the output is for, why it matters, and what counts as finished.
Do these prompting changes apply to non-Anthropic models?
The transcript notes that similar dynamics are being discussed around other frontier models, such as OpenAI’s newer releases, though the specific guidance quoted here comes from Anthropic’s own documentation for Opus 5 and Fable 5.1.
How do I fix skills and system prompts I wrote months ago?
Review them for step lists, hard constraint words like “always” or “must,” and instructions to double-check or narrate reasoning. Replace step lists with a stated goal and definition of done, and replace constraint language with plain conditional instructions paired with the reason behind them.
What should I do for large, undefined projects instead of writing a giant prompt?
Give the model a minimal starting prompt and have it interview you using its built-in questioning tool, covering goals, audience, edge cases, and trade-offs. Use that interview as the brief for the actual build.