blast-radius

Analyze what a code change could break beyond the diff and prove safety by running real code.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often miss breakage that grep and symbol searches cannot show, such as changes to wire formats, DB columns, feature flags, or downstream consumers. This Skill finds the hidden impact of a change before it ships and replaces convincing-sounding writeups with proof from actually running the code. ## Core Features & Use Cases - Hidden Impact Analysis: Traces risks that static search misses, including API responses, data formats, cross-language consumers, and code several hops downstream. - Evidence-Based Verification: Ranks each safety claim on a five-step confidence ladder, from assertion up to reproduction in the running app, and requires a script or test for the key fact. - Structured Risk Report: Returns what changed, the one fact the change is safe because of, confirmed risks with file:line citations, cleared concerns, and the cheapest pre-merge test. - Use Case: Before merging a small diff you do not trust, ask for its blast radius and receive a proven or explicitly unproven safety claim backed by a runnable script. ## Quick Start Ask the assistant to analyze the blast radius of your current diff and prove the one fact it is safe because of by running real code.

Frequently Asked Questions about blast-radius

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

FAQPage Schema
How do I find what a code change could break before merging?▼

Run a blast radius analysis on the diff: identify the one fact the change is safe because of, check impacts grep misses like API payloads and DB columns, then prove the safety fact with a script that calls the real code.

How to review a small diff I don't trust?▼

Read the diff and the symbols it touches, find the single fact its safety depends on, and verify that fact by running a test or script against the actual library code rather than trusting a written summary.

Why is grep not enough for impact analysis?▼

Grep finds direct callers but misses JSON API responses, wire formats, DB columns, feature flags, other languages reading the same bytes, and code several hops downstream. Blast radius analysis targets exactly those hidden couplings.

What proof is needed to call a change safe?▼

Claims are ranked on a five-step ladder from assertion to reproduction in the running app. Step 4, a script or test that runs the real code and fails loudly, is the expected bar; anything unproven must be marked as such.

When should I use an arena for blast radius analysis?▼

Use an arena for big or wide changes: ask several models the same blast-radius question and merge their answers, since different models catch different real bugs.