blast-radius

Blast radius

Find what a change breaks somewhere else, before it ships. Use for "blast radius of X", "what could this break", or reviewing a small diff you don't trust yet.

This skill is self-contained and complements how and why: how explains what the code does, why investigates why it is shaped that way, and blast radius finds what it breaks somewhere else. When either companion's instructions are also loaded in the current context, incorporate its analysis. Installation alone does not load or invoke another skill.

Listing the callers is not the job. Search tools find those quickly. The job is the breakage a symbol search will not show you.

Don't trust your own writeup

A blast-radius writeup that sounds right is worthless if it is untested. Find the one or two facts the whole assessment depends on and prove them by running real code. Words are where you start, not what you ship.

How sure are you

For each fact the change's safety depends on, get it as far down this list as is practical and say where it stopped.

1. You asserted it. Worthless on its own.
2. You pointed at the line. Cite a real file:line or the library's own source.
3. You showed the bad case cannot happen. Walk the failure path step by step and show where it stops.
4. You ran it. Use a script or test that calls the real code and fails clearly if the fact is wrong.
5. You reproduced it in the running application.

Any safety fact that does not reach level 4 is unproven. Say so directly rather than rounding it up to settled.

Steps

1. Read the change: the diff, symbols it adds, changes, and deletes, and the behavior that now differs. Trace the runtime flow when it is unclear. Investigate commits, PR context, and other historical evidence when rationale affects the risk. If how or why is also loaded, incorporate the relevant analysis rather than assuming the skill name alone invokes it.
2. Find the one fact it is safe because of. Most scary-looking changes are safe only if one central fact holds. Spend your time testing that fact instead of producing a long list of maybes.
3. Look where search stops. Read the source of called libraries and check their pinned versions and local patches. Work out lifecycle and scheduling behavior. Follow serialized data, API responses, database columns, wire formats, feature flags, cross-language consumers, and downstream code when relevant.
4. Be honest about each risk. Give it a realistic likelihood and cost. Keep confirmed risks separate from concerns you checked and cleared. Cite real sources, preserve uncertainty, and never invent a caller or API. A search that finds nothing is still a result when its scope is stated.
5. Prove the central fact. Prefer an existing test. Otherwise use an isolated temporary script that imports and calls the code the application ships. Do not modify project files unless the user authorized changes. Run the proof and include what happened. If proof is not cheap or possible, mark the fact unproven.
6. For a big or wide change, ask independent reviewers when the harness supports them and the user permits delegation. Give them the same question, then reconcile their answers against the evidence instead of counting votes.