Working With Claude Fable 5, the Real Skill Is Finding Your Own "Unknowns" First
- Anthropic staffer Thariq published a long-form post summarizing a set of practical techniques for locating "unknowns" when working with Claude Fable 5.
- The core framework sorts unknowns into four types: known knowns, known unknowns, unknown knowns, and unknown unknowns.
- 8 specific techniques are spread across the "before / during / after implementation" stages, covering blind-spot passes, reverse interviews, reference source code, implementation notes, quizzes, and more.
- Every technique comes with the original English prompt you can copy and use directly.
- The case study section shows how this method was applied to editing the Fable launch video — a domain the author himself wasn't familiar with.
Working With Claude: What's Actually the Bottleneck
Thariq, a member of Anthropic's Claude Code / Claude Design team, published a long-form post on X on July 3, 2026, summarizing a set of practical techniques for locating "unknowns" when working with Claude Fable 5.
Coding alongside Claude Fable 5, the author found the quality of the work kept snagging on the same thing: whether he could put into words the "unknowns" he hadn't fully thought through himself. This piece breaks "finding your unknowns" down into 8 actionable techniques, each with a prompt you can copy straight off the page.
Why it's worth reading: the author is a member of Anthropic's Claude Code / Claude Design team, and the 8 techniques are distilled directly from real projects — including editing the Fable launch video — grounded in hands-on experience. Every technique comes with the original English prompt, ready to copy and use.
The old saying the author keeps coming back to: the map is not the territory. The map — a simplified description of the work to be done — is the prompt, skill, and context you give Claude. The territory is where the work actually happens: the codebase, the real world, its real constraints. The gap between the two is what he calls an "unknown." When Claude runs into an unknown, it can only make a decision based on its best guess at what you want. The more work there is to do, the more unknowns it's likely to run into.
The author says Fable is the first model that made him feel the quality of the work was bottlenecked by his own ability to articulate his unknowns. And planning ahead alone isn't always enough: an unknown can be buried deep in the implementation and only surface partway through, or it can flip around and tell you the problem actually needs a completely different approach. So working with Fable becomes a process of continually discovering your own unknowns before, during, and after implementation.
Which Kind of "Not Knowing" Are You Actually Missing
Whenever the author brings a problem to Claude, he starts by sorting his unknowns into four boxes. The bigger the job, the easier it is to fall into the last two boxes — the things you never even noticed, or the things so obvious you'd never think to write them down.
The part you spell out in the prompt — what you explicitly tell Claude you want.
Example "I want a login button, place it in the top-right corner."
The part where you know you haven't figured it out yet, but you're aware there's a gap here.
Example "Not sure yet whether this list needs pagination."
Common sense so obvious you'd never write it down — but you know it's wrong the moment you see it.
Example "This color scheme is too jarring — one glance and you know it's off."
A blind spot you never even considered — you don't even know how good this could be.
Example "Turns out code can automatically cut out the pauses in a video."