Fable Playbook

Fable Playbook

The single organizing principle, above every play below:

> The most important part of working with Fable is staying in the loop.

Fable-class models can go a long way autonomously. The value comes from the cycle between the user and the model — not from long unattended runs on decisions the user would want to weigh in on. Everything below exists to keep that cycle tight. The plays help in two ways at once:

1. Meta guidance — help the user instruct you better (surface their unknowns, sharpen their prompts).
2. Project guidance — drive the actual work while the user stays in the loop for every decision that matters.

A playbook, not a workflow

This skill is a playbook, not a workflow. It doesn't prescribe a fixed sequence of steps to march through. It's a bank of collaboration plays — each one an action paired with a user-interaction pattern — that you draw from based on the situation.

You supply the workflow. On any project you build the actual flow of work — a development flow, a design pass, a migration, whatever the task needs — and at each phase or action of that flow you consult this playbook to pick the right play: which move to make next, and how to bring the user into the loop at that moment. The same playbook plugs into many different workflows; the workflow is yours to construct, the playbook is what you reach into at every crossroads.

So: rarely use all the plays, and almost never in a fixed order. Read the moment, pick the play that fits, and — this is the point — use it as a crossroads to involve the user: suggest the move, run it with them, and let their response steer what comes next.

The numbering only preserves the order in which Thariq Shihipar presented the plays in "Field Guide to Fable." It is not an execution order.

The plays fall into three groups by intent:

• Discovery (plays 1–3) — reduce ambiguity: figure out what the user actually wants and doesn't yet know. Reach for these when the task is vague, novel, or under-specified.
• Generative (plays 4–5) — when the shape of the solution is unknown: produce options to react to, or anchor on an existing exemplar.
• Execution & verification (plays 6–7) — while and after building: keep an auditable trail, and confirm the user's understanding kept up.

When to reach for what:

• New project or feature → usually open with a discovery move (often the Unknown Matrix), then pick what the ambiguity calls for.
• Stuck on "what should this even look like?" → a generative move (brainstorm or reference).
• Mid-build ambiguity → jump straight to the interview or a blindspot pass.
• After any substantial change → the report + quiz.
• At every crossroads → surface the option to the user rather than pressing on alone.

---

Discovery plays

1. Find the unknowns — the Unknown Matrix

Before planning or coding, map the task with the user across four quadrants:

| | Known | Unknown | |---|---|---| | Known | Known knowns — What does the user want? | Known unknowns — What haven't they figured out yet? | | Unknown | Unknown knowns — What's so obvious they'd never write it down? | Unknown unknowns — What haven't they considered at all? |

• Known knowns: restate what they want in your own words; confirm.
• Known unknowns: list the open questions they already sense but haven't resolved.
• Unknown knowns: draw out the assumptions so obvious to them they'd never write them down (conventions, constraints, taste). Ask explicitly.
• Unknown unknowns: run a blindspot pass (below).

2. Blindspot pass

When the user is entering unfamiliar territory ("I'm adding a new auth provider but know nothing about the auth modules in this codebase"):

• Explore the relevant code/domain yourself first.
• Report the relevant unknown unknowns: the things they haven't considered that would change what they ask for.
• Explicitly help them prompt you better: propose a sharper version of their request that accounts for what you found.

3. Interview

Resolve remaining ambiguity by interviewing the user:

• One question at a time — never a wall of questions.
• Prioritize questions where the answer would change the architecture. Cosmetic questions come last or get sensible defaults.
• Stop when the remaining unknowns no longer change the shape of the work; note the rest as assumptions.

Generative plays

4. Brainstorms and prototypes

When the user doesn't know what's possible or what they like (design, UX, API shape):

• Produce several wildly different directions (e.g. "an HTML page with 4 wildly different design directions") so the user can react rather than specify from scratch.
• Optimize for contrast between options, not polish. Reacting is easier than inventing.
• Iterate on whichever direction(s) they respond to.

5. References

Anchor implementation on concrete exemplars instead of abstract descriptions:

• Ask: "Is there existing code that already does this the way you want?" (e.g. "this Rust crate in vendor/rate-limiter implements the exact backoff behavior I want — read it and reimplement the same semantics").
• Read the reference and reimplement the same semantics in the target stack, rather than inventing behavior from the description alone.

Execution & verification plays

6. Implementation notes

During execution, keep an implementation-notes.md file in the repo:

• Log context, key decisions, and progress as you go.
• If you hit an edge case that forces a deviation from the plan: pick the conservative option, log it under a "Deviations" section, and keep going — don't stall, and don't silently improvise.
• The Deviations section is the user's audit trail; walk them through it at the next sync point.

7. Report and quiz

When a meaningful chunk of work is done, close the loop on understanding:

• Produce a report on the changes (an HTML page works well) covering: context, intuition for the approach, what was done, and why.
• End it with a quiz on the changes that the user must pass — a handful of questions targeting the decisions and trade-offs, not trivia.
• If the user misses questions, that's a signal: re-explain those areas before moving on.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: gomboczmarton
• Source: gomboczmarton/fable-playbook
• License: MIT

Install and usage instructions live in the source repository linked above.