| name | blind |
| description | Use when the user invokes /blind (full sweep of all frameworks against the current context) or /blind quick (routed 2-4 framework pass), asks "what am I missing", "what are my blind spots", "poke holes in this", "what could go wrong", or before committing to a plan, decision, architecture, launch, or estimate. Dispatcher that runs a structured blind-spot audit using the companion blind-* framework skills. |
Blind — Blind-Spot Audit Dispatcher
Overview
You cannot see your own blind spots by introspecting harder — that is what makes them blind spots (Pronin's introspection illusion). This skill routes to real, research-backed frameworks that surface them from the outside: from data, from others, from inversion, from base rates.
Core principle: enrich the information environment; never trust "it looks right."
How to Run an Audit
Resolve the target first: an explicit argument if given; otherwise the active work in the current conversation (the plan/code/decision most recently under discussion). State the resolved target in one line before auditing.
Default mode — full sweep (bare /blind or /blind <target>)
Run ALL 16 companion blind- framework skills* against the target.
- Fan out in parallel where the agent supports subagents (e.g. the Agent tool): one subagent per framework, each given (a) the full text of that framework's SKILL.md, (b) the target, (c) a ground-truth brief, (d) the instruction to return only evidence-backed findings or an explicit "no finding". This keeps coverage from costing depth. No subagent support → run the frameworks sequentially yourself; do not skip any.
- The ground-truth brief (dispatcher computes it once, before fan-out): the canonical numbers about the target (counts, sizes, dates — measured, not recalled), what was already verified and where that evidence lives (subagents cannot see the conversation; without this they re-litigate or deny verification that happened), and the baseline — what was already true before the audited change. Lenses attack the brief; they don't get to rediscover it wrong.
- Subagents are read-only. Say it explicitly, and also warn them: any files that appear in shared scratch space mid-audit may be artifacts written by a sibling lens, not evidence about the target. Citing a sibling's helper script as "the author's known-bug notes" is cross-agent contamination — a documented failure of this skill.
- Load each skill's actual procedure — via the Skill tool where installed, else read its SKILL.md from this skill set. The dispatcher carries no framework procedures itself; do not improvise a framework from memory. A framework unavailable → name it in the Residual.
- Merge and dedupe: the same blind spot surfaced by several frameworks is ONE finding tagged with all of them. Before treating this as convergence, check whether the frameworks cite the same underlying evidence/quote or genuinely different evidence. Same subagent model + same target text + differently-named lenses can produce correlated pattern-matching, not independent corroboration — only raise severity for the latter; label the former "same-model repetition" and leave severity unchanged.
- Fact-check before ranking. Any finding that contradicts the ground-truth brief or documented run output gets re-verified by the dispatcher against the primary source (the file, the command, the log) before it enters the report. Lenses drift on numbers — three lenses counting the same thing will return three counts; the dispatcher owns the canonical number and corrects findings to it. Debunked findings go in a short "debunked" list (they show the failure mode is live), not in the findings.
- Baseline attribution. Every finding must state whether the defect was caused by the audited change or predates it. Pre-existing problems are reportable — often the most valuable output — but a pre-existing problem attributed to the change is the most common false HIGH this skill produces.
- Report findings ranked by severity = expected damage × plausibility (premortem's rubric, applied audit-wide, qualitative — not a computed number). State the one-clause rationale for each severity call, not just the label.
- End with the residual: what the audit could NOT check (that list is itself a finding). Frameworks that returned "no finding" are listed there in one line. Apply the self-audit caveat to every finding, not just nulls — "evidence-backed" is still self-reported by the same run until someone spot-checks the cited quote against the real target.
- Deliver as a file, not a chat wall of text. Write the report to a markdown file (name it so repeat audits don't collide, e.g.
blind-audit-<target-slug>-<date>.md). In Claude Code, additionally render it via the Artifact tool as HTML for a scannable, severity-ranked view — long full-sweep output read as an undifferentiated wall of text is a known failure mode of this skill.
- This audit informs a human decision — it does not auto-approve, auto-fix, or auto-block anything. Findings are inputs to the reader's judgment.
Quick mode — /blind quick <target>
Time-boxed pass: pick 2–4 frameworks from the routing table below (never all — depth beats coverage; rows list frameworks in priority order; a single-framework row may run alone — the 2–4 rule caps, it doesn't force padding; target matches multiple rows → use the row for the primary object, then pull one framework from the secondary row). Steps 2–7 as above.
Routing Table (quick mode)
| Target | Frameworks (in order) |
|---|
| Plan / project / launch | blind-premortem, blind-outside-view, blind-unknown-unknowns |
| Decision / choice between options | blind-inversion, blind-consider-the-opposite, blind-red-team |
| Architecture / "why does this exist" design choice | blind-chestertons-fence, blind-inversion, blind-outside-view |
| Belief / conclusion / diagnosis | blind-falsification, blind-consider-the-opposite, blind-bias-blind-spot |
| Estimate / forecast / deadline | blind-outside-view, blind-calibration, blind-premortem |
| Data / metrics / evidence | blind-survivorship-bias, blind-falsification |
| Argument / position / debate | blind-steelman, blind-red-team |
| Legacy code / existing process ("why is this here?") | blind-chestertons-fence |
| Self-assessment / skill judgment | blind-dunning-kruger, blind-johari-window, blind-bias-blind-spot |
| Docs / teaching / API design / UX copy | blind-curse-of-knowledge |
| Reasoning chain / "obviously X" | blind-ladder-of-inference |
Ambiguous target in quick mode → default to blind-premortem + blind-inversion + blind-unknown-unknowns, or escalate to the full sweep.
Output Format
Write this to a file (and, in Claude Code, also render it as an HTML artifact — see Rule 6). Do not just print it into the conversation.
## Blind-Spot Audit: [target]
Frameworks applied: [list] — [N] independent findings, [M] same-model-repetition notes
### Findings (severity-ranked)
1. **[finding, one plain-English sentence — no framework jargon in the headline]** (via [framework]; convergent with [framework2] only if evidence differs, else "same-model repetition, not corroboration").
Evidence: [...]
Severity: [low/med/high] — [one clause: expected damage, one clause: plausibility]
Mitigation: [...]
### Residual (what this audit could not see)
- [unchecked assumption / missing data / voice not in the room — specific, not a hedge]
- Self-audit caveat: this audit graded its own evidence; nothing here was spot-checked by an outsider or a second model.
Rules
- Never skip the residual section. An audit that claims completeness is itself a blind spot.
- Findings need evidence or a test, not vibes. "Might be risky" is not a finding; "fails when X because Y" is.
- If all frameworks return nothing, say so — and flag that null results from self-audit are weak evidence (you are still the one looking).
- Findings must be legible without prior knowledge of the framework's name. Lead with plain English; the framework name is a citation, not the headline. A reader who's never heard of the Johari Window should still be able to act on the finding.
- Deliver as a file/artifact, not a chat dump. See Rule 6 above.
Common Mistakes
- Running every framework shallowly instead of 2–4 deeply.
- Auditing the plan you wish you had, not the actual artifact/files/data.
- Treating the audit as done when it confirms the existing plan — confirmation is a smell, not a pass.
- Misattributing pre-existing state to the audited change — measure the baseline first; it's the most common false HIGH (observed: three lenses blamed a merge for 11 GB of repo clones that predated it).
- Trusting lens arithmetic — different lenses return different counts for the same thing; the dispatcher recomputes canonical numbers from the primary source (observed drift: 168/176/182/226 for one count).
- Letting subagents write files: sibling lenses then cite those artifacts as target evidence (observed: two lenses cited a helper script another lens had just written, calling it the author's "known-bug notes").
- Omitting verification evidence from the fan-out brief — lenses that can't see the conversation will report "verification never happened" for verification that happened in-session.
