10 Fable 5 Prompts to Upgrade Your AI Agent Setup

The best Fable 5 prompts right now are not chat templates — they are audit jobs. Claude Fable 5 returned to general availability on July 1, 2026, and Anthropic’s own prompting guide is unusually direct about what a release like this means: behavioral differences from Opus 4.8 “may require prompt or scaffolding updates,” and a capability jump is “a good prompt to re-evaluate which instructions, tools, and guardrails are still needed.”

That advice has a deadline attached. Anthropic has announced that for Pro, Max, Team, and select Enterprise plans, Fable 5 is included for up to 50% of weekly usage limits only through July 7, 2026 — after that, it moves to metered usage credits. Every long-running audit you run inside the window rides plan inclusion instead of a credit balance.

This playbook gives you ten one-shot jobs, each structured the same way: the exact runnable prompt, the artifact you should expect back, and which cheaper model — Sonnet 5 or Haiku 4.5 — should execute the resulting plan. Every instruction pattern in the prompts comes from Anthropic’s published guidance, not folklore.

Most “new model” content asks what you can build. The more valuable question for any team already running agents is what you should now remove, tighten, or re-verify. Anthropic’s Prompting Claude Fable 5 guide makes the case explicitly: skills and prompts developed for prior models are often too prescriptive for Fable 5 and “can degrade output quality.” Instructions you added to work around an older model’s failure modes may now be dead weight — or actively harmful.

Three documented strengths make Fable 5 the right session for the audit step specifically. First, bug-finding recall is described as noticeably higher than Opus 4.8, “including search across codebases and repository history” — Anthropic gives no number for this, so treat it as a qualitative claim, but it is the vendor’s own claim. Second, Fable 5 dispatches parallel subagents more readily than prior models, which is what makes repo-wide sweeps tractable in one session. Third, the guide’s advice to “start at the top of your difficulty range” is a direct license to hand it a full-codebase audit rather than a toy prompt.

To be clear about the honest version of this claim: Opus 4.8 can run similar audits, and nothing below is a capability unique to Fable 5 in isolation. The argument is narrower — Fable 5’s documented long-horizon autonomy and higher recall make it the better session for the audit-and-plan step, while the execution step rarely needs it at all. And the timing argument is simple: the July 7 usage-credit transition is an announced schedule, which makes this week the cheapest time to run every job on this list.

Every job in this playbook follows one repeatable shape. Fable 5 runs the audit and produces a plan-shaped artifact. A cheaper model executes that artifact. You review the diff. The reason is economic as much as technical: the audit step is where judgment concentrates — reading an entire repository, weighing evidence, deciding what is safe to delete — while the execution step is mostly mechanical application of an already-written plan.

One caution from the community debate around routing: this pattern is a two-step handoff, not an orchestration layer. One widely shared write-up described burning $21 trying to prove an AI orchestrator could beat direct Fable 5 calls — and concluding that direct calls beat the routing overhead. The lesson holds here. You do not need a router, a gateway, or a meta-agent to run these jobs; you need one expensive session and one cheap session, in order. For a fuller treatment of which Claude model fits which work, see our model-routing guide for Sonnet 5, Opus 4.8, and Fable 5.

The table below is the whole playbook in one view: what Fable 5 does, what artifact comes back, the typical run shape, and which cheaper model executes the plan. No existing “Claude prompts” list we could find packages the audit-then-hand-off pattern as a named, repeatable matrix — that routing column is the point of this post.

Two reading notes. “Run shape” is a planning aid, not a promise — history-heavy sweeps (jobs 5 and 7) take longest because they scan commits, not just the working tree. And the executor column is a default, not a law: if a plan comes back with unresolved judgment calls, either send it back to Fable 5 for another pass or upgrade the executor one tier rather than letting a cheap model guess.

The first three jobs target the layer most teams never audit: the instruction files themselves. Anthropic’s memory documentation gives exact, checkable thresholds — which means these audits can return pass/fail findings instead of style opinions.

Job 1 — The CLAUDE.md / AGENTS.md consistency audit

The single most concrete checkpoint here: Claude Code reads CLAUDE.md, not AGENTS.md. If your repo standardized on AGENTS.md for other tools, the documented fix is an @AGENTS.md import (or a symlink) plus Claude-specific additions below it — not duplicating content across both files. Duplicated files drift, and drift matters more than it looks: the memory docs note that CLAUDE.md content is delivered as a user message after the system prompt, with “no guarantee of strict compliance, especially for vague or conflicting instructions.” Contradictions across nested files are a real defect, not a style nit.

Audit every agent-instruction file in this repository: CLAUDE.md,
.claude/CLAUDE.md, CLAUDE.local.md, .claude/rules/, and AGENTS.md
if present.

This is an audit-only job: do not modify any file. Report only.

Check: (1) files exceeding the ~200-line guidance; (2) instructions
duplicated or contradicting each other across nested files; (3)
AGENTS.md content the agent never reads because it is not imported;
(4) @path imports deeper than 4 hops or pointing at missing files;
(5) instructions restating what a linter or type checker already
enforces.

Return a findings report ordered by severity, and for each finding
a proposed fix as a unified diff I can apply later. Audit each claim
against a tool result from this session — quote the file and line
that proves it.

Expect back: a severity-ordered findings report with file:line evidence and ready-to-apply diffs. Execute with: Haiku 4.5 — applying doc diffs against numeric thresholds is mechanical.

Job 2 — The config-smell sweep

This is the job Anthropic’s guide most directly prescribes: skills developed for prior models are “often too prescriptive” for Fable 5 and can degrade output quality. Every workaround you wrote for an older model’s weakness is now a candidate for deletion. We published a full taxonomy of these defects — see the config-smell taxonomy — and this prompt runs your setup against exactly that class of problem.

Review every prompt, skill, and guardrail instruction this agent
setup carries: system prompts, skill files, hooks, and per-tool
instructions.

For each instruction, classify it: still needed, redundant with
default model behavior, or actively harmful (over-prescriptive
step-by-step guidance, stale workarounds for prior-model failure
modes, guardrails duplicating platform features).

Do not delete anything in this pass. Return a ranked removal list
with the reason each item is safe to cut, plus a one-paragraph risk
note for anything you are uncertain about. Audit each claim against
a tool result from this session.

Expect back: a ranked removal list with per-item rationale and risk notes. Execute with: Sonnet 5 — removals need light judgment per item, and the ranking already encodes the hard calls.

Job 3 — The docs-drift audit

Claude Code’s /init command generates a starting CLAUDE.md by exploring the codebase fresh — and when one already exists, it suggests improvements rather than overwriting. This job generalizes that idea: a fresh read of the repo, compared claim-by-claim against what the committed docs say.

Read the repository fresh, as if you had never seen its
documentation. Then compare what the code actually does against what
README, CLAUDE.md, and docs/ claim it does.

Report every drift: setup steps that no longer work, commands that
changed, described architecture that no longer matches the module
layout, env vars documented but unused or used but undocumented.

Audit-only: change nothing. Return a drift table (claim -> reality ->
file:line evidence) plus a proposed docs patch as a diff. Ground
every claim in a tool result from this session.

Expect back: a drift table with evidence plus a docs patch. Execute with: Haiku 4.5 — rewriting docs to match an evidence table is pure application.

The middle three jobs lean on the capability Anthropic describes as most improved: finding things — across the working tree and across repository history. The guide claims bug-finding recall noticeably higher than Opus 4.8 without publishing a figure, so the honest framing is qualitative: these sweeps come back with more, and more of it checks out when you verify the evidence lines.

Job 4 — The test-gap map

Coverage percentage is the wrong lens; consequence is the right one. This job maps tests to the paths where a slipped failure costs real money or data, and mines history for bug fixes that never gained a regression test. It pairs naturally with a broader testing strategy once the gaps are visible.

Map the test coverage of this repository against its riskiest code
paths — not by coverage percentage, but by consequence: money
movement, auth, data mutation, external side effects.

For each critical path, state whether a test exercises it, what the
nearest test actually asserts, and what failure would slip through
today. Search the repository history for past bug fixes that never
gained a regression test.

Return a prioritized gap map (path -> risk -> existing coverage ->
proposed test) I can hand to a cheaper model to implement. Do not
write the tests in this session.

Expect back: a prioritized gap map with a proposed test per gap. Execute with: Sonnet 5 — writing tests to a spec that names the path, the risk, and the assertion.

Job 5 — The dead-code and orphan-route sweep

The distinctive move here is using history as evidence: for each deletion candidate, the audit cites the last commit that referenced it. That converts “I think this is unused” into a checkable claim — and gives the executing model a manifest it can follow without guessing.

Sweep this repository for dead weight: exports nothing imports,
routes and pages nothing links to, feature flags that only ever
resolve one way, config for services we no longer use, and files
unchanged since they stopped being referenced.

Use repository history as evidence — for each candidate, cite the
last commit that referenced it. Do not delete anything.

Return a deletion manifest grouped by confidence (safe /
needs-owner-confirmation / keep), with the evidence line for each
entry.

Expect back: a confidence-graded deletion manifest with commit evidence. Execute with: Haiku 4.5 — delete exactly what the “safe” group says, run the build, stop on anything unexpected.

Job 6 — The dependency and version-drift audit

Dependency debt compounds silently: manifest ranges drift from lockfile reality, duplicate majors bloat the tree, and abandoned packages sit one CVE away from an emergency. The artifact that makes this executable by a cheaper model is sequencing by risk.

Audit this repository's dependency health: manifest ranges vs
lockfile reality, duplicate majors in the tree, packages with no
release in over a year, deprecated peers, and any dependency we
carry for a single trivial function.

Do not upgrade anything in this pass. Return an upgrade plan
sequenced by risk: batch 1 = patch-level, low blast radius; batch 2
= minors with changelog notes; batch 3 = majors, each with the
specific breaking changes that apply to our usage. Cite the manifest
or lockfile line for every claim.

Expect back: a three-batch upgrade plan with per-major breaking-change notes. Execute with: Sonnet 5 — majors hit real breaking changes, and adapting call sites per a changelog is judgment-light but not judgment-free.

The security pair. Job 7 is classic hygiene made cheap by a model that can actually read your whole history; job 8 audits the newest attack surface most teams added this year without a review — their MCP servers. The checklist for job 8 comes straight from the protocol’s own security documentation, which is blunter than most vendor copy.

Job 7 — The secrets and credential-hygiene pass

Run a credential-hygiene pass over this repository and its history:
committed secrets or tokens (including in old commits), .env files
in version control, credentials embedded in scripts or CI config,
and tokens that appear to be shared across more than one service.

Report only — do not rotate or edit anything. Return a findings
table (secret type -> location -> exposure window -> rotation
priority) and a rotation checklist ordered by blast radius. Never
print a discovered secret's full value; show a redacted prefix.

Expect back: a findings table and a blast-radius-ordered rotation checklist. Execute with: a human plus Sonnet 5 — rotation is a human act against provider consoles; Sonnet 5 handles the code-side cleanup (moving values to env, scrubbing scripts) the checklist specifies.

Job 8 — The MCP security check

The protocol’s security guidance names least privilege explicitly: never share tokens between MCP servers, give each server service-specific tokens with minimal scopes, log every tool invocation, and maintain a strict egress-domain allowlist. It also documents a real attack: a poisoned WhatsApp MCP server whose tool descriptions carried instructions able to override behavior across other connected servers, risking exfiltration of message history through seemingly benign calls. That is why this prompt inspects descriptions, not just code. For the full control set, see our MCP security checklist; for hardening the agent side beyond MCP, the OpenClaw hardening guide covers the adjacent surface.

Audit every MCP server this agent setup connects to: its source,
its tool descriptions, its token scopes, and its logging.

Check each server against the protocol's own security guidance:
tool inputs treated as untrusted, strict input schemas,
least-privilege scopes, no token shared across servers, every
invocation logged, an explicit egress-domain allowlist. Inspect the
tool DESCRIPTIONS, not just the code — poisoned descriptions can
steer behavior across other connected servers. Check package
provenance for typosquatting against popular server names.

Audit-only. Return a server-by-server risk report with a pass/fail
per control and the exact config line behind each fail.

Expect back: a per-server report with pass/fail per control. Execute with: Sonnet 5 for config hardening; any scope reduction or token reissue gets human sign-off first.

The last two jobs audit the machinery around the model. Job 9 checks your subagent harness against how delegation actually works — including one constraint teams repeatedly get wrong. Job 10 is the capstone: the migration nobody has had time to plan, scoped at the top of the difficulty range, exactly as Anthropic’s guide recommends.

Job 9 — The subagent harness review

The load-bearing fact: subagents run one level deep and cannot spawn subagents. Any agent definition or CLAUDE.md instruction that assumes recursive delegation describes a hierarchy that will never execute — we have caught this exact assumption in an audit of our own fact base, which is why the prompt names it. The guide also notes Fable 5 dispatches parallel subagents more readily than prior models, and that long-lived subagents keeping context across subtasks “save time and cost through cache reads.” If you are building the harness itself, start with our step-by-step custom subagent guide.

Review this project's subagent setup: every file in .claude/agents/,
plus any CLAUDE.md instruction telling the model how to delegate.

Verify each definition against how delegation actually works:
subagents run one level deep and cannot spawn subagents — call out
any config or instruction that assumes recursive delegation. Also
call out subagents whose description overlaps another's, tool
allowlists broader than the job needs, and single-use agents that
re-derive context a long-lived agent could keep across subtasks.

Audit-only. Return a harness report plus rewritten agent definitions
as proposed diffs.

Expect back: a harness report and rewritten agent definitions. Execute with: Haiku 4.5 — swapping in corrected definition files is file editing.

Job 10 — The migration / refactor plan

Anthropic’s advice is to pick a task harder than what you would assign to prior models, then have Fable 5 scope it, ask clarifying questions, and execute. For a plan-only job, keep the scoping and drop the execution. Note the scale ceiling has moved too: the Dynamic Workflows research preview in Claude Code lets Fable 5 author orchestration scripts running tens-to-hundreds of parallel subagents with adversarial verification and resumable progress — so for a very large migration, Fable 5 can write the workflow even though each individual subagent stays one level deep.

Scope the largest refactor this codebase needs but nobody has had
time to plan — [name it, e.g. the data-access layer]. Ask me
clarifying questions before you plan.

Produce a staged migration plan: stages that each leave the build
green, explicit verification steps between stages, the order of file
moves, and the tests that must exist before each stage starts.
Establish a method for checking your own work at an interval — after
each stage of planning, re-verify the plan's assumptions against the
current code with a fresh-context review.

Do not execute the migration. Return the plan as a document a
cheaper model can follow stage by stage.

Expect back: a staged plan where every stage ends green with an explicit verification gate. Execute with: Sonnet 5, stage by stage against the gates — escalating back to Fable 5 only if a stage’s assumptions no longer hold.

Every prompt above quietly embeds instruction patterns that Anthropic documents by name. Pulled out, they form a bolt-on block you can append to any audit job — including ones this list does not cover.

• Ground progress claims. Instructing Fable 5 to audit each claim against a tool result from this session “nearly eliminated fabricated status reports even on tasks designed to elicit them” in Anthropic’s own testing. Non-negotiable for audits, where the entire product is claims.
• State the boundaries. The guide notes Fable 5 can occasionally take unrequested actions — drafting an email when none was asked for, creating defensive git-branch backups. An audit-only job needs the boundary stated, not implied.
• Verify on an interval. For long runs, the guide recommends establishing a method for checking your own work at a set interval — and notes that separate fresh-context verifier subagents tend to outperform self-critique.
• Set effort deliberately. The documented default is high for most tasks, with xhigh reserved for the most capability-sensitive work — lower effort on Fable 5 “still performs well and often exceeds xhigh performance on prior models.” Sweeps do not need xhigh; the migration plan might.

BOLT-ON BLOCK — append to any audit job above:

1  Ground your claims: before reporting any finding as fact, audit
   it against a tool result from this session. If you cannot point
   to the file, line, or command output that proves it, mark it
   "unverified".
2  Stay inside the job: this is an audit. Do not modify files,
   create branches, draft messages, or take any action beyond
   reading and reporting.
3  Verify on an interval: every 10 findings, pause and re-check the
   last 10 against the codebase with fresh eyes before continuing.
4  Effort: run at high. Reserve xhigh for the single hardest job on
   this list (the migration plan), not for routine sweeps.

The deeper shift these patterns encode is worth naming: prompting is moving from coaxing capability to governing autonomy. Prior-generation prompt libraries spent their tokens telling the model how to think step by step. Fable 5’s official guidance spends its ink on evidence discipline, boundaries, and self-verification — the controls you put on a system that is already capable enough to run for hours without you. Expect the prompt-engineering conversation to keep drifting in that direction as autonomy windows lengthen.

The routing logic rests on published list prices. Fable 5 lists at $10 per million input tokens and $50 per million output. Opus 4.8 sits at $5/$25. Sonnet 5 carries intro pricing of $2/$10 through August 31, 2026 (then $3/$15). Haiku 4.5 is $1/$5. Execution is the token-heavy phase — plans generate long diffs — so putting it on Sonnet 5 is 5× cheaper per token than leaving it on Fable 5 at intro pricing (about 3.3× after August 31), and Haiku 4.5 is 10× cheaper for the mechanical jobs.

Two levers cut the audit step’s own cost as well. Prompt-cache reads on Fable 5 run about 90% off list — roughly $1 per million input tokens — which matters for audits that re-read the same large files repeatedly. And the Batch API halves list to $5/$25 for jobs that tolerate async turnaround. Inside the announced window, plan-included usage covers interactive runs; after July 7, usage credits meter them, with Anthropic stating a $2,000/day spend ceiling.

On whether the audit step is worth frontier pricing at all: community sentiment from early Claude Code users characterizes Fable 5 as roughly “10–25% better than Opus, fewer mistakes, same workflow” for coding work — an individual-user impression, not a benchmark, and we treat it as exactly that. The stronger argument stays structural: audits are read-heavy and judgment-dense, which is precisely the profile where the documented recall and long-horizon improvements bind. Our projection: as usage credits normalize expensive-model pricing, the audit-up/execute-down split stops being a cost hack and becomes the default shape of agentic engineering work — the same way senior/junior pairing is the default shape of human engineering teams. It is also how we run this kind of agent-setup audit for clients inside our AI transformation engagements: Fable 5 on the audit, cheaper models on the execution, senior review on every artifact in between.