blast-radius

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

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Small-looking code changes often break things far outside the diff, and a convincing-sounding risk writeup can be wrong. This Skill finds the hidden downstream breakage of a change and proves the one fact its safety depends on by executing real code instead of trusting a narrative. ## Core Features & Use Cases - Hidden Breakage Discovery: Traces what grep and symbol search miss, such as API response shapes, DB columns, wire formats, feature flags, and code several hops downstream. - Evidence-Ranked Verification: Ranks each safety claim on a five-level confidence ladder, from assertion up to reproduction in the running app, and pushes key facts toward executable proof. - Executable Proof Scripts: Writes and runs a small script or test that calls the real shipped code and fails loudly if the safety assumption is wrong. - Use Case: Before merging a PR that changes cache invalidation logic, use this Skill to find the single fact the change is safe because of, prove it with a runnable script, and get a report of confirmed risks, cleared risks, and the cheapest pre-merge test. ## Quick Start Ask the AI 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 might break before merging?▼

Read the diff and its commits, find the single fact the change is safe because of, then trace what grep misses: API responses, DB columns, wire formats, feature flags, and downstream callers. Prove the key fact by running a script against the real code.

What is a blast radius analysis in code review?▼

A blast radius analysis identifies everything a change could break outside its own diff before it ships. It goes beyond listing callers to uncover breakage that symbol search cannot show, such as data formats and behavior three hops downstream.

Why is listing callers not enough when reviewing a risky diff?▼

Callers are trivial to grep, but the real breakage hides in things search misses: JSON an API returns, a shared DB column, another language reading the same bytes, or timing behavior like microtasks and teardown. The analysis targets exactly those gaps.

How do I prove a code change is safe instead of just writing it up?▼

Write a small script or test that imports the same library the app ships and calls the exact function you are worried about, then run it and paste the output. A writeup that sounds right is worthless without executable evidence.

When should I run a blast radius check with multiple models?▼

For big or wide changes, run the analysis as an arena where several models answer the same question and their answers are merged. Different models catch different real bugs, which widens coverage beyond a single review pass.