Blindspot
The map — your prompt, your plan, your glossary — is not the territory: the codebase, its history, its real constraints. The gap between them is the unknowns, and an unknown left unfound doesn't stay unfound: the diff review finds it, or production does.
The concept: go look, at the three moments the gap is widest.
- Before unfamiliar work — walk the territory, read-only, as a fresh frontier-tier subagent: hunting unknown unknowns is judgment, not reading, and the fresh context means the main session consumes the report instead of re-walking the files. The code, its tests, its history — where it bit last time is the best predictor of where it bites next. Report whatever matters — questions nobody thought to ask, what "good" looks like here, potholes, a sharper ask; no taxonomy limits what counts. Every finding carries its evidence, and potholes are found, never manufactured.
- At a choice the user can't evaluate — "whichever you think" is a judgment gap, not agreement. Teach just enough of the actual difference to hold an opinion, then re-present the choice; if they still can't call it, an honest
assumed: beats a hollow confirmation.
- Before acceptance — nothing verifies the user's map of what got built. Summarize what changed at the behavior level, then quiz the consequences they'll live with. A wrong answer is a finding about the explanation, not the user: repair the map, ask again.
Standalone or inside a larger flow, the moves are the same. Findings route to whoever is shaping the work: questions into the conversation defining it, terms into the glossary, hazards to whoever judges the design.
1---2name: blindspot3description: Find the unknowns before they find the work — a read-only territory pass that surfaces the questions nobody knew to ask, judgment taught before a choice is extracted, and a quiz that catches the user's map up with what actually changed. Use when work enters territory the user calls unfamiliar, when the user is confirming a choice they can't evaluate, or when the user asks what they're missing or wants to be quizzed before accepting built work.4---56# Blindspot78The map — your prompt, your plan, your glossary — is not the territory: the codebase, its history, its real constraints. The gap between them is the unknowns, and an unknown left unfound doesn't stay unfound: the diff review finds it, or production does.910The concept: **go look, at the three moments the gap is widest.**1112- **Before unfamiliar work** — walk the territory, read-only, as a fresh frontier-tier subagent: hunting unknown unknowns is judgment, not reading, and the fresh context means the main session consumes the report instead of re-walking the files. The code, its tests, its history — where it bit last time is the best predictor of where it bites next. Report whatever matters — questions nobody thought to ask, what "good" looks like here, potholes, a sharper ask; no taxonomy limits what counts. Every finding carries its evidence, and potholes are found, never manufactured.13- **At a choice the user can't evaluate** — "whichever you think" is a judgment gap, not agreement. Teach just enough of the actual difference to hold an opinion, then re-present the choice; if they still can't call it, an honest `assumed:` beats a hollow confirmation.14- **Before acceptance** — nothing verifies the user's *map* of what got built. Summarize what changed at the behavior level, then quiz the consequences they'll live with. A wrong answer is a finding about the explanation, not the user: repair the map, ask again.1516Standalone or inside a larger flow, the moves are the same. Findings route to whoever is shaping the work: questions into the conversation defining it, terms into the glossary, hazards to whoever judges the design.