blast-radius

Analyzes what a code change could break beyond the diff and proves safety facts by running real code.

136|8|Updated May 9, 2026
One-click install
npx skills add https://github.com/Sma1lboy/rove --skill blast-radius-sma1lboy
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: blast-radius
Source: https://github.com/Sma1lboy/rove/tree/main/.agents/skills/pstack/skills/blast-radius
Command: npx skills add https://github.com/Sma1lboy/rove --skill blast-radius-sma1lboy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often miss breakage that lives outside the diff: downstream callers, wire formats, DB columns, feature flags, and library behavior that grep cannot reveal. This Skill finds what a change could break somewhere else before it ships, and instead of trusting a convincing writeup, it proves the one safety fact the change depends on by running real code. ## Core Features & Use Cases - Hidden Breakage Discovery: Traces risks grep misses, including JSON API responses, DB columns, wire formats, cross-language consumers, feature flags, and code three hops downstream. - Evidence-Ranked Safety Facts: Ranks each safety claim on a five-level confidence ladder, from assertion up to reproduction in the running app, and marks anything unproven honestly. - Proof by Execution: Writes and runs a small script or test that calls the real code and fails loudly if the safety assumption is wrong. - Use Case: Before merging a diff that changes a cache-invalidation call, ask for its blast radius to identify the single fact that makes it safe, verify the pinned library version's actual behavior, and get a runnable script that proves it. ## Quick Start Ask the agent to analyze the blast radius of your current diff or a specific change and prove the key safety assumption with a runnable test.

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 symbols it changes, find the one fact that makes it safe, then trace risks grep misses like API payloads, DB columns, wire formats, and feature flags. Prove the safety fact by running a script against the real code.

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

Read the diff and what it now does differently, locate the single safety assumption, check the pinned library source and version, then write a small test that calls the exact function you are worried about and fails loudly if the assumption is wrong.

Why is listing callers not enough for impact analysis?▼

Grep finds direct callers but misses breakage through JSON responses, database columns, wire formats, other languages reading the same bytes, feature flags, and code several hops downstream. The real job is proving the one fact the change's safety depends on.

What counts as proof that a code change is safe?▼

Proof is ranked on five levels, from a bare assertion up to reproducing behavior in the running app. The target is level four: a script or test that imports the same library the app ships, calls the exact function in question, and fails loudly if wrong.

When should I use multiple models to review a change?▼

For big or wide changes, run the analysis as an arena: ask several models the same blast-radius question and merge the answers. Different models catch different real bugs, which widens coverage beyond a single review pass.