If you remember one sentence, make it this:
Fable rewards ambition when the boundaries and verification are concrete.
That is the shift.
With older models, the safe move was often to decompose the work into small steps and tell the model exactly what to do. With Fable 5, that can become the limiting factor. If you over-specify the path, you replace the model's search, judgment, and ability to integrate context with your first guess.
The better move is to delegate a bounded mission.
You give Fable the outcome. You give it the territory. You give it house rules. You give it a hard bar for done. Then you use unknown discovery, references, prototypes, implementation notes, and independent review to keep the work grounded.
This is how to build with Fable 5.
Fable is not just better at following instructions. It is better at carrying intent through a messy build.
That changes the unit of delegation.
Do not delegate tiny procedural steps when the model can own the mission. Delegate the outcome, then manage the conditions around the work.
Weak delegation:
Create these files. Add this hook. Use this state shape. Put a button here. Wire it to this endpoint.
Stronger delegation:
Build the first version of a support command center for account managers. They should be able to see customer health, spot urgent accounts, and take the next action without leaving the page. Use the existing app patterns unless there is a strong reason to change them.
The second version lets Fable inspect the codebase, find patterns, choose interfaces, notice gaps, and propose a plan. You still control the build, but you control it at the level that matters.
Every serious Fable build should start with a contract.
Goal:
What should exist when the work is done?
Territory:
What repo, product area, users, constraints, prior work, references, and external systems matter?
House rules:
What must remain true no matter how Fable solves the problem?
Done bar:
What observable evidence proves the work is good enough?
Unknowns:
What does Fable need to discover before the plan is trustworthy?
Permissions:
What can Fable run, spend, create, modify, delete, or decide without asking?
Review:
Who or what attacks the result before you trust it?
This contract is the difference between letting Fable run and letting Fable guess.
Start with the user outcome or system outcome. Avoid prematurely choosing the implementation unless the implementation itself is the point.
Good goals describe:
- Who the work is for
- What they should be able to do
- What should be easier, faster, safer, or more reliable
- What existing constraints matter
- What kind of evidence would make you trust the result
Prompt:
I want to build [goal].
Treat this as an outcome, not a prescribed implementation. Inspect the relevant repo areas and propose the best path using existing patterns. If my suggested approach is worse than another approach, say so and explain the tradeoff before implementing.
Use this when your first idea may be too narrow:
I have a possible implementation in mind, but do not anchor on it. First, tell me whether this is the right shape of solution for the goal. If there is a simpler, safer, or more idiomatic path in this codebase, recommend it.
House rules are how you give Fable room without losing control.
They are not steps. They are invariants.
Use rules like:
House rules:
- Prefer existing project patterns over new abstractions.
- Keep changes scoped to the feature unless a broader change is necessary.
- Do not add dependencies unless they clearly reduce complexity.
- Do not change persisted data shape without explaining migration and rollback.
- Do not make destructive, irreversible, security-sensitive, or high-spend changes without asking.
- For agent behavior, prefer clear model instructions over brittle hard-coded special cases.
- For UI work, verify the real rendered app at desktop and mobile sizes.
- The builder does not grade its own work. Use a fresh reviewer context.
House rules should be short. If you have twenty, you probably have a spec, not house rules.
"Make it good" is not a bar. It is a vibe.
Fable needs a pass/fail target. If you do not know how to measure the target, make measurement the first deliverable.
Prompt:
Before building, define the done bar.
Include:
- User-visible behavior
- Technical behavior
- Error and edge states
- Regression protection
- Runtime or browser evidence
- What would make this unacceptable
If the goal is hard to measure, propose a practical measurement strategy first.
Examples:
The onboarding flow is done when a new user can complete it from a clean account, refresh halfway through, recover from validation errors, and land on the expected next screen.
The import pipeline is done when valid rows are idempotent, malformed rows produce useful reports, partial failure behavior is documented, and rerunning the same file creates no duplicates.
The UI clone is done when a fresh reviewer comparing screenshots at mobile and desktop sizes cannot identify meaningful differences from the reference without inspecting the code.
This is where Fable gets much more useful. You can ask it to invent the measurement strategy, then run against it.
This is the lesson from the field guide by Tariq (Claude Code at Anthropic).
Your prompt is the map. The codebase, users, edge cases, constraints, and domain are the territory. The gap is where Fable has to guess.
Unknowns come in four types:
| Type | What It Means | Best Move |
|---|---|---|
| Known knowns | You can state it clearly | Put it in the contract |
| Known unknowns | You know it is undecided | Ask for options or an interview |
| Unknown knowns | You will recognize it when you see it | Ask for prototypes |
| Unknown unknowns | You do not know what to ask | Ask for a blindspot pass |
The best Fable users are not people with perfect prompts. They are people who surface the right unknowns early.
Prompt:
Do a blindspot pass before implementation.
Inspect the relevant code, references, and domain. Identify unknown unknowns that could change:
- Architecture
- UX
- Data model
- Integration boundaries
- Security or permissions
- Cost or latency
- Verification strategy
Separate what I specified from what you inferred. For each important inference, say whether it is low-risk, reversible, expensive to change later, or something you need to ask me about.
Fable should not spend questions on things it can discover.
Bad interview:
What should I name the file?
Should I run tests?
Should I follow existing patterns?
Good interview:
Should this workflow optimize for speed by allowing partial success, or for correctness by making the whole operation atomic?
Prompt:
Interview me one question at a time. Only ask questions where my answer would change architecture, UX, data shape, permissions, dependencies, or verification. If the answer can be found by reading the repo, read the repo instead.
This keeps you involved where your judgment matters and out of the way where Fable can discover the answer itself.
When words are weak, use references.
References are not decoration. They are compressed judgment.
Useful references:
- A previous successful build
- A component or workflow in the same repo
- Source code from another project
- A live product
- A screenshot or screen recording
- A design system
- A spec or API contract
- Prior implementation notes or session traces
Prompt:
Use [reference] as the behavior and quality reference. Study its structure, edge cases, interaction details, and intent. Recreate the relevant behavior in this codebase's patterns. Do not copy blindly.
For visual or taste-based work:
Before touching the real app, create 3 disposable prototypes with fake data. Make them meaningfully different in layout, density, interaction model, and visual direction. The goal is to expose taste and product decisions early.
If you only know what you want when you see it, do not pretend otherwise. Make Fable generate things you can react to.
A useful plan is not a file-by-file checklist. It is a decision surface.
Prompt:
Write an implementation plan. Lead with decisions that are expensive to change:
- Data model and type changes
- User-facing behavior
- UX flow
- Integration boundaries
- Error handling
- Permission and security implications
- Verification strategy
Put mechanical edits at the bottom. Mark assumptions clearly. For each assumption, say whether you will verify it, proceed with it, or ask me.
You are not trying to remove all improvisation. You are trying to make sure Fable improvises inside the right boundaries.
Some unknowns only appear during implementation. That is normal.
For meaningful work, require implementation notes.
Prompt:
Create and maintain implementation-notes.md while you work.
Track:
- Original goal
- Final plan
- Decisions made
- Deviations from the plan
- Edge cases discovered
- Commands run and results
- Verification evidence
- Remaining risks
- What a reviewer should inspect first
If you need to deviate, choose the conservative path, log the deviation, and continue unless the decision is irreversible, costly, destructive, or security-sensitive.
This turns a long agent run into something you can review, reuse, and learn from.
The notes matter because Fable compounds on prior work. Your best previous builds become references for the next build. The implementation trail is part of the asset.
The builder has a narrative. It remembers why it made each choice. That makes it too forgiving.
Use a fresh reviewer context.
Prompt:
Review this from a fresh context. Try to prove it is not done.
Check:
- Original goal
- House rules
- Done bar
- Implementation notes
- Actual runtime behavior
- Tests and regression coverage
- Security, data, and edge cases
Prioritize blockers over style preferences. Give concrete evidence for every issue.
For UI, the reviewer should inspect the running app.
For backend, the reviewer should trace data, failure modes, auth, idempotency, observability, and rollback.
For creative work, the reviewer should compare output to the reference and measurement bar.
The loop is the work.
Build.
Measure.
Find the biggest gap.
Fix it.
Measure again.
Repeat.
Prompt:
Run a verification loop. After each pass, identify the highest-impact gap between the current result and the done bar. Fix that gap, then verify again. Continue until no blocker remains or you need a decision from me.
For long runs:
Maintain a progress artifact with current status, screenshots or command evidence, completed checks, open risks, and the next gap being closed.
This prevents the most common failure mode: stopping at plausible.
At the end, you need enough understanding to own the change.
Prompt:
Package this change for review.
Include:
- What changed
- Why this approach was chosen
- Important unknowns discovered
- Deviations from the plan
- How to verify the behavior
- Test and runtime evidence
- Screenshots, if relevant
- Residual risks
- Follow-up tasks that should not block this change
For large changes:
Teach me this change, then quiz me on behavior, data flow, edge cases, and likely future regressions. I should not merge until I can answer perfectly.
If you cannot explain the result, you are not ready to own it.
Use:
- Short contract
- Quick blindspot pass
- Plan focused on expensive decisions
- Implementation notes only if the work spreads
- Fresh reviewer
Prompt:
Build [feature]. First inspect the repo and do a quick blindspot pass. Tell me the important assumptions and the done bar. Propose a short plan focused on expensive-to-change decisions. After approval, implement, verify real behavior, and have a fresh reviewer try to prove it is not done.
Use:
- Domain primer
- Blindspot pass
- Interview
- References
- Prototype
- Strong done bar
- Quiz at the end
Main risk:
You do not know what good looks like yet.
Use:
- References
- Multiple prototypes
- Screenshot or pixel evidence
- Fresh visual reviewer
- Iteration loop
Main risk:
Language is too low-bandwidth for taste. Make artifacts you can inspect.
Use:
- Deep architecture options
- Explicit tradeoffs
- Migration and rollback thinking
- Strong tests
- Independent review
- More time before implementation
Main risk:
A bad foundation compounds.
Use only when boundaries are clean.
Roles:
- Builder agents own scoped workstreams.
- Reviewer agents challenge each workstream.
- Integrator agent merges, resolves overlap, and tests the combined product.
Prompt:
Split this into parallel workstreams only where boundaries are clean. For each stream, define ownership, likely files touched, dependencies, verification evidence, and integration risks. Assign one final integrator to test the combined behavior like a real user.
Symptom:
You prescribe every file and function before Fable has inspected the territory.
Fix:
State the goal, constraints, and done bar. Ask Fable to inspect and propose the path.
Symptom:
You ask for "clean", "polished", "production-ready", or "high quality" without a testable bar.
Fix:
Define observable pass/fail evidence.
Symptom:
The same context that built the feature declares it complete.
Fix:
Use a fresh reviewer context that tries to prove the work is incomplete.
Symptom:
Fable starts coding while architecture, UX, data, or verification assumptions are still hidden.
Fix:
Run a blindspot pass and interview only on build-changing decisions.
Symptom:
The result looks reasonable, but no one checked real behavior against the bar.
Fix:
Loop against the biggest remaining gap until the done bar is met or the risk is explicit.
Use this for serious builds.
I want to build: [goal].
Context:
- Product/user outcome:
- Repo/app area:
- What I already know:
- Known unknowns:
- References:
- Constraints:
- Budget and permissions:
House rules:
- Prefer existing patterns unless there is a strong reason not to.
- Do not add dependencies without explaining the tradeoff.
- Do not make irreversible, costly, destructive, security-sensitive, or high-spend changes without asking.
- Verify real behavior, not just code shape.
- Use a fresh reviewer context before calling the work done.
Done bar:
- User-visible behavior:
- Technical behavior:
- Edge/error states:
- Regression protection:
- Evidence required:
- Rejection criteria:
Workflow:
1. Inspect the relevant code and references.
2. Do a blindspot pass and identify unknown unknowns.
3. Interview me one question at a time only where my answer changes architecture, UX, data, permissions, dependencies, or verification.
4. If the work is visual or taste-based, create disposable prototypes before changing the real app.
5. Write an implementation plan focused on expensive-to-change decisions.
6. Build while maintaining implementation-notes.md.
7. Run tests and verify real behavior.
8. Use a fresh reviewer context to attack the result against the goal, house rules, and done bar.
9. Fix the highest-impact gap and repeat until the bar is met.
10. Produce a reviewer packet. For large changes, quiz me.
Use this for everyday builds.
Build [goal]. Treat this as an outcome, not a prescribed implementation. Inspect the repo, do a quick blindspot pass, identify assumptions, and propose a done bar. Then give me a short plan focused on expensive-to-change decisions. After approval, implement, verify real behavior, and use a fresh reviewer context to try to prove it is not done.
The people who get the most from Fable are not writing magical prompts. They are creating better conditions for ambitious work.