finding-unknowns

Topics in the source

• Finding Unknowns
• The Quadrant Walk
• Rules

The map is not the territory. The prompt, the plan, and the context window are the map; the codebase, the domain, and the user's actual intent are the territory. The gap between them is the unknowns — and an unknown found before code is written costs minutes, while the same unknown found three PRs later costs the three PRs. This skill is a guided conversation: the quadrant walk. Together with the user you fill in a four-quadrant map of the task, one quadrant per stage, and the user walks away holding the completed map. The map is the deliverable; implementation is a different task that starts only after the map is handed over. Two moves apply at every stage: Reacting beats imagining — for tacit unknowns. When the unknown is taste, shape, vocabulary, or "I'll know it when I see it", never ask the user to describe what they want when you can hand them something concrete to react to — a rendered option, a clickable mock, a decisions table. Reacting extracts knowledge the user has but cannot articulate unprompted. When the unknown is a factual constraint or an architectural decision, ask the highest-blast-radius question directly, with a recommendation. Every artifact assembles the rep

This is an excerpt. Refer to the complete source and its current requirements.