Blindspot

The user is about to work in territory they don't know. Two kinds of blindness live there: unknown unknowns (questions they don't know exist) and unknown knowns (assumptions too obvious to write down, and things they're sure of that are wrong). Convert the first into known unknowns, name the second, then hand back a map they can prompt with.

Boundaries: best-practices returns recommendations — this skill returns questions. Grilling stress-tests decisions the user can already defend — this skill maps territory where they can't answer yet. Neither a tutorial nor a plan.

Workflow

1. Surface the framing

Before asking anything, state as bullets: the assumptions the request takes for granted, and the missing information that would change the approach. This names the user's unknown knowns up front. If their goal or familiarity is still unclear, fold one calibration question into the first interview round.

2. Recon

Facts are your job, never the user's. Sweep before asking:

• Repo: Explore agent for existing patterns, conventions, and adjacent solutions.
• Tools and domain: find-docs for current APIs and config; WebSearch for pitfalls ("X gotchas", "X common mistakes") — pitfalls live in issue threads and post-mortems, not getting-started docs.