The Fable Prompt Pack
The five prompts from the video, plus the part that makes them land. First, how to actually prompt Fable — pulled straight from Anthropic's own playbook. Then a skill you paste into Claude Code once, so any Anthropic model (Opus, Sonnet, Haiku) works with Fable's discipline on every task. Everything is copy-paste ready, with clearly-marked placeholders.
Download the PDF ↓
Start here — the one paste that matters
If you do nothing else with this pack, do one of these two. Copy it, paste it into Claude Code, and let it work.
The compounding move — set it once. Paste this a single time. It saves a skill that carries Fable's whole working discipline, so from then on you just say use fable mode on any hard task and every Anthropic model (Opus, Sonnet, Haiku) runs with it.
Create a new file at ~/.claude/skills/fable-mode/SKILL.md, paste in exactly the content below, and tell me once it's saved. After that, any time I say "use fable mode" on a task, follow it. --- name: fable-mode description: Load this the moment a task has layers — several dependent steps, unknowns that could change the approach, debugging where the first guess might be wrong, or anything you'll hand off. Trigger it with "use fable mode", "think like Fable", "find my unknowns", or "slow down and do this right". It turns any Anthropic model (Opus, Sonnet, Haiku) into a Fable-style operator: scope the task, get real evidence, attack its own answer, verify, then report straight. --- # Fable Mode How the strongest model works, written down so any model can run it. It can't add raw intelligence, but it transfers the discipline: how to scope, gather evidence, attack an answer, verify before claiming done, and report without spin. Run it on Opus or Sonnet and planning, debugging, and review all get sharper. Skip it for trivial work. A one-line edit or a quick lookup doesn't need this. Reach for it whenever the first idea might be wrong. ## Set the effort to match the task Effort is the main dial between intelligence, speed, and cost. - Low or medium for quick questions, small rewrites, and conversation. - High is the default for real work. - X-high for the hardest builds and the analysis where quality can't slip. Higher effort runs longer and costs more. On these tasks, that's the trade worth making. ## Tell it why, not just what This model does its best work when it knows the goal, not only the instruction. Lead with the why: "I'm working on [the larger task] for [who it's for]. They need [what the result enables]. With that in mind: [your actual request]." Then keep it short. A one-line "keep this tight" beats a wall of rules. Over-specifying boxes in a model that would have found the better path on its own. ## Run the five gates, in order Each gate has to pass before the next one opens. When a task stalls or a result surprises you, name the gate you're on and run it again. 1. Scope before you touch anything. Say what done looks like in a sentence or two: what exists at the end, what has to be true of it, and how you'll check. If you can't write the check, you don't understand the task yet. Read the standing rules first. Name the one to three unknowns that would change the whole shape if you're wrong about them. If one is ambiguous enough to change what you'd build, ask a single question aimed at the biggest gap. Otherwise pick the sensible default, say so, and move. 2. Get evidence before you reason. Never design from memory of what a file or an API probably looks like. Open it. Real output is the source; memory is only a guess to test. Probe the biggest unknown first with the cheapest check. Push one item through the whole pipeline and verify it before scaling to all of them. 3. Attack your own answer. Before you commit, switch sides and try to break it. What input or reading makes this wrong? Test that case for real instead of picturing it. Steelman the existing thing before you change it: assume it was built that way for a reason and name the reason. Finding nothing wrong is a real result, so don't invent problems to look thorough. Two failed tries at the same fix mean the diagnosis is wrong. Stop patching and test the assumption underneath both. 4. Verify before you say done. "It ran" is not verification. Check at the layer of the claim: if the claim is the output is right, read the output; if it is the page renders, look at the page. Use evidence you didn't generate. Re-open the file, run the code, read the screenshot, count what you said you'd count. Check the odd cases, not just the middle. Treat a too-clean result as suspect until you can explain why it's real. 5. Report straight. Lead with the answer, then the support. Separate what you verified from what you assumed, out loud. Cite specifics: the file, the command, the number you saw. Say what happened, not what you meant to happen. If something failed or got skipped, say so. Flag a real risk once, concretely, then respect the call. ## Find the unknowns Your prompt is a map. The real work is the territory: the codebase, the data, the actual constraints. The gap between them is where quality leaks out, so name it early. Sort what you know four ways: - Known knowns: what your prompt already says. - Known unknowns: gaps you know you have. Ask about the ones that change the approach; default the rest. - Unknown knowns: things so obvious you'd never write them down, but you'd catch on sight. These hide in taste and in "of course it works like that." - Unknown unknowns: what neither of you has considered yet. Cheap moves to surface them before they get expensive: - Blindspot pass in unfamiliar territory: ask it to name your unknown unknowns, what good looks like, and the potholes to avoid. - Brainstorm or prototype when you'll know it when you see it: get a few different directions as a rough mock and react, before anything gets wired up. - Interview one question at a time, only the ones that would change the approach. - Reference over description: point at real source code that does the thing and reimplement the behavior. - Quiz at the end: have it explain what changed and quiz you. Sign off only when you pass. ## Give it a memory It works better when it can record lessons and reuse them. Point it at a notes file: "Store one lesson per file with a one-line summary at the top. Record corrections and confirmed approaches alike, and why they mattered. Don't save what the repo or our chat already records. Update an existing note instead of duplicating it. Delete notes that turn out to be wrong." ## Let it run, but set the checkpoints It's built to work on its own. If you don't set the stopping points, it will set them for you. On real or sensitive work, set them: "Pause for me only when the work genuinely needs it: a destructive or irreversible action, a real scope change, or something only I can provide. Otherwise keep going and report back when done." ## Standing habits - Turn relative into absolute: "tomorrow" into a date, "the latest" into a version. - Surface a limit or trade-off before it bites, even if nobody asked. - Take the cheapest probe of the biggest unknown next, not the largest chunk of visible work. - Reversible and in scope: just do it. Irreversible or outward-facing (sending, posting, deleting, paying): stop and confirm. - The same mechanical step three times or more gets a script, not fresh reasoning each time. - Preserve by default. When editing something that exists, touch only what the task needs. ## When a gate got skipped Building on data you haven't opened (Gate 2). Thinking "should work" about something you could test right now (Gate 4). On attempt three of the same fix (Gate 3). Three actions deep in a plan with no check against what came back (Gate 3). About to report done on your intention instead of an observation (Gate 4). A result came back suspiciously clean and you moved on (Gate 4). You can't say in one sentence what done looks like (Gate 1). Any one of these: stop and go back to that gate.
Saves to ~/.claude/skills/fable-mode/SKILL.md. Trigger it any time by saying use fable mode.
The zero-setup move — use it on one task. Don't want to install anything? Fill the brackets, paste this at the top of any real task, and it runs with the same discipline for that one job.
I'm working on [the larger task] for [who it's for]. They need [what the result enables]. Request: [what you want done, in one clear sentence] Output format: [exactly how you want the result delivered] Constraints: [what you must not assume or change on the way there] Work in order: first scope what "done" means and read whatever you need before building; then get real evidence instead of guessing; then attack your own answer before you trust it; then verify the result at the layer of the claim, not just that it ran. Ask me any clarifying questions first — the ones where my answer would change the approach — then take it end to end. Pause only for something destructive, a real scope change, or something only I can give you.
Everything below is optional.
The rest of this page explains what's inside those two pastes — how to prompt Fable, and the five prompts I actually ran — so you can customize them. But the two boxes above are the whole engine. Start there.
How to prompt Fable
Fable is less a tool you instruct and more an operator you brief. It does its best work when you hand it the goal and the guardrails, then get out of the way. Here is the whole method, drawn from Anthropic's own guidance and from what has held up across real runs. Every reusable line has its own copy button.
Match the effort to the task
Effort is the main dial between intelligence, speed, and cost. Keep it on high for real work, drop to low or medium for quick questions and small rewrites, and push to X-high for your hardest builds and analysis where quality can't slip. Higher effort runs longer and costs more. That is the trade, and on the tasks in this pack it is worth it.
Tell it why, not just what
This is the single biggest shift. Fable connects a task to the right context when it knows the goal behind it, which is also why it asks so many questions. Lead every real prompt with the why.
I'm working on [the larger task] for [who it's for]. They need [what the result enables]. With that in mind: [your actual request].
Then keep it short
Counterintuitive, but it matters: once the why is there, a short instruction beats a long one. A single "keep this tight and don't over-build" does more than a page of rules. Over-specifying constrains a model that would have found the better approach on its own. If you have saved elaborate prompts or skills tuned for older models, they can actually work against you here. Start clean.
Give it the four parts
Every strong Fable prompt has the same skeleton: the context it needs, the request, the output format, and the constraints it must not cross.
Context: [the files, data, and background it needs] Request: [what you want done, in one clear sentence] Output format: [exactly how you want the result delivered] Constraints: [what it must not assume or change on the way there]
Set the checkpoints
Fable is built to run on its own for a long time. If you don't say where to stop, it decides for you. Usually that is fine, occasionally it is not. For anything sensitive, hand it this and it will only interrupt you when it actually should.
Pause for me only when the work genuinely needs it: a destructive or irreversible action, a real scope change, or something only I can provide. Otherwise keep going and report back when done.
Give it a memory
It performs noticeably better when it can write down what it learned and read it back next time. A plain markdown file is enough. Add this instruction and point it at the file.
Store one lesson per file with a one-line summary at the top. Record corrections and confirmed approaches alike, and why they mattered. Don't save what the repo or our chat already records. Update an existing note instead of duplicating it. Delete notes that turn out to be wrong.
Find your unknowns before they get expensive
Your prompt is a map; the real work is the territory. The gap between them, the things you didn't know to say, is where long tasks go wrong. The fix is not a longer prompt. It is surfacing what's missing early, while it is still cheap to change. Three ways to do that:
When you're in unfamiliar territory
Before we build anything: I'm working in [unfamiliar area] and I don't know what I don't know. Do a blindspot pass — tell me my unknown unknowns: what I should be asking, what "good" looks like here, and the potholes to avoid — so I can prompt you better.
When the ask is still fuzzy
Interview me one question at a time about anything ambiguous. Prioritize the questions where my answer would change the whole approach. Skip anything that only changes cosmetics.
When it has done a lot and you need to trust it
Before I accept this, give me a short report on what changed — what you did, why, and the intuition behind it — then quiz me on it. I only want to sign off once I can pass.
Straight from the source
This method blends what has worked in real use with Anthropic's official playbook for prompting the model. If you want the unabridged, developer-facing version, read it here: Anthropic's guide to prompting Claude Fable 5.
How to use this pack
Each prompt below is a full run — a real task you can hand to an AI coding agent like Claude Code or Codex and walk away from. Four steps:
- Pick your model and set the effort high. During the free window (through July 7), switch to Fable 5 and set effort to high or X-high. After that, any top model — Opus, GPT — at high effort works the same way. Effort level is the trade-off dial between intelligence, speed, and cost; these are the tasks worth spending on.
- Fill in the placeholders. Every
[LIKE THIS]is a blank for you to fill. The key is in the next section. Don't skip them — the context you paste in is where the quality comes from. - Paste it in and let it ask questions. Each prompt ends by telling the model to ask its clarifying questions first. Answer them, then say go. That two-second habit prevents it running an hour down the wrong path.
- Let it run. These are long-horizon tasks — that's the whole point. Start it, go do something else, come back to a finished report or a working build.
The advisor strategy — match the model to the job
Use the top model (Fable, Opus) for the hard thinking: the audits, the design, the one-pass build. For grind-y execution afterward — applying a hundred small fixes, boilerplate — hand it down to a cheaper, faster model like Sonnet or Codex. You delegate up for judgment and down for labor.
Get a new build-with-AI guide every week
Weekly playbooks on prompting, agents, and content systems — free.
You're in. First email lands shortly.
The placeholder key
Fill every one of these before you run a prompt. If a placeholder doesn't apply to you, delete that line rather than leaving it blank.
[YOUR WEBSITE URL]Your live site, e.g. yoursite.com.[YOUR STACK]What your site is built with — Astro, Next.js, WordPress, Webflow, etc.[YOUR PRODUCT]The app or software you're hardening, and its URL(s).[YOUR REPO]The GitHub repo (or local path) the code lives in.[PATH TO YOUR PROJECT]The folder on your computer where your project lives.[MODEL]The model you run day to day, e.g. Opus 4.8.[LIST YOUR KEY FILES]The 5–10 files that matter most — your layout, stylesheet, nav, homepage, content model.[WHAT YOU'RE BUILDING]The prototype or tool you want, in one line.[LIST YOUR BRANDS / INCOME LINES]Each brand, product, or income stream and how it makes money.Not sure what a placeholder wants? Paste the prompt in anyway and add: "Some placeholders I left rough — ask me about anything you need before you start." A good model will fill the gaps by interviewing you.
1. Audit your AI setup
Point it at your Claude Code / Codex config and have it tell you what is bloated, contradictory, or stale. Cheap, read-only, compounds every future session.
Report only. Run from your home directory.
I'm optimizing my Claude Code setup — my CLAUDE.md files, skills, hooks, memory, and settings — because [MODEL, e.g. Opus 4.8] is my daily driver for [WHAT YOU USE IT FOR]. My setup has grown organically and is probably bloated, contradictory in places, and partly stale. I need it sharp so every routine session runs better. Read my whole setup: - Global: ~/.claude/CLAUDE.md, ~/.claude/skills/, ~/.claude/settings.json, and my memory directory - Project: [PATH TO YOUR PROJECT]/.claude/ (CLAUDE.md, rules/, skills/, agents/, hooks/, settings.json, scripts/) Request: audit it like a senior AI engineer taking over my setup on day one, and tell me exactly how to make it work better for daily use. Judge each piece on: does it actually change model behavior, or is it dead weight? Where do rules contradict each other? What's stale — references to tools, models, or files that no longer exist? Which skills overlap or should merge? What's missing that I clearly need? Is my CLAUDE.md too long to be followed reliably, and what should move to skills or memory? Output format: a prioritized report at ~/.claude/harness-audit/README.md. Every finding tagged P0–P3, with the exact file + line, the concrete fix, and whether it's a quick win (safe to apply now) or a judgment call (needs my sign-off). End with the 5 changes that would most improve my daily sessions and the 5 safest quick wins you can apply the moment I say go. Constraints: the deliverable is your assessment. Report and stop. Do not edit, delete, merge, or rewrite anything until I say go — this is my live setup and a wrong change breaks real automations. Don't assume a skill is unused just because it looks redundant; flag it, don't touch it. Ask any clarifying questions up front, then produce the report end-to-end.
Why it works. The cheapest, safest run to start with. It only reads. You get one prioritized report, and every fix you apply makes every future session sharper. Watch for the token count it flags before you type a word — most people are shocked how heavy their setup got.
2. Website design + SEO audit
Have it boot your site, screenshot every page, and hand you a ranked redesign plan built around getting found in search.
Plan + screenshots. Run from your website project folder.
I'm redesigning [YOUR WEBSITE URL] (built with [YOUR STACK, e.g. Astro / Next.js / WordPress]) to be cleaner, more polished, and far more discoverable in search. Priority #1 is getting found in search; then a cleaner, more polished look; then making my content easy to browse. Request: audit the site like a senior design + SEO lead on their first day, then give me a redesign plan. Boot the local dev server and screenshot every public page (desktop + mobile). Cover: 1. SEO (top priority) — per-page titles, descriptions, and canonicals; structured data (Organization / Person / WebSite / Breadcrumb / Article); default OG images; sitemap and robots hygiene (make sure any private or admin pages aren't leaking into search); internal linking; and how to make individual pages actually rank. 2. Information architecture — how a visitor picks a topic and lands on the right content, resources, and products in one place. Give a concrete nav + page structure with 2 layout options for the main hub. 3. Resources / library page — propose a cleaner, organized, filterable structure. 4. Design system health — flag dead or duplicated CSS, token duplication, and the missing reusable components that would make the redesign maintainable. Key files to read first: [LIST YOUR KEY FILES — e.g. the layout/head file, the global stylesheet, nav + footer, the homepage, the content model]. Treat any admin, dashboard, or API routes as private — audit them only for search or security leakage. Output format: a prioritized plan at docs/site-audit/README.md, with screenshots in docs/site-audit/assets/. Every issue tagged P0–P3, which it hurts (SEO / understanding / trust / conversion), the exact file + line, and the specific fix. End with the 5 changes that most improve search discoverability and the 5 safe quick wins you can apply today. Constraints: fix only trivially safe things on the spot — a meta tag, a robots or sitemap exclusion, a typo, dead CSS you can prove is unused. Everything structural — new nav, new routes, the redesign itself — is a spec and recommendation only; do not implement until I approve. Never touch payment, checkout, auth, or API routes. Ask your clarifying questions up front, then run the audit end-to-end.
Why it works. A design + SEO audit is a perfect long-running task to hand off — it's read-heavy, visual, and the payoff compounds. The constraints matter: without the "spec only, don't implement" fence, a strong model will happily start rewriting your whole site.
3. Security + reliability audit
Turn parallel agents loose on your product to find what will break for a paying user before they find it. Findings only — nothing gets changed.
Report only. Run from your product repo.
I'm hardening [YOUR PRODUCT] — [the marketing site and/or the app] — in the repo [YOUR REPO]. Before I put more paying users on it, I need to know what will break in real use before they find it. This is an audit only: you produce the findings, and I'll hand the implementation to [me / my developer / another model] — so write every finding so it can be implemented cleanly from your report alone. Request: audit this codebase from first principles for reliability and security, then attack it. Don't pattern-match to generic checklists — start from what actually has to be true for a paying user's session to work end-to-end, and find where it isn't. Spin up parallel agents, each in one role: hostile user, careless user, performance, security, and data integrity. Each hunts only from its angle — what input breaks it, what edge case got skipped, where it crashes, leaks, loops, corrupts, or loses a user's data, or silently fails. Pay special attention to auth / session / token handling and access control (can one user reach another user's data?), the core pipeline, external API calls, payment or subscription state, and error handling on every write. Output format: one report at docs/reliability-audit/README.md, findings worst-first. Write each finding as a self-contained task: the exact trigger + reproduction, the file + line, the blast radius, a concrete proposed fix, and how to verify it (ideally a regression test to add). Separate "will break in production" (P0/P1) from "should fix eventually" (P2/P3). End with the 5 that would hurt a paying user most. Constraints: this is an audit — findings only. Do NOT change any code, migrations, or config. Don't defend the code; attack it. Don't touch production data or run anything destructive. Flag anything that needs a secret or credential I have to provide rather than guessing. Ask clarifying questions up front, then run the audit end-to-end.
Why it works. The "attack it, don't defend it" framing is what makes this work — models are trained to be helpful, so you have to explicitly give them permission to be adversarial. Findings-only keeps it safe to run against a live product, and the report is written so whoever implements the fixes can work straight from it.
4. Build a prototype in one pass
Get a polished, working first version out the door in one run instead of days of back-and-forth. Best after you spend 20 minutes planning on a cheaper model first.
Builds a working local prototype. Run at high or X-high effort.
I want to build [WHAT YOU'RE BUILDING — e.g. a simple internal dashboard, a client-facing prototype, an internal tool]. Here's the goal and why it matters: [ONE OR TWO SENTENCES ON THE OUTCOME YOU WANT AND WHO IT'S FOR]. Context to ground this: [PASTE OR POINT TO anything real — a rough plan, the data it should read (a spreadsheet, a sample file), an existing prototype to extend, your brand colors and fonts, and 1–2 examples of the look and feel you want]. Request: build the smallest version that actually works, end to end, in one pass. Make real design decisions — I want it to look polished, not like a wireframe. Wire it to the real data source above (read-only unless I say otherwise). Where you have to assume something, pick the most sensible default and note it rather than stopping to ask on every small thing. Output: a working [app / page / tool] I can run locally, plus a short list of the choices you made and the 3–5 things you'd polish next. Constraints: don't over-build — no features I didn't ask for, no speculative flexibility. Never write to or delete real user data, and never auto-post or publish anything. If a decision is genuinely irreversible or only I can make it, pause and ask. Otherwise keep going until it runs. Ask your clarifying questions up front, then build it end-to-end.
Why it works. Two-step move: first spend 20–30 minutes on a cheaper model (Sonnet, or Opus at medium effort) letting it interview you to get the plan on paper. Then paste that plan into the Context slot above and run this on a top model at high effort. The planning is where the quality comes from — the build is just execution.
5. Business + strategy audit
An honest outside-operator read on where your leverage is, what to cut, and the most credible paths to more revenue.
Writes a strategy memo. Reads whatever real context you point it at.
I run several things [solo / with a small team] and I want a hard, strategic outside read on where to focus to grow — especially revenue. My portfolio: [LIST YOUR BRANDS / PRODUCTS / INCOME LINES, one line each — what each is and roughly how it makes money]. My worry is that I'm spread too thin and leaving leverage on the table. Read my real business context to ground this — don't guess where you can read: [POINT TO anything real — your notes, plans, a strategy doc, a folder of context]. If you don't have files to read, work from what I tell you below. Request: audit my business like a sharp operator or advisor who just joined, and tell me where I could go better strategically. Specifically: where is my highest-leverage focus; what is spreading me too thin or should be cut or parked; how the brands do (or don't) reinforce each other; and the 3 most credible paths to more revenue. Be direct and rank everything by leverage, not by how much work I've already put in. Before you start, ask me for the few numbers that would change your answer — rough revenue per line, audience or list sizes, and how my week splits across these. Use them; don't invent them. Output format: a strategy memo — (1) the one-paragraph honest read, (2) a ranked "where the leverage is" list, (3) what to cut or park and why, (4) 3 revenue paths with the first concrete move for each, (5) the single thing you'd do this month if you were me. Flag every place you're inferring versus certain. Constraints: analysis only — don't change any files. Don't flatter me or hedge; if something should be killed, say so. Don't fabricate numbers, testimonials, or facts — mark unknowns as unknowns. Ask your clarifying questions up front, then write the memo end-to-end.
Why it works. Don't take the output as gospel — take it as a gut check. Its value is forcing you to defend the decisions you've already made, or admit you can't. Ranking by leverage instead of sunk effort is the line that makes it actually useful.
The one rule
If you take one thing from this pack, take this: nail the why behind your prompt — the goal and why it matters — and let the model figure out the how. Every prompt above gives it the outcome, the context, the output format, and a fence of constraints, then gets out of the way. You're not writing instructions for a script. You're briefing a very capable operator on what a good result looks like.
Fill the placeholders, set the effort high, let it ask its questions, and let it run. That's the whole thing.