blast-radius

Analyzes what a code diff breaks outside its changed lines before merging.

1|Updated Sep 10, 2026
One-click install
npx skills add https://github.com/blauwtje/exo --skill blast-radius-blauwtje
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: blast-radius
Source: https://github.com/blauwtje/exo/tree/main/skills/blast-radius
Command: npx skills add https://github.com/blauwtje/exo --skill blast-radius-blauwtje

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? A diff that looks safe and passes CI can still break callers, data consumers, or processes it never touched. This Skill finds the downstream impact of a change and proves the safety claim it rests on by running the real code, instead of trusting comments, READMEs, or green test suites. ## Core Features & Use Cases - Impact tracing beyond grep: Follows callbacks, hooks, dynamically built keys, cross-language readers of the same data, and code several hops downstream that symbol search misses. - Executable proof of safety claims: Writes throwaway scripts that import the actual module or pinned library version and drive the path in question, so every claim is backed by a run, not an assertion. - Leveled safety reporting: Tags every claim with a confidence level from [1 asserted] to [5 live] and hands back a structured result with confirmed risks separated from checked-and-cleared items. - Use Case: Before merging a branch that renames a shared field, use this Skill to find every consumer of that field, run the real code against the pinned dependency version, and receive a report stating exactly which risks are proven and which remain unverified. ## Quick Start Ask the AI to check the blast radius of the current branch diff before merging it.

Frequently Asked Questions about blast-radius

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check what a code change might break before merging?▼

Run a blast radius analysis on the diff: state what behavior changes, name the one fact its safety rests on, trace consumers beyond grep including callbacks and built keys, then run the real code to prove or disprove that fact before the merge proceeds.

Why is grep not enough to find all callers of changed code?▼

Grep misses dynamically built keys, callbacks and hooks, code in other languages, and separate processes reading the same data. A blast radius check names exactly what was searched and follows those indirect paths that symbol search stops at.

Can I trust a change when CI is green and it was approved?▼

No. The test suite covers the diff's own code, while breakage outside the diff runs in no test the change touched. Safety claims need to be proven by running the real code, not inferred from a passing pipeline.

When should I not use blast radius analysis?▼

Skip it for failures already observed, which belong to debugging, for explaining how code works with no decision riding on it, for checking a finished branch against its plan, and for edits whose effect stays inside one function.

What do the safety claim levels [1 asserted] through [5 live] mean?▼

They rank proof strength: [1 asserted] is an unverified claim, [2 file:line] cites code, [3 traced] follows the path, [4 ran] executes the real code, and [5 live] reproduces in the running app. Claims below level 4 are reported as unproven, never as safe.