blast-radius

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

Updated Sep 2, 2026
One-click install
npx skills add https://github.com/jnyross/pstack-muse --skill blast-radius-jnyross
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: blast-radius
Source: https://github.com/jnyross/pstack-muse/tree/main/skills/blast-radius
Command: npx skills add https://github.com/jnyross/pstack-muse --skill blast-radius-jnyross

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often miss breakage that lives outside the diff: downstream callers, wire formats, feature flags, and library behavior that grep cannot reveal. This Skill finds what a change could break somewhere else before it ships, and replaces confident-sounding writeups with proof obtained by running real code. ## Core Features & Use Cases - Hidden Breakage Detection: Looks where grep stops, including library source, pinned versions, JSON payloads, DB columns, wire formats, and code three hops downstream. - Proof-Based Verification: Identifies the single fact the change's safety depends on and proves it with a script or test that calls the real code, with an explicit confidence ladder from assertion to live reproduction. - Honest Risk Reporting: Separates confirmed risks with real file:line citations from checked-and-cleared cases, and marks anything unproven instead of rounding up. - Use Case: Before merging a small diff you do not trust, ask for its blast radius and receive the one safety fact either proven by a runnable script or explicitly marked unproven, plus the cheapest test to catch the real bug. ## Quick Start Ask the assistant to analyze the blast radius of your current diff and prove the key safety assumption by running the 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's safety depends on, trace behavior grep misses like wire formats and downstream callers, 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 its commits, find the single assumption that makes it safe, and verify that assumption by running a test against the actual library code. Report confirmed risks with file:line citations and mark anything unproven explicitly.

Why is listing callers not enough for impact analysis?

Grep only finds direct symbol references. Real breakage hides in JSON payloads, DB columns, wire formats, feature flags, pinned library versions, and code several hops downstream, which require reading source and running code to detect.

What proof is needed to call a code change safe?

Safety claims follow a confidence ladder: assertion, file:line citation, walked failure path, a running script or test, and reproduction in the live app. Anything that cannot reach a runnable proof should be marked unproven, not written up as settled.

When should I use multi-model review for a change?

Use an arena-style review with several models when the change is big or wide. Different models catch different real bugs, and merging their answers gives broader coverage than a single review pass.