Blind Spots

The failure mode this skill exists to avoid: re-reading the material closely and critiquing what's there. That finds weak arguments, not blind spots. A blind spot is by definition not on the page — you can't find it by reading harder. You find it by building an independent picture of what a complete version would need to cover, then diffing that against what's actually in front of you.

This is gentler than truth-mode. You're not saying anything given is wrong. You're saying: here's a gap, or here's something that got one sentence when it deserved a paragraph.

Process

1. Name the subject in one line — what exactly is being reviewed (a spec for X, a plan to do Y, an analysis arguing Z). A vague target produces a vague scan.
2. Reconstruct the expected surface, independent of the text. Before re-reading what's given, work out what a complete version of this artifact would need to address — from domain checklists (see references/) and first-principles reasoning about who's affected and how it could fail. Do this before diffing against the actual content, otherwise you'll anchor on what's already written and only spot variations of it.
3. Diff. Compare the expected surface against what's actually present, and sort each gap into one of two bins:
   • Missing — not addressed anywhere, not even a sentence.
   • Underrated — addressed, but the space/rigor given to it doesn't match how much it matters if it's wrong (one throwaway clause, a "TODO," a "we'll figure that out," or an assumption stated without support). This bin is the one plain re-reading tends to miss, because the topic looks covered at a glance.
4. Apply perspective shifts. Domain checklists catch category-level gaps; they miss things specific to this artifact's particular shape. For each, briefly ask what this idea/spec/analysis looks like from their vantage point, and note anything that surfaces:
   • Someone trying to break it (attacker, hostile edge case, adversarial user)
   • Someone skeptical and empowered to say no (investor, auditor, on-call engineer paged at 3am, reviewer with veto power)
   • The person with the least power in the situation (the end user with the worst-case setup, the customer who churns quietly, the team downstream who inherits this)
   • The author, six months later, having forgotten today's context
5. Run a premortem. Assume it already failed. What's the most likely reason? Check whether that reason is addressed anywhere in the material — if not, it's very likely the highest-severity finding, precisely because it's the one that ends the thing.
6. Filter before writing anything down. Not everything absent is a real blind spot — some omissions are legitimately fine (out of scope, genuinely low-stakes, or a deliberate and defensible simplification). Keep only gaps that could plausibly bite. Don't manufacture findings to hit some target count; a short, honest list beats a padded one. If a whole lens (e.g. security, or market risk) turns up nothing real, drop it silently rather than forcing an entry.
7. Rank by how much it would hurt if it actually bites, not by how easy the finding is to state. If one item would sink the whole thing while the rest are contained, say so.

Which checklist to load

Pick the reference(s) that match the subject — load only what's relevant, and skip straight to step 2 if the subject is a clean fit for one lens (a spec doesn't need the startup-pitch checklist):

• Technical spec, API design, system/code architecture → references/spec-and-code-checklist.md
• Business idea, product plan, project proposal → references/idea-and-project-checklist.md
• Written analysis, research writeup, decision memo → references/analysis-and-report-checklist.md

If the subject spans more than one (a project plan that includes a technical spec section), pull from both, but don't force-fit a lens that plainly doesn't apply.

Output

## Blind spots in [one-line restatement of the subject]

1. **[Short title]** — Missing | Underrated · Severity: High/Medium/Low
   [One or two sentences: what's absent or underweighted, and the concrete way it bites — "if X happens, nobody catches it until Y" rather than "consider X."]

For Underrated items, name what's currently there (the one sentence, the hand-wave) so the gap between coverage and importance is visible, not just asserted.

Order by severity. If there's one gap that would end the thing on its own, put it first and say so plainly — don't bury the load-bearing gap under three cosmetic ones just because the cosmetic ones are easier to articulate.

Close with a single line naming what you're not flagging, if anything stood out as genuinely well-covered and worth not second-guessing — this is optional and should only appear if it's true, not as a courtesy.

Guardrails

• Ground every finding in the specifics of this artifact. "Consider security" is not a finding; "the spec accepts a redirect_url param with no allowlist, which is an open redirect" is.
• No quota. If a lens or checklist item produces nothing real, it doesn't appear in the output at all — not even as a reassuring "N/A."
• Keep the Missing/Underrated distinction — they call for different fixes (write something new vs. reweight something that exists), and collapsing them loses the useful signal.
• Don't restate what's already well-argued in the material as if it were a gap — check step 3's diff actually found an absence or a mismatch in weight, not just a topic you personally would've emphasized differently.
• Tone is matter-of-fact, not alarmist. You're pointing at gaps, not arguing the whole thing is broken.