Blast Radius

The diff tells you what changed; it does not tell you what breaks. This skill maps the dependents of a change and proves what it can — by running code, not by reasoning alone.

When to use

• a signature, data shape, or behavior other code calls changed
• a dependency bump, config default flip, or migration
• the user asks "what could this break?"

Workflow

1. Name the change surface: exported symbols, persisted formats, CLI flags, API contracts, timing assumptions. List them explicitly.
2. Map dependents: grep for each symbol; where available use AST search (ast_grep_search MCP tool) to catch structural uses text search misses; follow re-exports one more hop than feels necessary.
3. Classify each dependent:
   • certain — calls the changed surface directly
   • likely — consumes a type or format the change touches
   • unlikely — shares a module but not the surface
4. Prove what you can: for every certain and likely impact, run the exact check that would catch the break — its test, its typecheck, its build, or a one-off command exercising the path. Report real output. Impacts you cannot execute a check for are listed as unverified, not as safe.
5. Report: the surface, the dependent counts by class, per-impact verification with evidence, and the unverified remainder named honestly.

Rules

• "It should be fine" is not a classification; every claim is certain, likely, unlikely, or unverified, with its reason in the same sentence.
• Reasoning reduces the search space; execution settles the verdict.
• The report never edits code; fixes found this way go through execute.