How to Find Your Unknowns When Prompting Claude Fable 5

Key takeaways

1. Framing metaphor: the map is not the territory. The map = what you give Claude (prompts, skills, context). The territory = where the work happens (codebase, real world, constraints). The gap between the two = the unknowns. Faced with an unknown, Claude decides based on its best guess of what you want → the larger the work, the more unknowns it encounters.
2. The Fable plateau. "Fable is the first model where I find the quality of the work is bottlenecked by my ability to clarify its unknowns" — the bottleneck has shifted from the model to human clarity. Planning ahead isn't enough: unknowns surface mid-implementation, or reveal that the problem needed to be solved differently. → an iterative process: discovering your unknowns before, during, and after.
3. The 4 quadrants (unknowns matrix). Known knowns = what's in the prompt (what you say you want); Known unknowns = what you haven't resolved yet but are aware of; Unknown knowns = "too obvious to write down, but I'd recognize it" (the "I'll know it when I see it"); Unknown unknowns = "the pothole you didn't know the road could have".
4. The real skill. "reducing and planning for your unknowns is THE skill of agentic coding". The best (cites Boris, Jarred) have few unknowns (in sync with both the codebase AND the model's behaviors) but assume some remain. Good news: it's a skill that improves by working with Claude.
5. Instructing Claude is a delicate balance. Too precise → Claude follows the instructions even when a pivot would be better. Too vague → Claude fills in with industry best practices, not necessarily suited to the case. Without managing your unknowns, you fail on both sides. Remedy: give Claude context on your starting point (where you are in your thinking, your experience with the problem) and treat it as a thought partner. Claude searches the codebase and the web very fast and iterates from failure faster than we do.
6. BEFORE — Blindspot pass. when working in unfamiliar territory (unknown unknowns), ask Claude to find and explain its blind spots. Use the literal words "blindspot pass" and "unknown unknowns" plus context on who you are. E.g. "I'm adding a new auth provider but I know nothing about the auth modules… do a blindspot pass"; "teach me to understand my unknown unknowns about color grading so I can prompt better".
7. BEFORE — Brainstorms & prototypes. for unknown knowns (criteria you can only define by seeing them, e.g. visual design). Verbalize them early, since discovering them during implementation is costly (a small spec change can mean radically different code, hard to revert). Start almost every session with an exploration/brainstorm phase to frame the scope (neither too narrow nor too broad). E.g. "make me an HTML page with 4 wildly different design directions so I can react to them"; "mock the new toolbar in a single HTML file with fake data before you touch the real app"; "brainstorm 10 places we could intervene, cheapest to most ambitious".
8. BEFORE — Interviews. after brainstorming, ask Claude to interview us on the remaining ambiguities, one question at a time, prioritizing "questions where my answer would change the architecture".
9. BEFORE — References. when you can't describe what you want, the best reference is source code. Point Fable to a folder/library (even in another language) and say what to look for there. Claude Design works this way: pointed at a site's module, it reads the underlying code (markup, structure, actual construction), not just the screenshot. E.g. "this Rust crate implements the exact backoff I want — reimplement the same semantics in our TypeScript client".
10. BEFORE — Implementation plan. ask for a plan led by the decisions most likely to change (data models, type interfaces, UX flows) and relegating mechanical refactoring to the bottom ("I trust you on that part"). The plan surfaces what you'll actually need to alter.
11. DURING — Implementation notes. however much planning is done, unknown unknowns remain (the agent finds an edge case while coding). Have Claude Code keep a temporary implementation-notes.md logging decisions "so we can learn from our next attempt". E.g. "if you hit an edge case that forces a deviation, pick the conservative option, log it under 'Deviations', and keep going".
12. AFTER — Pitches & explainers. shipping means getting buy-in and approvals. Package prototype + spec + notes into a single doc that "lead[s] with the demo GIF" → speeds up understanding (reviewers start from the same unknowns as you) and approvals (experts want to see their failure points were covered).
13. AFTER — Quizzes. after a long session, reading the diffs only gives a superficial understanding (behavior depends on existing code paths). Ask Claude for an HTML report + a quiz on the changes — "I only merge after I pass the quiz perfectly".
14. Proof by example: the Fable launch video. , edited entirely with Claude Code in a domain Thariq didn't master — he starts from what he knows (Claude can edit/transcribe video through code), has Whisper/ffmpeg explained, prototypes a word-timed UI via Remotion, then has Claude teach him color grading (having no idea what "good" means) instead of blindly generating variants.
15. Punchline. "every explainer, brainstorm, interview, prototype, and reference is a cheap way to find out what you didn't know before it gets expensive to fix" → "start your next project by asking Claude to help you find your unknowns". The residue of learning becomes the map for next time ("what you learn becomes the map for next time").
16. Links. converges with the Compounding Knowledge Lifecycle (capitalizing on what's learned), loop engineering, and the note [[willison-fable-judgement-delegation-subagents-2026-07-03]] (same author cited, Thariq, same moment on Fable) — two complementary facets: Willison on letting Fable judge, Thariq on reducing your own unknowns to better guide it.