finding-unknowns

Finding Unknowns

Distilled from Thariq Shihipar's essay "A Field Guide to Fable: Finding Your Unknowns" (@trq212 — https://x.com/trq212/status/2073100352921215386). Community skill; not affiliated with or endorsed by Anthropic.

<Use_When>

• The user is starting work in a new domain or an unfamiliar part of the codebase
• The task involves taste — "I'll know it when I see it" criteria that resist specification
• The task is long-horizon and a wrong early assumption would compound
• A previous attempt came back wrong and the spec, not the execution, is the suspect
• The user says "blindspot pass", "unknown unknowns", "interview me", "brainstorm directions", "quiz me", or "Cartographer mode" </Use_When>

<Do_Not_Use_When>

• The request is specific and trivial (typo, one-liner, obvious bug fix) — execute directly
• The user has a detailed spec with file paths and acceptance criteria — go build it
• The user wants ontology/entity-convergence tracking or OMC-native state/pipeline machinery (autopilot/ralph/team handoff) — use oh-my-claudecode:deep-interview instead; Cartographer covers ambiguity gating and an approval-gated bridge without that runtime
• The user explicitly says "just do it" — respect that; offer one sentence of risk if material, then proceed </Do_Not_Use_When>

<Why_This_Exists> Model capability is no longer the bottleneck on long-horizon work; clarity is. Generic requirements gathering asks "what do you want?" — but users cannot answer for the unknowns they are not aware of. This skill's premise is that different kinds of unknowing need different instruments: blind spots need reconnaissance, tacit taste needs reaction to prototypes, nameable gaps need targeted questions, and comprehension needs examination. A single uniform interview under-serves all four. </Why_This_Exists>

<Execution_Policy>

• ALWAYS locate the unknown on the quadrant map (Phase 0) before choosing a technique
• Establish the user's starting point — where they are in their thinking, their experience with this problem and codebase. The same task needs different probing for an expert than for a first-timer
• Discovery ends at understanding. No discovery technique slides into implementation
• Never ask the user a question the territory can answer — explore the codebase first
• Interview via AskUserQuestion (clickable options). Up to 3 independent questions per round, ordered by blast-radius/regret; never bundle dependent questions — where one answer would change the next question's framing, ask those one at a time
• Architecture-changing unknowns outrank trivia, always
• "You have no significant unknowns here" is a valid and valuable result — say it plainly rather than manufacturing concerns
• Deviations get logged, not buried. Comprehension is the merge gate, not a green diff
• Prefer single-file self-contained HTML artifacts for anything the user must react to or review (prototypes, plans, quiz reports); markdown fallback for pure-terminal flows
• Delegate to companion agents when installed and the case is non-trivial; run inline otherwise. Every technique works standalone </Execution_Policy>