blindspot git:20260711.7cbcd32A

Immutable. This exact content is served forever at /api/v1/blob/f77de930f091fc83.

---
name: blindspot
description: 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.
argument-hint: "the task or area to scan for unknowns"
---

# Blindspot

The work file, the prompt, the glossary — all map. The codebase, its history, its real constraints — territory. The gap between them is the unknowns, and an unknown left unfound doesn't stay unfound: the diff review finds it, or production does.

Sort any unknown into one of four kinds; the flow already mines three:

| Kind | What it is | Who finds it |
|---|---|---|
| Known knowns | Already written down | The work file carries them |
| Known unknowns | Questions you know are open | Wonder settles or parks them |
| Unknown knowns | Obvious to the user, never said | The interview extracts them |
| Unknown unknowns | On nobody's question list | **Only the territory can surface them — this skill** |

An interview can't reach the fourth kind: it only asks questions someone thought to ask. This skill owns three moves for the moments the map is furthest from the territory. Each feeds a stage; none replaces one.

## Move 1 — the territory pass (before the work)

When work enters an area the user names as unfamiliar, when interview answers keep coming back "I don't know", or when a whole discipline nobody on the work has judgment in walks in (a new subsystem, a new domain entirely) — walk the territory before anyone writes the brief.

Read only — the code, its tests, its docs, and its history (log and blame of the area; reverted commits and bug-fix clusters are where it bit last time). Spawn the pass as a fresh subagent **on a frontier-tier model — the session's main model or better, never a cheaper one**. Hunting unknown unknowns is judgment, not reading: a cheap model reliably collects the potholes that are written down and then mis-calls the ones that aren't — measured twice (a greenfield pass that recommended the exact render path the project's fixed constraint forbade, corrected only by two later frontier stages; a 9/10-scored pass whose recommendations included quietly disabling a safety net). The report anchors every stage after it; this is the wrong place to save money. The subagent is still worth it for the fresh context — the main session consumes the report instead of re-walking the files. Then report four things, nothing else:

1. **Questions you didn't know to ask** — decision points the territory forces that the ask never mentions. Each arrives as a question with your recommended answer, same discipline as the interview.
2. **What "good" looks like here** — the conventions, invariants, and quality bars this area already enforces; what a reviewer of this area would reject without discussion.
3. **Potholes** — where this area has bitten before, with the evidence: the reverted commit, the FIXME cluster, the test named after a bug. No history of bites? Say so — potholes are found, never manufactured.
4. **A sharper ask** — the user's request rewritten with the found unknowns settled or explicitly parked. Offer it back: "this is what I'd put in the brief."

Before offering any of it, collide your recommended answers with your own findings: a recommendation that quietly disables a safety net you just reported as a pothole, or divides money you just said must not be divided, is the pass contradicting itself — and it reads authoritative precisely because the rest of the report is right.

Route the findings where they live: questions join the interview (`/wonder`), a term that wobbled goes to the `domain-glossary` skill, potholes become attack material for `/discern`, the sharper ask goes into the work file. Findings carry their evidence (the commit, the file, the test name) so consuming stages cite the report instead of re-exploring — a pass that gets re-verified file by file cost double and bought nothing. The pass writes no code and checks no gate — it exists so the stages that do have real material.

## Move 2 — teach before judging (at a choice)

Watch for it whenever the user is confirming a choice — options from Invention, Discernment's recommendation, prototype directions. "Whichever you think", "they all look fine", an outright "I can't tell": that isn't agreement, it's a judgment gap. A confirmation from someone who can't evaluate the choice is an unknown wearing an approval, and it comes back later as "this isn't what I wanted."

Name the dimensions along which the options actually differ. Teach just enough to hold an opinion — with material from *this* territory: a side-by-side, a before/after, the two lines that differ — not a lecture on the field. Then re-present the choice.

If the user can judge now, their confirmation means something — record it. If they still can't, that is a delegated decision: record your pick as `assumed:` (the `genius-file` skill owns the idiom) instead of dressing it up as user-confirmed. An honest `assumed:` beats a hollow "sure, option A" — the returning reader knows to look at one; the other lies to them.

## Move 3 — quiz the map (before acceptance)

Tenacity verifies the territory: tests run fresh, diff reviewed. Nothing verifies the user's *map* of it. Built work the user hasn't absorbed is next month's unknown knowns — decisions they now own and couldn't state.

When built work is about to be accepted — Tenacity's close-out offers this, and delegated or auto work all but demands it, the user having watched none of the build — summarize what actually changed at the behavior level (from the diff and the work file: what happens differently now, what they will have to live with), then quiz. A few questions, one per message, each aimed at a consequence — "an upload fails twice; what happens on the third try?" — never trivia like filenames or line counts.

A wrong answer is a finding about the map, not about the user: the explanation was thin or the change genuinely surprising. Repair the map — re-explain, or write the missing line into the work file or docs — then ask again. The quiz checks no gate; the work's evidence is Tenacity's job. Its finish line is the user answering clean — so they accept knowing what they accepted.

## What this skill is not

- **Not the interview.** Wonder extracts what the user knows and never said; this skill surfaces what nobody knew. A territory-pass finding that needs a user decision becomes an interview question — Wonder's, not this skill's.
- **Not review.** Tenacity's reviewer judges the work against the brief; the quiz judges the user's map against the work. Either can fail while the other passes.
- **Not divergence.** Invention owns generating options; Move 2 only teaches how to choose among options that already exist.
- **Not a stage.** It has no gate and never sets `stage:`. It feeds the gates the stages own.