blast-radius

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

2|Updated Jun 27, 2026
One-click install
npx skills add https://github.com/imjasonh/playground --skill blast-radius-imjasonh
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: blast-radius
Source: https://github.com/imjasonh/playground/tree/main/.cursor/skills/blast-radius
Command: npx skills add https://github.com/imjasonh/playground --skill blast-radius-imjasonh

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often miss breakage that grep and symbol searches cannot reveal, such as changes to wire formats, DB columns, library behavior, or downstream consumers. This Skill finds the hidden blast radius of a change and proves the one fact its safety depends on by executing real code instead of trusting a convincing writeup. ## Core Features & Use Cases - Hidden Breakage Detection: Traces risks that symbol search misses, including API JSON shapes, pinned library versions, microtask timing, feature flags, and code three hops downstream. - Proof by Execution: Identifies the single fact the change's safety depends on and verifies it with a runnable script or test that fails loudly if wrong, rating confidence on a five-step scale from assertion to live reproduction. - Honest Risk Reporting: Separates confirmed risks with real file:line citations from cleared cases, and marks anything unproven rather than overstating it. - Use Case: Before merging a diff that touches a shared cache-invalidation call, use this Skill to find the one safety fact, write a small script that calls the real library function, and hand back a report of proven facts, real risks, and the cheapest regression 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 the blast radius of a code change?▼

Read the diff and what it now does differently, then find the one fact the change is safe because of. Check where grep stops: library source, pinned versions, wire formats, DB columns, and downstream consumers, then prove the safety fact by running real code.

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

Identify the single fact the change's safety depends on and write a small script that imports the same library the app ships and calls the exact function you are worried about. If the script cannot prove it cheaply, mark the fact unproven rather than writing it up as settled.

Why isn't listing callers enough for impact analysis?▼

Callers are trivial to grep, but the real breakage hides in things symbol search misses: JSON an API returns, a DB column, another language reading the same bytes, feature flags, and code three hops downstream. The job is the breakage grep won't show you.

What counts as proof that a change is safe?▼

Proof is ranked on a five-step scale: your assertion, a real file:line citation, a step-by-step walkthrough showing the bad case can't happen, a script or test that runs the real code and fails loudly, and reproduction in the running app. Anything below step 4 should be flagged.

When should I use an arena of multiple models for change review?▼

Use an arena for big or wide changes where a single review may miss real bugs. Ask several models the same blast-radius question and merge the answers, since different models catch different real issues.