blindspot
Surface the USER's unknown-unknowns before they work in unfamiliar territory and coach a sharper prompt. Use when: 'what am I missing', 'find my blindspots', 'blind spot pass', 'what do I not know here', 'sharpen this prompt', 'I am new to this area', or about to work in an unfamiliar area and the goal is a better prompt, not the codebase handoff /discovery:explore produces.
- License 许可
- MIT
- 最近更新
- 2026-11-15
- Stars
- ★ 30
- Forks
- 7
01 前言 Front Matter
- metadata
- { "summary": "Surface your unknown-unknowns and sharpen the prompt before unfamiliar work", "workflow-stage": "explore" }
- description
- Surface the USER's unknown-unknowns before they work in unfamiliar territory and coach a sharper prompt. Use when: 'what am I missing', 'find my blindspots', 'blind spot pass', 'what do I not know here', 'sharpen this prompt', 'I am new to this area', or about to work in an unfamiliar area and the goal is a better prompt, not the codebase handoff /discovery:explore produces.
- argument-hint
- [area-or-domain]
- user-invocable
- true
- disable-model-invocation
- false
02 资源文件 2
- 参考文档evals/evals.json6.1 KB
- 参考文档templates/blindspot-view.html6.1 KB
03 SKILL.md 正文
Arguments. [area-or-domain]. e.g., /discovery:blindspot geofencing, /discovery:blindspot payments module, /discovery:blindspot <domain-vocabulary>
Repository context. Gather first
Collect these with individual Bash calls, one command per call, never combined into a single invocation:
- Current branch,
git branch --show-current - Project root,
git rev-parse --show-toplevel
Treat a failure (not a repository, git unavailable) as an unknown value and carry on. Keep these as separate body Bash calls rather than pre-compute lines (gather-block convention, "The pre-compute block runs as one shell invocation").
These values orient this session only; resolve files against the project root while working.
Workflow
This skill builds the USER's knowledge, not the agent's: the deliverable is the user's understanding plus one improved implementation prompt, calibrated to their disclosed starting point rather than a fixed depth.
- Intake. Ask the user's starting point first (one question). What they already know bounds which gaps are worth surfacing.
- Scan. Two lanes, chosen by what is unfamiliar:
- Codebase lane. Read the target area (the codebase-reading, git-history, and project-structure
dimensions in
${CLAUDE_PLUGIN_ROOT}/skills/explore/reference/workflow.md) looking specifically for things the user's framing missed: existing patterns they'd duplicate, constraints they'd violate, historical decisions they'd re-litigate, adjacent code their change would break. - Domain lane. Build a lightweight vocabulary ladder grounded in sources fetched this session (repo files, official docs), never bare training recall. Right after the ladder, add a block of the quality axes experts judge the work by, with a worked good-vs-bad example per axis, each grounded in a source fetched this session. The axes are their own block ahead of the cards, not a card type. Each axis becomes a prompt-fix line in the improved prompt, which the user keeps or deletes like any other fix. A criterion the user's framing never named may also appear as a Missing concept card.
- Codebase lane. Read the target area (the codebase-reading, git-history, and project-structure
dimensions in
- Output. Blindspot cards, then ONE improved implementation prompt assembled from their prompt-fix lines (Output format below).
- Escalate when depth warranted. A domain too deep for a lightweight ladder gets a
recommendation to learn it in a structured way:
/education:teach topic <domain>when it is among the available skills, otherwise proper external research,/discovery:researchinvoked via the Skill tool.
Output format
Present each blindspot as a card:
- Type, one of four: Landmine (the change would break something non-obvious), History (a constraint whose reason the code no longer shows), Convention (an unwritten team rule the work must follow), or Missing concept (a domain idea the user's framing never named).
- Gap, the specific thing the user's current framing did not account for.
- Why it matters here, the concrete consequence in this codebase or domain, not a generic caution.
- Prompt-fix, a single copyable line the user can drop into their prompt to close the gap.
Then assemble every prompt-fix into ONE improved implementation prompt, wrapped in clear copy-start / copy-end markers so the exact text to reuse is unambiguous.
End with one scan-scope disclosure line: which lane(s) ran and what was and was not scanned (areas read, sources fetched). One line, not a methodology dump.
For a long card list, offer an interactive view in one sentence (cards filterable by type, a tick for each that was news, a copy-out of the reaction). The page is never written beside the cards, which stay the record. When the reader accepts:
-
Resolve the medium through the shared resolver. Add
--argument "<medium>"only when the reader named a medium in the request.<option>is this plugin'smediumoption,${user_config.medium}; pass""when that reads empty or as an unsubstituted placeholder. Read each option value from this text; never put a${user_config.*}string in a shell command.node "${CLAUDE_PLUGIN_ROOT}/lib/view-settings.mjs" resolve --lane discovery:blindspot --option "<option>"Take the medium from its JSON line only, never from a rendered-views settings file. The step is done when its report line and each notice line are printed as they stand. When
nodeis missing or the resolver exits non-zero, build nothing and say in one line why the view was not built. -
pagefalse: build nothing. The step is done: the cards stand. -
pagetrue: build the page only with${CLAUDE_PLUGIN_ROOT}/scripts/build-view.mjs, never by hand. Withpublishestrue, publish the printed file with the Artifact tool and give the link; when that tool is unavailable, hand back the path and say why in one line. Otherwise hand back the path. The step is done when the reader has the link or the path.
Build command, data shape, build failures and reply ids:
${CLAUDE_PLUGIN_ROOT}/reference/rendered-view.md,
steps 1, 2, 4 and 6 and its "Discovery: blindspot" section. The resolver above replaces steps 3 and 5.
This skill makes no changes and runs no open-ended external research: the domain lane fetches
official docs only to ground the ladder and quality axes, and anything deeper routes to
/discovery:research, invoked via the Skill tool. It does NOT write EXPLORE.md. When the scan's findings also serve
as stage-1 codebase exploration, offer to hand off to /discovery:explore, invoked via the Skill
tool, to persist the EXPLORE.md artifact.
Next
- The scan doubles as stage-1 codebase exploration:
/discovery:explore <area>. - The prompt is sharpened and ready to scope:
/planning:interview. - Unsure where this leaves the work, or arrived mid-flow:
/session-flow:workflow.
Gotchas
- Presenting training recall as domain fact. The domain lane grounds its vocabulary ladder and quality axes, good-vs-bad examples included, in sources fetched this session (repo files, official docs).
- Surfacing the agent's gaps instead of the user's. Cards name what the USER's framing missed, calibrated to their intake disclosure, not a generic audit of the area.
- Generic cautions in "why it matters". Each card's consequence is concrete to this codebase or domain; a caution that would read the same in any repo is not a blindspot.
- Writing an artifact by reflex. No
EXPLORE.mdunless the user opts into the explore handoff.
04 同仓库更多 Skills
track
Backlog reads through the bound tracker: search open and closed items, view one item with its comments and state history. Use when another skill searches or reads tracker items.
reviewer-media
Reviewer media for one pull request: decides whether it needs a narrated walkthrough, builds the storyboard from /review:explain-change's digest, has /explainer-video:produce render it and hands the manifest to /source-control:pull-request media. Use when asked for 'reviewer media', 'a walkthrough video for this PR', 'a produced video of this change', or when pull-request ready or monitor hands a PR over.
route
Model and effort per agent role (orchestrator, worker, verifier, retrieval) for a multi-agent run, resolved through the bundled defaults and the user, team and personal override config layers into fenced JSON with single-agent and fan-out variants and the layer behind each value. Use when asked 'which model for the subagents', 'route the roles' or 'model routing', or before a skill passes a role's model on a spawn.
route
Model and effort per agent role (orchestrator, worker, verifier, retrieval) for a multi-agent run, resolved through the bundled defaults and the user, team and personal override config layers into fenced JSON with single-agent and fan-out variants and the layer behind each value. Use when asked 'which model for the subagents', 'route the roles' or 'model routing', or before a skill passes a role's model on a spawn.
principles
Module-design vocabulary for architecture findings, and the checks built on it. Use when: 'what is a deep module', 'what is a seam', 'deep vs shallow module', 'what is the deletion test', 'leverage and locality', 'module design vocabulary', 'which word do we use for X in architecture findings'. Scanning a codebase for friction is /architecture:improve.
write
Structured five-field bug report (title, steps to reproduce, expected vs actual, justified severity, suggested fix location) from an informal description, read-only. Use when the user names a defect they observed, or asks for one written up ('report a bug', 'file a bug', 'write this up as a bug').