blast-radius

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

4|1|Updated Dec 16, 2023
One-click install
npx skills add https://github.com/Shtian/AuthentiClash --skill blast-radius-shtian
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: blast-radius
Source: https://github.com/Shtian/AuthentiClash/tree/main/.claude/skills/blast-radius
Command: npx skills add https://github.com/Shtian/AuthentiClash --skill blast-radius-shtian

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often miss breakage that grep and diff inspection cannot reveal, such as library behavior, timing, wire formats, and downstream consumers. This Skill finds the hidden impact of a change before it ships and replaces confident-sounding writeups with proof obtained by executing real code. ## Core Features & Use Cases - Hidden Impact Analysis: Traces risks that symbol search misses, including library internals, pinned versions, microtask timing, DB columns, API payloads, and code several hops downstream. - Evidence-Ranked Safety Facts: Identifies the single fact a change's safety depends on and escalates it through a five-level confidence ladder, from assertion to reproduction in the running app. - Executable Proof: Writes and runs a small script or test that calls the real shipped code and fails loudly if the safety claim is wrong. - Use Case: Before merging a diff that touches a shared cache-invalidation call, ask for its blast radius to get the one safety fact proven by a runnable script, a list of confirmed risks with file:line citations, and the cheapest pre-merge test. ## Quick Start Ask the AI 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 the blast radius of a code change?▼

Read the diff to see what now behaves differently, then trace what symbol search misses: library internals, timing, API payloads, DB columns, and downstream consumers. Identify the one fact the change's safety depends on and prove it by running real code.

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

Go beyond listing callers, which grep handles instantly. Check the called library's source and pinned version, work out execution timing, then write a small script that calls the exact function you are worried about and fails loudly if your assumption is wrong.

What risks does grep miss when reviewing code changes?▼

Grep misses behavior rather than references: JSON an API returns, a DB column, a wire format, another language reading the same bytes, feature flags, microtask and teardown timing, and code three hops downstream of the change.

Why is a written impact analysis not enough for code review?▼

A writeup reads as convincing whether or not it is true, so it carries no evidence on its own. The analysis ranks confidence from bare assertion up to running the real code, and any safety fact not proven by execution is explicitly marked unproven.

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

Use it for big or wide changes where a single review pass is likely to miss real bugs. Ask several models the same blast-radius question and merge the answers, since different models catch different real issues.