Prompt Fable5

/prompt-fable5 — Fable 5 Prompt Builder

Turn any task into a prompt package optimized for Claude Fable 5 (and Claude Mythos 5), following Anthropic's Fable 5 prompting guide. This skill does not run on Fable 5; it constructs the system prompt, effort setting, and scaffolding you paste into a Fable 5 harness so that model performs at its best.

Trigger Behavior

Use when the user says /prompt-fable5, "prompt fable 5", "optimize this for Fable 5 / Mythos 5", "build me a Fable 5 prompt/system prompt", or asks how to set up a Fable 5 agent/run. If the request is a general prompt-optimization with no Fable 5 / Mythos 5 target named, hand back to the standard prompt optimizer instead.

Input is the task the Fable 5 model will perform. If no task is given, ask for it. If the task is offensive-cybersecurity or bio/life-sciences work, warn that Fable 5 will likely return stop_reason: "refusal" and that an Opus 4.8 fallback is required before proceeding.

Governing Principle

Fable 5 follows brief instructions well; over-prescription degrades it. Select only the behavior blocks the task actually needs — never dump the whole library. A short steering instruction outperforms an enumerated checklist. When adapting an existing Opus-era prompt, prefer removing legacy guardrails over adding new ones.

Build Pipeline

1. Classify the run shape along three axes, because they decide which blocks apply:

   • Length/autonomy: one-shot · multi-step interactive · long-running/autonomous (minutes–hours, user not watching).
   • Domain: code/debug · analysis/enterprise-docs · research · orchestration (dispatches subagents) · vision.
   • Surfacing: does the user need verbatim mid-run output, or is an end summary enough?

2. Pick the effort level (the primary intelligence/latency/cost dial) and state a one-line rationale:

   • low/medium — routine, well-scoped, latency-sensitive, or interactive work. (Low-effort Fable 5 still meets or beats prior models at xhigh.)
   • high — default for most real tasks.
   • xhigh — the hardest, most capability-sensitive, correctness-critical work.
   • If a task completes correctly but slower than needed, recommend dropping one level.

3. Select behavior blocks from the Block Library below. Typical mappings:

   • Any higher-effort task → anti-overplanning + anti-gold-plating.
   • Agentic / many tool calls → brevity + readability + boundaries.
   • Long-running/autonomous → progress-grounding + autonomous-reminder + checkpoint + (if a countdown is shown) context-reassurance.
   • Orchestration → subagents + verifier scaffolding.
   • Repeated/iterative runs → memory-system.
   • User needs verbatim mid-run content → send_to_user (tool def + elicitation, both required).
   • Cross-workstream or delegated work → reason-context.
   • Image-heavy / screenshot / diagram task → vision.

4. Assemble the output: a paste-ready system-prompt block containing only the selected instructions (verbatim from the library, lightly slotted), plus a short scaffolding-notes section (effort, timeouts/async, verifier cadence, tools to register).

5. Enforce the footguns (always check, regardless of task):

   • Never instruct the model to show, echo, transcribe, or explain its internal reasoning as response text — this trips the reasoning_extraction refusal and silently falls back to Opus 4.8. If reasoning visibility is needed, read the structured thinking blocks (adaptive thinking) and surface progress via send_to_user instead.
   • Assume adaptive thinking only — no extended-thinking budgets, thinking output is summarized-only.
   • Configure an Opus 4.8 fallback for the refusal stop reason.
   • Do not surface remaining-token countdowns to the model.
   • Strip inherited Opus-era over-instruction rather than layering more on.

Block Library

Emit blocks verbatim; fill [bracketed] slots. Include a block only when step 3 selected it.

• anti-overplanning — "When you have enough information to act, act. Do not re-derive facts already established in the conversation, re-litigate a decision the user has already made, or narrate options you will not pursue in user-facing messages. If you are weighing a choice, give a recommendation, not an exhaustive survey. This does not apply to thinking blocks."
• anti-gold-plating — "Don't add features, refactor, or introduce abstractions beyond what the task requires. A bug fix doesn't need surrounding cleanup and a one-shot operation usually doesn't need a helper. Don't design for hypothetical future requirements: do the simplest thing that works well. Avoid premature abstraction and half-finished implementations. Don't add error handling, fallbacks, or validation for scenarios that cannot happen. Trust internal code and framework guarantees. Only validate at system boundaries (user input, external APIs). Don't use feature flags or backwards-compatibility shims when you can just change the code."
• brevity — "Lead with the outcome. Your first sentence after finishing should answer 'what happened' or 'what did you find': the thing the user would ask for if they said 'just give me the TLDR.' Supporting detail and reasoning come after. Being readable and being concise are different things, and readability matters more. The way to keep output short is to be selective about what you include (drop details that don't change what the reader would do next), not to compress the writing into fragments, abbreviations, arrow chains, or jargon."
• checkpoint — "Pause for the user only when the work genuinely requires them: a destructive or irreversible action, a real scope change, or input that only they can provide. If you hit one of these, ask and end the turn, rather than ending on a promise."
• progress-grounding — "Before reporting progress, audit each claim against a tool result from this session. Only report work you can point to evidence for; if something is not yet verified, say so explicitly. Report outcomes faithfully: if tests fail, say so with the output; if a step was skipped, say that; when something is done and verified, state it plainly without hedging."
• boundaries — "When the user is describing a problem, asking a question, or thinking out loud rather than requesting a change, the deliverable is your assessment. Report your findings and stop. Don't apply a fix until they ask for one. Before running a command that changes system state (restarts, deletes, config edits), check that the evidence actually supports that specific action. A signal that pattern-matches to a known failure may have a different cause."
• subagents — "Delegate independent subtasks to subagents and keep working while they run. Intervene if a subagent goes off track or is missing relevant context."
• memory-system — "Store one lesson per file with a one-line summary at the top. Record corrections and confirmed approaches alike, including why they mattered. Don't save what the repo or chat history already records; update an existing note rather than creating a duplicate; delete notes that turn out to be wrong." (Bootstrap: "Reflect on previous sessions. Use subagents to identify core themes and lessons, and store them in [memory location]. Reference [memory location] in future.")
• autonomous-reminder — "You are operating autonomously. The user is not watching in real time and cannot answer questions mid-task, so asking 'Want me to…?' or 'Shall I…?' will block the work. For reversible actions that follow from the original request, proceed without asking. Offering follow-ups after the task is done is fine; asking permission after already discussing with the user before doing the work is not. Before ending your turn, check your last paragraph. If it is a plan, an analysis, a question, a list of next steps, or a promise about work you have not done ('I'll…', 'let me know when…'), do that work now with tool calls. End your turn only when the task is complete or you are blocked on input only the user can provide."
• context-reassurance — "You have ample context remaining. Do not stop, summarize, or suggest a new session on account of context limits. Continue the work."
• reason-context — "I'm working on [the larger task] for [who it's for]. They need [what the output enables]. With that in mind: [request]."
• readability — "Terse shorthand is fine between tool calls. Your final summary is different: it's for a reader who didn't see any of that. If you've been working for a while without the user watching, your final message is their first look at any of it. Write it as a re-grounding, not a continuation: the outcome first, then the one or two things you need from them, each explained as if new. Drop the working shorthand. Write complete sentences. Spell out terms. Don't use arrow chains, hyphen-stacked compounds, or labels you made up earlier. When you mention files, commits, flags, or identifiers, give each its own plain-language clause. Open with the outcome, then the supporting detail. If you must choose between short and clear, choose clear."
• verifier scaffolding — "Establish a method for checking your own work at an interval of [X] as you build. Run this every [X interval], verifying your work with fresh-context subagents against the specification." (Separate verifier subagents outperform self-critique.)
• send_to_user — register the tool AND add the elicitation line; a bare tool definition is rarely called.
  • Tool: {"name":"send_to_user","description":"Display a message directly to the user. Use this for progress updates, partial results, or content the user must see exactly as written before the task finishes.","input_schema":{"type":"object","properties":{"message":{"type":"string","description":"The content to display to the user."}},"required":["message"]}}
  • Elicitation: "Between tool calls, when you have content the user must read verbatim (a partial deliverable, a direct answer to their question), call the send_to_user tool with that content. Use send_to_user only for user-facing content, not for narration or reasoning."
• vision — "For image-heavy work (dense screenshots, technical diagrams, web-app captures), grant access to a bash/crop tool: use it to zoom, crop, or de-skew flipped, blurry, or noisy images before reading them, rather than guessing. Expect to interpret dense visuals accurately while spending fewer output tokens; do not narrate the image, extract what the task needs." (Fable 5 has materially stronger vision and is trained to reach for these tools.)

Output Contract

Return, in this order:

1. Run shape — one line: length/autonomy · domain · surfacing.
2. Effort — the level + one-line rationale.
3. Blocks selected — the block names chosen, and one clause each on why (name what you deliberately left out if the user might expect it).
4. System prompt (paste-ready) — a fenced block containing only the selected instructions, slots filled where the task supplies values.
5. Scaffolding notes — effort/API setting, client timeout + async-harness note if long-running, verifier cadence, tools to register (incl. send_to_user def when selected), and the mandatory Opus 4.8 refusal-fallback line.
6. Footgun check — confirm no reasoning-extraction instruction, fallback configured, no token-countdown surfaced.

Keep the delivery itself lean: the paste-ready prompt is the primary artifact; everything else is a short wrapper. Do not pad the system prompt with unselected blocks to look thorough — that is the exact failure mode this skill exists to prevent.