Prompting

Turn Your Whole Backlog Into Finished Plans in One Night

Spend your last free Fable 5 night mining your whole backlog into build-ready blueprints, so cheaper models build them for months. The exact prompt, the template, and the overnight loop are below.

11min read
4prompts to copy
4sections

The idea in one line. Fable 5 is Anthropic's planning and hard-problems model, so its real edge is not typing your work, it is turning a vague backlog into specs so exact that a cheap model (Sonnet or Haiku) can build them later without a single judgment call. You plan once tonight with the expensive brain, then cheap models cash the checks for a long time. Three pieces do it: the mining prompt, the blueprint template, and the batch loop.

Step 1The mining prompt

Paste this first. It stops Fable from writing code, forces it to read your real files, and makes it interview you before it plans anything. Watch for the line QUESTIONS FIRST, that is how you know it gated itself instead of guessing.

MINING PROMPT , PASTE INTO FABLE 5 FIRST
You are my planning model for this session. Anthropic positions you (Claude Fable 5) as their model for planning and hard, long-horizon problems, so I am spending you on exactly that: turning my whole backlog into build-ready blueprints. You will NOT write any product code, copy, or deliverables tonight. Your only job is to produce one blueprint per backlog item, each one exact enough that a CHEAPER model (Claude Sonnet or Haiku) can build it later, alone, without making a judgment call or asking a follow-up.
THE HANDOFF RULE (this is the whole game, read it twice):
The builder model cannot guess what I meant, cannot see me, and cannot ask me anything. So every blueprint must be exact enough that a mediocre model builds the thing correctly by following it literally, and no more verbose than that. If a sentence does not change what gets built, cut it. If a step still needs taste or a decision, the blueprint is not finished: make the decision yourself and write it down.
STEP 1 - GROUND YOURSELF BEFORE YOU PLAN.
IF I am running you inside a real project folder (Claude Code): first read this repo so every blueprint is grounded in what actually exists, not what you assume. Look at the folder structure, the package/dependency files, the README, the config, the existing naming conventions, and 3 to 5 representative source files. Then read my backlog file (path at the bottom). Do not invent files, libraries, endpoints, or features that are not in this repo or my backlog. If something genuinely is not in the repo yet, say so in the blueprint instead of guessing.
IF there is no repo (plain claude.ai chat): I will paste my backlog as a list. You have no files to read, so you must ask MORE clarifying questions up front, and you must ask me to paste any real sample you need (current landing page, brand colors, a past email, a data schema) rather than inventing my specifics.
STEP 2 - INTERVIEW ME FIRST. DO NOT WRITE ANY BLUEPRINT YET.
Before writing anything, ask me every clarifying question you need so the blueprints require zero guessing later. Ask ONLY questions whose answers would change what a builder produces: ambiguous scope, missing acceptance criteria, which existing file or module a change belongs in, data shapes, edge cases, which platform or tool I am on, what 'done' means to me. Group your questions by backlog item. If an item is already clear, say so and skip it. Ask the smallest set of high-value questions, not a survey. A wrong guess now costs me a whole wasted build later, so do not guess to save me time. When you are ready to ask, open your reply with the exact line 'QUESTIONS FIRST' so I know you gated yourself, then ask, then STOP and wait for my answers.
STEP 3 - THE ALTITUDE RULE.
After I answer, write each blueprint at exactly the altitude the cheap builder needs: detailed enough that Sonnet or Haiku executes it mechanically with no open decisions, but not so verbose that you restate obvious context or pad. Concretely: name the exact files to create or edit (real paths when you have a repo), give the exact functions/components/routes and their signatures or shapes, spell out the logic step by step, put exact copy or values where copy or values are needed, and list every acceptance check. No vague verbs like 'optimize' or 'improve'. If a step could be done two ways, pick one and say which.
STEP 4 - WRITE FOR THE CHEAP MODEL, BY NAME, COLD-START.
Address each blueprint to the model that will build it. Open every blueprint with one line, e.g. 'BUILDER: Claude Sonnet, working alone, cold start, cannot ask questions.' (Use Haiku for the simple ones, your call per item, and say which and why in one line.) Assume the builder opens only this one blueprint with zero memory of tonight, so restate all context it needs INSIDE the blueprint. If it is not written in the blueprint, it does not exist for the builder.
STEP 5 - OUTPUT FORMAT.
Produce ONE blueprint per backlog item, all in the identical structure from the template I paste next, in the same order as my list. Number them Blueprint 1, Blueprint 2, and so on. Do them ONE AT A TIME (the batch loop below controls this) so altitude and grounding do not drift. Do not dump them all silently.
MY BACKLOG: ./BACKLOG.md (change this path to wherever my list lives; or, in a plain chat, I will paste the list under the template)
SAVE EACH BLUEPRINT TO: ./blueprints/<short-slug>.md (in a plain chat with no folder access, print each blueprint in full and I will save it myself)
Confirm you have grounded yourself (read the repo, or noted there is no repo), then open with 'QUESTIONS FIRST', ask your clarifying questions, and stop.

Keep reading

Free, for an email.

Unlocks 3 more sections, 3 copy-paste prompts, the document version, and every other guide on the site, for free. Enter your email once to keep reading.

19,000+ follow where these guides come from.No spam. Unsubscribe in one click.

Read next