| name | blind-spot-scanner |
| description | Audits knowledge gaps before executing in new technical domains. Produces a
structured knowledge gap analysis with quantified coverage per sub-domain and
a go/no-go launch threshold. Use when the user mentions entering a new field,
starting a new project, feeling "stuck" on what to ask, or requests a
"knowledge audit", "domain map", or "T/F assessment". Never proceeds to deep
implementation until the user confirms the launch decision.
|
Blind Spot Scanner
Audit knowledge gaps before executing. Prevent "don't know what you don't know"
from bottlenecking AI-assisted work.
When to Activate
- User is exploring a new technical domain or sub-field
- User feels their questions to AI are "low quality" or repetitive
- User asks for a "learning plan", "roadmap", or "where to start"
- User is about to commit to a project but unsure of prerequisite depth
- User says "re-audit", "重新扫描", "再测一次", or mentions revisiting a previous domain
Prerequisites
- User must provide: target domain name + project goal (1 sentence)
- Optional but recommended: current familiarity level (beginner / dabbler / practitioner)
Workflow
Copy this checklist and track your progress:
Scan Progress:
- [ ] Step 1: Deconstruct the domain into 5–8 dimensions
- [ ] Step 2: Present dimensions to user for confirmation
- [ ] Step 3: Generate and administer T/F questions per dimension
- [ ] Step 4: Quantify coverage and identify bottleneck
- [ ] Step 5: Deliver gate decision and launch checklist
Step 1: Deconstruct the Domain
Identify 5–8 core dimensions. Templates provide a baseline of 6 dimensions;
adjust by splitting or merging to stay within the 5–8 range based on project scope.
For each dimension, provide:
- Name
- One-sentence definition (accessible to non-experts)
- 3–5 key concepts or technical terms
- A "safe-to-proceed" criterion: what minimum understanding prevents foot-guns
Load dimension templates from {baseDir}/resources/templates/ if the domain
matches known patterns (trading, publishing, agent systems). Present the matched
template(s) to the user and ask them to confirm or request custom dimensions.
If no match or the user declines, generate from first principles.
Step 2: Present Dimensions for Confirmation
Show the user the dimension list with definitions. Do not proceed to questions
until the user confirms or revises the dimensions.
Step 3: Generate and Administer T/F Questions
For each dimension, generate 4–6 True/False questions covering:
- 1–2 concept definitions (catch definitional errors)
- 1–2 common misconceptions or tacit knowledge (catch hidden foot-guns)
- 1–2 cross-dimensional intersections (prevent siloed understanding)
Present questions one at a time within each dimension. After the user answers
(True, False, or "I don't know"), reveal the correct answer with a concise
explanation before proceeding to the next question. Complete one full dimension
before moving to the next.
Step 4: Quantify Coverage and Identify Bottleneck
After all answers are collected, score each dimension 0–100%:
- 80–100%: Can teach others
- 60–79%: Can execute with reference docs
- 40–59%: Can follow tutorials, likely to get stuck
- 20–39%: Concepts fuzzy, systemic errors likely
- 0–19%: Near blank
Identify the bottleneck dimension: the dimension with the lowest coverage score.
Step 5: Deliver Gate Decision and Launch Checklist
Determine the go/no-go threshold by analyzing the domain's risk profile:
- Domain risk: cost of error (irreversible harm → high; recoverable bugs → low)
- Iteration cost: time/resources to test and pivot (clinical trials → high;
coding prototypes → low)
- Feedback loop speed: how quickly the user learns from mistakes
(trading backtests → minutes; academic publishing → months)
Higher risk × slower feedback → higher threshold. Lower risk × faster feedback → lower threshold.
Reference points (agent adapts based on specific project context):
- High-stakes + slow feedback (medicine, law, production security): 75–90%
- Medium-stakes + medium feedback (data science, web dev, hardware): 50–65%
- Low-stakes + fast feedback (coding prototypes, trading backtests, hobby projects): 25–40%
Deliver:
- The rationale for the chosen threshold
- Which 1–2 dimensions to prioritize for patching (bottleneck + next lowest score)
- Specific resources (docs, repos, papers) to reach threshold
- A "launch checklist" with observable signals
Report Persistence
After delivering the report, save it to:
docs/blind-spot-scan/blind-spot-scan-<domain-slug>-YYYY-MM-DD.md
<domain-slug>: domain name in kebab-case (e.g., quantitative-trading)- Do not show the save path to the user unless they ask
- Re-audit depends on these files being readable from the filesystem
Output Format
Return a markdown report with this exact structure:
# Domain Map: [Domain Name]
Date: [YYYY-MM-DD]
Goal: [User's project goal]
## Dimensions
| Dimension | Coverage | Threshold | Status |
|-----------|----------|-----------|--------|
| ... | ...% | ...% | 🔴🟡🟢 |
Status rules: 🟢 if Coverage ≥ Threshold; 🟡 if Coverage ≥ Threshold × 0.7; 🔴 otherwise.
## Critical Blind Spots (Top 3)
1. **[Dimension]**: [Blind spot] → [Action]
2. ...
3. ...
## Launch Decision
- [ ] GO — Start project. Parallel track: patch [Dimension] to [X]%
- [ ] NO-GO — First patch [Dimension] to [X]%. Estimated time: [Y]
## Re-audit Triggers
- When [signal], revisit [dimension]
### Re-audit Diff (appendix)
If this is a re-audit, add a Diff section before Re-audit Triggers. Use this exact
text-based format (no markdown tables):
```markdown
## Re-audit Diff (vs YYYY-MM-DD)
**[Dimension]:** [last]% → [current]% ([±diff]%) [trend]
...
Coverage legend: <60%=🔴 60–79%=🟡 ≥80%=🟢
**Top improvement:** [Dimension] — [one-line note]
**Regression alert:** [Dimension] — [one-line note]
Trend arrows: +10% or more → 📈 | −10% or more → 📉 | otherwise → ➡️
## Re-audit Workflow
Copy this checklist and track your progress:
Re-audit Progress:
### Step R1: Locate Historical Reports
List files in `docs/blind-spot-scan/`. If the directory does not exist or is empty,
tell the user this is the first scan and run the standard workflow.
### Step R2: User Confirmation
Present the most recent matching report. Ask exactly:
> 是对 `blind-spot-scan-[domain]-YYYY-MM-DD.md` 这份报告进行 re-audit 吗？
If the user says no, list all available reports and ask which one to use.
### Step R3: Read the Confirmed Report
Extract from the confirmed report:
- Domain name
- Dimension names
- Last coverage scores
- Thresholds
- Status (🔴🟡🟢)
### Step R4: Execute the Scan
Reuse the same dimensions from the previous scan. Rotate T/F questions: keep
1–2 questions that test retention, replace the rest with new ones that probe
deeper or test recently learned material.
### Step R5: Generate Diff
After Step 5 of the standard workflow, append the Diff section (see Output Format).
### Step R6: Save
Save the new report using today's date. Old reports are never overwritten.
## Error Handling
- If user cannot answer questions in a dimension: Switch to "exploratory mode"
— provide all correct answers immediately and ask the user to self-rate
confidence (high / medium / low) on each instead. Trigger exploratory mode
when either (a) the user fails or skips 3+ consecutive questions in a dimension,
or (b) the user explicitly asks to skip the dimension.
- If domain is too broad: Ask user to narrow to a specific project or
deliverable before proceeding.
- If user disputes a "correct" answer: Flag it as "contested / paradigm-dependent"
and note the dominant vs. alternative view.
- **If `docs/blind-spot-scan/` is empty**: Inform the user this is the first scan.
Run the standard workflow and save the report.
- **If user rejects the matched report**: List all files in `docs/blind-spot-scan/`
and ask which one to use.
- **If no matching domain is found**: Ask the user to confirm the domain name or
start a fresh scan.
## Examples
### Example Invocation
User: "I want to build a momentum strategy on QQQ constituents but I don't
know where to start."
Agent response: "I'll run a blind spot scanner for quantitative momentum trading.
First, the 6 core dimensions..."
### Example Output Snippet
See `{baseDir}/resources/examples/sample-output.md` for a full rendered example.
### End-to-End Demo Walkthrough
See `{baseDir}/demo/quant-factor-research-agent.md` for a complete, annotated walkthrough covering:
- Domain deconstruction across two templates (trading + agent systems)
- 6 dimensions with 30 T/F questions and answer rationales
- Coverage scoring and contested-question handling
- Final launch decision with risk-calibrated threshold
## Evaluation & Iteration
Test this Skill with real scenarios before relying on it for critical decisions.
### Evaluation checklist
- [ ] **Activation test**: Ask "I want to learn X but don't know where to start" —
does the Skill activate and suggest the blind spot scanner?
- [ ] **Dimension quality**: Are the 5–8 dimensions comprehensive and non-overlapping?
- [ ] **Question calibration**: Do T/F questions distinguish beginners from practitioners?
- [ ] **Threshold sanity**: Does the risk-calibrated threshold feel reasonable?
- [ ] **Output usefulness**: Does the final report help the user decide what to learn next?
- [ ] **Re-audit activation**: Does the Skill activate when the user says "re-audit"?
- [ ] **Diff accuracy**: Does the Diff correctly identify improvements and regressions?
- [ ] **File confirmation**: Does the agent always show the file path before proceeding?
### Iteration signals
Observe how the agent uses this Skill in practice:
- **User skips dimensions frequently**: Questions may be too hard or too broad
- **User disputes many answers**: Dimensions may be paradigm-dependent; add "contested" flags
- **Threshold feels arbitrary**: Revisit the risk-profile analysis with the user
- **Launch checklist ignored**: Make checklist items more concrete and observable
- **User rejects the matched report**: File naming or matching logic needs tuning
- **Diff shows no change across multiple dimensions**: Questions may be too similar
to last time; rotate questions more aggressively
## Guardrails
- T/F answers reflect mainstream consensus, not absolute truth. Flag contested
topics explicitly without fabricating consensus percentages.
- Thresholds are advisory. User overrides only after the agent restates the risk
and the user responds with an explicit go-ahead (e.g., "确认继续",
"是的，继续", "I accept the risk and want to proceed").
- Re-audit is user-initiated. Suggest the user re-run a blind spot scanner when:
(a) project scope changes significantly, (b) a milestone is reached and new
unknowns surface, or (c) after 2–4 weeks of active work as a routine check-in.
Each re-audit should be scoped to the project's current state and open questions,
not a full reset.
- Never embed credentials, API keys, or absolute file paths in skill output.
- During the scan phase, do not write executable code, configure production
environments, submit real orders, send submission emails, deploy services to
public networks, or use live API credentials. The scan phase is limited to
concept explanation, resource recommendation, pseudocode, environment prep
checklists, and dependency installation guides.
