How to Use Claude to Uncover Your Unknown Unknowns

Map Is Not the Territory

Prompt, skill, and context supplied to Claude constitute a "map"; the actual codebase and real‑world constraints are the "territory". The gap between them represents the unknowns that Claude must guess.

When Claude encounters unknowns it can only infer the desired outcome. More work creates more unknowns; the first model where Thariq felt "blocked by its own ability‑card to clarify unknowns" was Fable.

Four Quadrants of Unknowns

Known‑known : explicitly written in the prompt.

Known‑unknown : recognized as not yet understood.

Unknown‑known : obvious enough to be recognized without being written.

Unknown‑unknown : completely unconsidered aspects.

Effective agentic coders keep unknowns minimal but assume they exist, planning to reduce them.

Techniques to Make Claude Surface Unknowns

1. Blind‑Spot Scan

Before work begins, ask Claude to locate unknown‑unknowns by mentioning “blindspot pass” and “unknown unknowns”.

"I am adding a new authentication provider to the project, but I know nothing about the auth module in this codebase. Can you do a blind‑spot scan to surface relevant unknown‑unknowns so I can craft a better prompt?"

2. Brainstorms and Prototypes

When many unknown‑knowns remain, have Claude generate several divergent directions. This is especially useful for visual design where the desired outcome is hard to describe.

"I want a dashboard for this data but have no visual taste. Give me an HTML page with four completely different design concepts so I can react to them."

3. Interviews

If brainstorming still leaves gaps, let Claude interview you question‑by‑question, prioritizing those that could affect architectural decisions.

"Interview me one question at a time on any fuzzy area, focusing on questions whose answers would affect architecture decisions."

4. References

The most reliable reference is the source code itself; point Claude at the relevant repository path.

"The Rust crate in vendor/rate‑limiter implements the back‑off behavior I need. Read its code and re‑implement the same semantics in our TypeScript API client."

5. Implementation Plans

Ask Claude to draft a plan that emphasizes parts likely to change: data models, type interfaces, and user flows.

"Write an HTML implementation plan that focuses on likely adjustments: data model changes, new type interfaces, and any user‑facing aspects."

6. Implementation Notes

During implementation, have Claude record decisions and note any deviations from the plan.

"Maintain an implementation‑notes.md file. If edge cases force a deviation, choose a conservative solution, log it under 'Deviations', and continue."

7. Pitches and Explainers

After completion, let Claude package the prototype, spec, and notes into a stakeholder‑ready document.

"Bundle the prototype, spec, and implementation notes into a document I can drop into Slack to rally support, opening with a demo GIF."

8. Quizzes

Before merging, have Claude generate a report and a quiz to verify understanding of the changes.

"Give me an HTML report that explains the changes—context, intuition, actions—and append a quiz at the end that I must pass."

Case Study: Fable Launch Video

Thariq used Claude Code to edit a launch video for Fable. Starting from the known capability that Claude can edit video via code and transcribe with Whisper, he let Claude explain Whisper, prototype with Remotion, then discovered a color‑grading issue he had not considered. Claude subsequently taught him proper color grading, illustrating how the process narrows the map‑territory gap.

Automation: David’s Skill

David encoded Thariq’s methodology into a reusable skill that scans the codebase, interviews the user, and performs a final unknown‑unknown scan. Using eval‑skills on Opus, the first run passed 0/2 tests; after three iterations it passed all tests and caught a hidden bug.

The skill is open‑source under the MIT license and can be installed with:

npx skills add dzhng/skills

Observation

Stronger models make unknowns more costly: with weak models, unknowns hide in vague outputs; with powerful models like Fable, they surface sharply, forcing clearer thinking. The described techniques aim to convert unknowns into knowns at minimal cost, locating them before they become expensive.