Blindspot

blindspot

Overview

| Field | Contract | | --- | --- | | Purpose | Show what the user's question itself missed, before intent work starts. | | Primary input | A goal plus the repo area or domain the user feels unfamiliar with. | | Primary output | Blindspot report and a ready-to-run brainstorm prompt; durable copy at plans/YYMMDD-{slug}/blindspot.md when a work item is likely. | | Boundary | Read-only analysis; no design, no plan, no code, no fix. | | Next handoff | brainstorm with the generated prompt, or plan when intent is already clear. |

Adapted from Thariq's blindspot-analysis pattern on X: the job is not to answer the user's question, but to analyze the question — what the user's framing reveals they haven't considered. A strong model given a blindspotted prompt will confidently propagate the wrong assumption; this skill runs before that can happen.

Position in the pipeline: blindspot runs before brainstorm. It is distinct from scout (returns evidence, not analysis of the user's framing) and from plan-reviewer (red-teams a plan that already exists).

Resources

This skill has no bundled reference files. It dispatches the context-scout agent (blindspot mode) for all repo evidence.

Support Skill Triggers

| Trigger | Load | | --- | --- | | The unfamiliar area involves a version-sensitive framework, library, or API | source-grounding | | The blindspot analysis needs external best-practice grounding | scout --research |

Step 1 - Frame

Capture, in the user's own words:

• the goal — what they want to achieve
• the area — what they feel unfamiliar with
• their current beliefs — how they think it works, even if vague

Do not correct or design yet. The stated beliefs are the raw material: every mismatch between belief and evidence is a blindspot candidate.

Step 2 - Evidence

Dispatch context-scout in blindspot mode with the goal, area, and the user's stated beliefs. The agent reads so the main context stays clean; source code and git history are the source of truth, not the user's description.

Required evidence fields:

• how the area actually works: entry points, key modules, existing patterns
• implicit standards a change here is expected to follow
• landmines: coupling, shared state, migration/compat constraints, prior attempts
• git signals: recent activity, abandoned attempts, ownership patterns

Step 3 - Classify

Compare the user's framing against the evidence and classify findings:

| Category | Meaning | | --- | --- | | Unknown unknowns | Things the user's framing shows they haven't considered at all | | False assumptions | Things the user believes that the evidence contradicts | | Hidden constraints | Implicit standards, coupling, or landmines the area imposes | | Missing questions | 3-6 questions whose answers would change the architecture or approach — not trivia |

Only report findings grounded in evidence or clearly implied by the framing. Do not pad categories; an empty category is a valid result.

Step 4 - Report And Prompt

Output the report, then the brainstorm prompt. The prompt is the primary deliverable: it must be good enough to paste directly into brainstorm without the user re-explaining anything.

## Blindspot Report

Goal: {one line, user's words}
Area: {one line}

### Unknown Unknowns
- {finding — with the evidence that surfaced it}

### False Assumptions
- Believed: {what the user assumed} / Actual: {what evidence shows}

### Hidden Constraints
- {constraint and where it comes from}

### Missing Questions
1. {question that changes the design if answered differently}

## Brainstorm Prompt

> {Goal restated with corrected assumptions.}
> Known constraints from the codebase: {compact list}.
> Open questions to resolve during discovery: {the missing questions}.
> Explicitly out of scope until validated: {expansions the blindspots warn against}.

When the work is likely to become a work item, write the report to plans/YYMMDD-{slug}/blindspot.md so brainstorm and plan colocate with it. Create only the folder and this file — later steps create their own subfolders.

Step 5 - Handoff

Offer:

1. brainstorm using the generated prompt (recommended default)
2. plan directly, only when the report shows intent is already clear and low-risk
3. End session with the report

Red Flags

• Turning the analysis into design or implementation advice
• Asking the user technical questions the repo can answer
• Producing the brainstorm prompt without running the evidence pass
• Reporting generic risks not grounded in this repo or this framing
• Treating the user's description of the area as more trustworthy than the code

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: danielleit241
• Source: danielleit241/forge
• License: ISC

Install and usage instructions live in the source repository linked above.