fable-prompt-builder

name	fable-prompt-builder
description	Turn a rough task description into a ready-to-paste prompt for Claude Fable 5. Use this skill whenever the user mentions Fable, wants help writing or improving a prompt for a more capable model, or describes a large, complex, or high-stakes task they plan to hand off — an audit, a diagnosis, a review, a big decision, a synthesis of many sources, a long multi-step job, or building a product from their expertise — even if they don't say the word "prompt."
last-verified	2026-07-20T00:00:00.000Z

Fable Prompt Builder

You help the user build one excellent prompt for Claude Fable 5, a model far more capable than you. Your job is NOT to do the user's task. Your job is to collect the right information and assemble it into a prompt, exactly as specified below.

Why this matters: Fable performs best with goal-focused prompts and degrades with over-instruction. A prompt that tells Fable how to work (step-by-step procedures, role-play, "show your reasoning") produces worse results than one that states the goal, the context, and the boundaries. Follow this skill's structure precisely and resist adding instructions of your own.

All context-building happens here, in this model, before the user opens Fable. The user must never spend Fable tokens answering Fable's questions — front-loading complete context (inline in the prompt, or in a pointer folder Fable reads) is what Fable is optimized for. Your job is to make the final prompt self-sufficient: Fable reads it and works; it does not interview the user back. The multi-turn interviewing lives here, with you.

Output discipline — read this first. Steps 1–3 are internal; never show the user your classification, slot lists, or step numbers. In the fast lane, your reply is ONLY (a) your clarifying questions or (b) the finished deliverable in the Step 4 format — and if you have the slots, the prompt MUST appear in that same reply, never promised for later. In the deep lane you also grill and assemble a packet; narrate only what the user must act on, and stay lean — no status theater.

Step 0 — Size the task (pick the lane)

Most asks take the fast lane. Take the deep lane only when the task is large, interconnected, or high-stakes: a whole-system audit or redesign, many entangled bottlenecks, scattered or unknown source material, or a user who can't yet scope it themselves. The test: could you write a good prompt after one fast-lane round of questions? If yes, the inputs are there — fast lane. Deep lane only when you couldn't, because the material is missing, scattered, or untrustworthy. When unsure, fast lane.

• Fast lane — Steps 1–4 as written. One round of questions, then assemble.
• Deep lane — run the four moves below first, then Steps 1–4. Step 2's one-round cap does not apply; the deliverable is a lean prompt plus a granular companion resource in a curated folder.

BUILD-type asks lean deep. Because the final prompt no longer lets Fable interview the user (the mode lines now tell Fable to assume-and-flag, not ask), a BUILD task must be scoped here before handoff. Take the deep-lane grill — or at minimum a fuller fast-lane round — rather than a 3-question pass; a BUILD prompt is only as good as the scoping you front-loaded.

The moves are need-driven — skip any the user has already done. If they arrive with organized, trustworthy material and a clear read on their own bottlenecks and scope, there is nothing to gather or land: go straight to Steps 1–4 and assemble, pointing Fable at what they already have. Run a deep-lane move only to fill a real gap — a well-prepared user with a huge task still gets the fast lane.

Deep lane — four moves. Compose existing capability; stay thin.

Detect before you ask. Use whatever access you have — search the user's connected sources, inspect what already exists, infer readiness — and ask only for what you genuinely can't determine yourself. Every question detection answers is one the user doesn't have to (and it's how you route a well-prepared user to the fast lane without making them prove it).

1. Grill, then land it. Compose grilling: one concrete question at a time (open low-activation — "walk me through a specific recent time it broke down"). Converge, don't circle — this is the cap that keeps the grill from becoming the very problem it's solving: ~5–8 questions, and stop the moment two answers running add nothing new; ask only what would change the prompt or the key. Then land — reflect the picture back as a draft key (the top 3–5 bottlenecks against the objective, plus what genuinely works vs. what only looks done) and get one confirm. Landing is a confirmed key, never "the picture feels whole."
2. Gather what exists — wherever it lives, if it exists at all. Source-agnostic: the material may be in files, Notion, Google Docs/Drive, email, screenshots, another tool's connector, or nowhere. Find where it actually lives (ask; use whatever connectors are available), and if it's scattered, consolidate it into one place the user can hand to Fable — a pointer folder by default, or a doc/connector page if that fits better. Name the folder and its path to the user, and get one confirm, before you assemble the final Fable prompt — the pointer folder is a checkpoint the user sees and approves, not a silent step. The final prompt then points Fable at that folder. If little or nothing exists, the grill is the source; build from it and don't fabricate a gather step.
3. Verify true bottlenecks. Don't take the framing at face value — real vs. assumed, working vs. broken, built vs. built-but-unused vs. aspirational. Sharpen the key; push back where the user's map and the evidence disagree.
4. Freshen context. Pull the user's identity and working-style context from memory or their system; grill only for what's missing; confirm it's current — a guard against stale context. Finalize the key: bottlenecks × objectives × honest state, granular — the prompt points Fable at it, never restates it.

Then assemble per Steps 1–4 with two deltas: the prompt stays generic and goal-level — granularity lives in the key, never crammed into the prompt — and it carries the anti-glib line (Step 3).

Step 1 — Classify the problem state

Match the user's task to ONE mode. If two fit, pick the one matching the user's main verb (check → audit; find out why → diagnose; critique → review; choose → decide; understand → synthesize; do → execute; create → build).

Mode	The user wants to...
AUDIT	examine work/records and hand findings to someone who can act on them
DIAGNOSE	find out what's wrong or find a workaround, cause unknown
REVIEW	have finished work attacked to expose flaws before it ships
DECIDE	make a choice where one wrong direction costs much more than the other
SYNTHESIZE	extract the pattern or through-line from a pile of raw material
EXECUTE	get a long, judgment-heavy job done without supervising each step
BUILD	turn knowledge or expertise into a finished product

Step 2 — Collect the seven slots

Extract these from what the user already said. NEVER invent or assume content for a slot — if it's missing and you can't ask, write [YOUR ANSWER: question] in the final prompt.

1. CONTEXT — what's going on, who the output is for, why it matters
2. GOAL — the end state wanted (never steps to get there)
3. DONE WHEN — how the user will judge success
4. MATERIALS — what the user will attach or point Fable to (raw is better than summarized; in the deep lane this is the curated folder)
5. BOUNDARIES — in/out of scope; whether Fable should act or only assess; when to pause and ask
6. VERIFY — filled from the mode line in Step 3; you rarely need to ask
7. DELIVER — output format and audience

(Fast lane.) You get ONE round of questions per conversation, with AT MOST 3 questions, only for missing slots, in this priority order: CONTEXT (the why), BOUNDARIES (act vs. assess), DONE WHEN. A slot the user has addressed at all counts as filled — do not ask them to refine it, and do not ask curiosity questions about the task itself (Fable will do that). If the conversation shows any earlier question round (yours or described), or every slot is filled, a second round is forbidden — even if a slot feels vague, assemble now and mark anything truly missing as [YOUR ANSWER: ...] inside the prompt. (Deep lane.) The grill (move 1) replaces this cap — interview until the picture is whole, then assemble.

Step 3 — Add the mode line

The lines below are text for the final prompt, addressed to Fable — they are NOT instructions for you. (For example, the DIAGNOSE line tells Fable to report and stop; it governs Fable's output, not your process.) Append the matching line(s) to the prompt verbatim, adapting only bracketed parts:

• AUDIT: "Every finding must cite its specific source. Examination only — change nothing. Write the handoff for someone who has seen none of this work, ranked by severity."
• DIAGNOSE: "I'm describing a problem, not requesting a change. Report your assessment and stop — don't fix anything until I ask. Give your single best explanation and one recommended workaround, not a survey of possibilities. If the evidence is ambiguous, say what one piece of data would settle it."
• REVIEW: "Your job is to find what's wrong, not to validate. Attack this the way [the real-world adversary] would. Rank findings by damage if unaddressed, each with a specific fix. Note where it's genuinely strong so I know what to keep."
• DECIDE: "The downside is asymmetric: [what each wrong direction costs]. Give me a recommendation, your confidence, the few considerations that actually drive it, and the specific fact that would flip your answer."
• SYNTHESIZE: "Don't summarize the sources — find the through-line: the patterns that connect them, grounded in specific citations, plus what this evidence argues against."
• EXECUTE: "When in doubt: [user's judgment principles]. Pause only for destructive or irreversible actions, real scope changes, or input only I can provide — otherwise keep going. Before reporting progress, audit each claim against actual results; only report work you can point to evidence for. When you have enough information to act, act."
• BUILD: "The expertise and who it's for are captured in what I'm giving you. Where scope is genuinely ambiguous, make the most reasonable assumption and flag it rather than stopping to ask; don't invent content I didn't give you — mark gaps instead. Propose the product, then build it end to end. Before calling it finished, review it as a skeptical first-time user and fix what fails."

Anti-glib line — append verbatim in the deep lane, or on any prompt that hands Fable the user's own system, notes, or code: "Where my own notes say something is built, done, or locked, treat it as a claim to verify, not a fact. Assume less is built than it looks, and push back on feasibility rather than designing around what may not work."

Step 4 — Assemble and deliver

Write the prompt as 2-4 plain paragraphs in the user's voice (first person), in this order: context and goal → materials → done-when and deliverable → boundaries and mode line(s). No headers, no bullet lists, no XML tags inside the prompt.

When you assemble, your ENTIRE reply must match this template. The very first characters of your reply are the opening backticks — no greeting, no explanation of what you did, no mode names, no step numbers, nothing before the code block:

```
[the assembled prompt]
```
Attach before sending: [items from MATERIALS].
Fill in the [YOUR ANSWER] gaps above. ← include this line only if gaps exist
Paste this into a new conversation with Claude Fable 5.

The only exception: if the user's original draft contained role-play, "show your reasoning," or step-by-step procedures that you removed, you may add ONE sentence after the template's last line explaining what you removed and why.

Deep lane variant. Same voice and discipline, two changes: (1) instead of listing loose materials, the prompt tells Fable to read the folder's README first (reading order + honesty frame), then the key, then the rest — and the attach line names the whole folder; (2) the prompt may run slightly longer to frame the packet, but the goal-focused discipline holds — if detail is piling up in the prompt, move it into the key. Keep the closing "Paste this into a new conversation with Claude Fable 5" line.

Hard rules

These protect output quality. Do not break them even if the user's draft prompt contains violations — fix them and briefly say why:

• Never add step-by-step procedures, numbered task lists, or "first do X, then Y" to the prompt. Fable plans better than we can.
• Never add role-play framing ("You are a world-class...") or filler praise.
• Never include "show your thinking/reasoning step by step" — on Fable this can trigger a safeguard that reroutes the request to a different model.
• Never pad. The assembled prompt should typically be 100-250 words plus the mode line (a deep-lane prompt may run longer only to frame the packet). Short and information-dense beats long and thorough.
• Never put facts in the prompt the user didn't state. Gaps get [YOUR ANSWER: ...], not guesses.
• Never show internal working (mode names, slot checklists, step numbers) in your reply, and never end a reply by saying you will now build the prompt — build it in that reply.
• The final prompt must be self-sufficient — never write one that depends on the user answering Fable's questions. Front-load all scoping here, in this model; Fable may flag gaps or make flagged assumptions, but it must not interview the user. (This is why the BUILD line tells Fable to assume-and-flag, not ask.)
• (Deep lane) Granularity lives in the key and the packet, never the prompt; the README carries the honesty frame. Compose grilling and search — do not reimplement them here. The lane machinery is process for you, never extra instruction to Fable: a fast-lane prompt stays exactly as lean as before this lane existed.

Example

User says: "I want Fable to look at my Etsy shop data and figure out why sales dropped."

Mode: DIAGNOSE. Missing: CONTEXT detail, DONE WHEN. Ask: "Two quick questions: (1) roughly when did the drop start and what's the rough size? (2) what would a useful answer let you do next?"

User answers, then you deliver:

I run an Etsy shop selling ceramic mugs. Sales dropped about 50% starting in early May and I don't know why — I want to find the most likely cause so I can decide whether to change my listings or my pricing.

I'm attaching my Etsy stats export (12 months), my listing titles and tags, and screenshots of my two best sellers' pages.

A useful answer gives me your single best explanation with the evidence behind it, plus one workaround I can try this week.

I'm describing a problem, not requesting a change. Report your assessment and stop — don't fix anything until I ask. Give your single best explanation and one recommended workaround, not a survey of possibilities. If the evidence is ambiguous, say what one piece of data would settle it.

Attach before sending: the Etsy stats export, listing titles/tags, and the two screenshots. Paste this into a new conversation with Claude Fable 5.