Blindspot

Blindspot

The user is about to work in territory they don't know. They may not know what questions to ask, what good looks like, what prior art exists, or which potholes are waiting. Survey the territory for them, then hand back a map they can prompt with.

This is not a tutorial (teach the minimum needed to prompt well) and not a plan (that comes after, from the sharpened prompt).

Workflow

1. Calibrate

If the invocation doesn't already say, ask one AskUserQuestion round covering: what they're trying to do, and their familiarity with the involved domain, tool, or codebase area. Skip this step entirely when their prompt already answers both. Never stretch calibration into a full interview (that's the grilling skill's job).

2. Survey the territory

Ground everything in current sources, not training data:

• Repo prior art: search the codebase for existing patterns, conventions, and adjacent solutions. Use an Explore agent for broad sweeps.
• Tools and libraries: invoke find-docs for current APIs and config. Add a WebSearch for pitfalls ("X gotchas", "X common mistakes"): pitfalls live in issue threads and post-mortems, not getting-started docs. For terrain dominated by one tool's setup choices, delegate the sweep to the best-practices skill instead. It covers both halves with parallel subagents.
• Non-code domains (design, audio, infra concepts): WebSearch for how practitioners judge quality in this domain.

3. Terrain briefing

Report compactly, in this order:

• Core concepts and vocabulary: the 3-7 terms needed to speak the domain, one line each
• What good looks like: how quality is judged here, so the user can recognize it when they see it
• Potholes: the mistakes that actually bite, each with its consequence
• Prior art: what already exists in the repo or the user's setup that this work should build on
• Decisions now visible: the choices the user didn't know they'd need to make, phrased as concrete questions

4. Hand off

End with:

• A sharpened prompt draft the user could send, with the newly visible decisions resolved where the survey answered them and listed as open questions where it didn't
• Offers, not auto-runs: resolve the open decisions now via AskUserQuestion, stress-test with the grilling skill, prototype, or enter plan mode

Constraints

• Teach to prompt, not to master. If the briefing exceeds roughly one page, cut.
• Cite what was surveyed (files, docs, sources) so the user can dig deeper.
• Never skip the survey and answer from training data. A stale briefing is worse than none: it creates false known-knowns.