GreatMark Blindspot Pass
Help the user discover their unknown unknowns before work starts. This is a read-only pass: do not modify any files.
Workflow
- Anchor on the user's starting point. If not already clear from the conversation, ask once — a single short message, at most three sub-questions — about their experience with this problem and codebase, what they have already decided, and what they plan to do next. If asking is not possible (e.g. an unattended/CI run), the user deflects ("just go"), or the reply does not answer the questions, state your assumptions in one line — folding in whatever they did say — and proceed.
- Explore the territory. Start from the files the task will touch — or, when the user is adopting an area rather than doing one task, its entry points (public API, main module, README) — and expand outward: direct dependencies/dependents, tests, docs, then git history of the touched files (not the whole repo). If history is unavailable (tarball, shallow clone, fresh repo) or the area is not code, use its changelog, release notes, or prior internal write-ups instead. For non-code areas (a SaaS tool, a business decision), expand the same way through official docs and pricing, adoption and migration post-mortems from other teams, the vendor's changelog and viability, and compliance constraints. In large codebases, cap this pass at roughly 15-25 file reads/searches: follow the 2-3 leads most likely to change the user's approach; if a lead stalls (slow search, missing tooling), drop it after one retry; when you hit the cap, stop and report, listing unexplored areas explicitly as unswept corners. If the domain is unfamiliar to you or fast-moving, search the web. Look specifically for things the user did not mention in their description of the task.
- Report blindspots directly in the chat response, in the language of the
conversation (do not create files unless the user asks for a document),
organized as:
- Questions you didn't know to ask — decisions hidden in this area (existing conventions, invariants, feature flags, edge cases; for non-code: pricing-tier traps, data-export paths, compliance).
- What "good" looks like — quality bars, reference implementations, or prior art the user should calibrate against.
- History and potholes — past attempts, known pitfalls, TODO/FIXME landmines, coupling that will bite.
- Domain concepts — if the domain is new to the user, teach the 3-5 concepts they need to evaluate results (not an encyclopedia).
- End with "how to prompt me better": 3-6 concrete things the user should specify in their next prompt now that these blindspots are visible. If "what good looks like" surfaced a concrete reference worth copying, suggest reference-hunt. If the remaining ambiguities would change the approach, can only be decided by the user, the session is interactive, and the user has not declined to answer questions, suggest running interview-me next; otherwise end after the prompt advice. If the area was simple (see Rules), shrink or skip this section.
Rules
- Prioritize blindspots that would change the user's approach; skip trivia.
- Cite checkable sources: file paths + line numbers, or URLs / commit hashes.
- If the area turns out to be simple with few blindspots, say so plainly instead of inventing findings.