Your Claude Code Skills Are Too Prescriptive for Fable 5

Here's an uncomfortable finding from Anthropic's own prompting guidance for Claude Fable 5: skills and prompts written for older models are "often too prescriptive… and can degrade output quality." The careful, numbered procedures you wrote to keep a weaker model on the rails now actively hold a stronger one back.

That's a hard pill for skill authors. Prescriptiveness felt like craft. When a model kept skipping a validation step or forgetting to handle an edge case, you added a rule. Over months, a good skill accreted into a twenty-step checklist that pinned the model to exactly the path you'd walk yourself. On Fable 5, that pinning is the problem. The model is capable of planning the path — and often a better one than your script — but only if you leave it room.

As of July 2026, if you're migrating a skill library from Opus 4.7 or 4.8 to Fable 5, the highest-leverage refactor isn't wiring up new parameters. It's deleting instructions. This piece is how to find the over-specified ones and what to replace them with.

Key Takeaways

• Over-prescription degrades Fable 5 output — Anthropic's guidance, not a hunch. Numbered procedures that pinned weaker models now constrain a stronger one.
• Refactor toward goal + constraints. State the outcome, the boundaries, and the definition of done — then let the model plan the steps.
• Audit for tell-tale phrases: "step 1… step 2…", "first do X then do Y", "always output in exactly this order", and reasoning-extraction traps like "show your work."
• Keep genuine constraints, cut invented procedure. A required output schema stays. A hand-walked algorithm goes.
• Pair the cut with a boundary line so the model doesn't over-elaborate or wander into adjacent tasks.

Why prescriptive prompts backfire now

A prescriptive prompt encodes your solution path. That's fine when the model is weaker than you at planning — the script substitutes for judgment it doesn't have. Fable 5 is built for "the most demanding reasoning and long-horizon agentic work," and its thinking is always on and adaptive. Hand it a rigid script and you get two failure modes.

First, you cap the ceiling. If your steps describe an okay approach and the model could have found a great one, it dutifully executes okay. Second, you create conflict. When the model's own planning disagrees with your script — because your script was tuned for a different model's blind spots — it burns effort reconciling the two, and the output gets worse, not better. Anthropic also notes Fable 5 can occasionally over-elaborate or take unrequested adjacent actions; a wall of procedural text feeds exactly that tendency.

The mental model shift: you're no longer writing an algorithm for the model to execute. You're writing a brief for a capable operator — the goal, the guardrails, and what "done" looks like.

The audit: what to grep your skills for

Open your skill prompts and scan for these patterns. Each is a signal you've encoded procedure that Fable 5 doesn't need.

• Ordered step lists that describe how, not what. "Step 1: read the file. Step 2: parse the frontmatter. Step 3: validate each field." The model knows how to do this. Tell it the frontmatter must be valid and what fields are required.
• "First… then… then…" chains that narrate a path instead of stating a result.
• Redundant restatements — the same constraint said three ways "to be safe." Say it once, precisely.
• Invented tie-breakers for decisions the model can make itself. "If unsure, default to X" is fine when X is a real business rule; it's noise when it's you guessing.
• Reasoning-extraction traps. Any "explain your reasoning step by step," "show your work," or "output your chain of thought" line. On Fable 5 these can be refused outright with category reasoning_extraction and they elevate fallbacks — read the reasoning-extraction trap piece for the full story, then delete them.

What you keep: hard output contracts (a JSON schema, a required section order in a deliverable), real domain rules, safety and scope boundaries, and anything a downstream system parses. Those aren't over-prescription — they're the spec.

Before and after

Here's a skill that lints and rewrites a project's README. First, the over-prescriptive version, tuned over months against a weaker model:

# README Improver Skill

You improve README files. Follow these steps exactly and in order:

1. Read the entire README.md file from top to bottom.
2. Explain your reasoning step by step as you go so I can follow it.
3. First, check that there is a title on line 1. If not, add one.
4. Second, check for an installation section. If missing, add one.
5. Third, check for a usage section with at least one code block.
6. Fourth, check that every code block has a language annotation.
7. Fifth, look for broken relative links and list each one.
8. Then rewrite the file applying all fixes from steps 3-7 in that order.
9. Always output the sections in this order: Title, Badges, Install, Usage, API, License.
10. Do not skip any step. Show me each step's result before moving on.

Now the goal-and-constraints version for Fable 5:

# README Improver Skill

Improve the project's README.md so a new developer can install and use the
project without asking questions.

Constraints:
- Preserve all existing accurate content; don't invent features or commands.
- Every code block must declare its language.
- Prefer this section order when sections exist: Title, Badges, Install,
  Usage, API, License. Don't add empty sections.
- Fix broken relative links; if a target is ambiguous, leave the link and
  note it at the end.

Done means: the file passes a markdown linter, install and usage are both
present with runnable examples, and no factual claim is unsupported by the
repo. Return the rewritten README, then a two-line summary of what changed.

The second version is shorter, but that's not the point. It removed the reasoning-extraction trap (line 2 and 10 of the original), stopped hand-walking an algorithm the model can plan, and replaced "do these steps" with a crisp definition of done. The output contract that actually matters — the section order, the language annotations, the "don't invent" rule — survived, because those are constraints, not procedure.

A repeatable refactor loop

Don't rewrite your whole library blind. Run each skill through a tight loop:

1. Baseline. Run the current prescriptive skill on 3–5 representative inputs on Fable 5. Save the outputs.
2. Cut. Remove ordered procedure, redundant restatements, and every reasoning-extraction line. Rephrase the survivors as goal + constraints + definition of done.
3. Add one boundary. If the skill tends to sprawl, add a single line like "stay within the README; don't modify other files." Anthropic notes a one-line boundary fixes most over-elaboration.
4. Re-run and compare. Same inputs, same effort level. Read both sets side by side.
5. Keep what wins. If the leaner prompt matches or beats the old one — the common result — ship it. If a specific constraint regressed, add that one back precisely, not the whole script.

This is empirical on purpose. "Less prescriptive" isn't a slogan to apply uniformly; it's a hypothesis to test per skill. A skill that produces a strictly-formatted machine artifact may legitimately keep more structure than one that writes prose.

The objection: won't looser prompts make skills less reliable?

This is the fair pushback, and the answer is that you're trading the wrong kind of reliability for the right kind. A prescriptive script gives you reliable process — the model walks your exact path every time — at the cost of reliable outcomes, because your path was tuned for a weaker model's failure modes. Goal-and-constraints flips that: you specify the outcome and the invariants, and let the model find a path that satisfies them.

Two levers keep the looser version tight. First, the definition of done is your real reliability contract — "passes a linter, has runnable examples, no unsupported claims" is far more enforceable than a ten-step procedure, and you can even check it programmatically. Second, a single boundary line curbs the sprawl Fable 5 can occasionally show: it may over-elaborate, take an unrequested adjacent action, or stop early with a text-only "I'll now do X." Each has a documented one-line fix — state the scope, and add "you are operating autonomously; do the work before ending your turn." That's two lines of guardrail replacing twenty lines of script, and it holds better.

If a skill genuinely needs a rigid procedure — a compliance workflow, a deterministic build step — keep it. The audit is about deleting invented procedure, not real requirements.

Where effort fits in

Cutting instructions and setting effort are the same conversation. A leaner prompt gives the model room to plan; the effort level decides how hard it plans. For a simple, well-bounded skill, a trimmed prompt at medium effort will often beat a bloated prompt at high — remember that lower effort on Fable 5 frequently exceeds prior models' xhigh. For a genuinely hard, open-ended skill, pair the lean brief with xhigh. The effort routing guide has the full table.

If your skills feed into multi-step agents or workflows, the payoff compounds: each over-specified sub-prompt you cut removes a place where the model's plan and your script can collide.

The takeaway

The instinct that made you a good skill author on weaker models — anticipate every failure, script around it — is the instinct to unlearn on Fable 5. Its thinking is always on, and its planning is often better than the path you'd hard-code. Your job moves up a level: define the outcome, fence the scope, specify the output contract, and delete the rest.

Audit one skill today. Find its longest numbered procedure, replace it with a goal and three constraints, and run the before/after. Then make it fallback-aware so a stray refusal doesn't take it down. Browse the Claude Fable 5 series for the rest, and see what other builders are shipping across /browse and /loops.