SkillHub

Skills cursor plugins pstack

blast-radius

Use it when:
A small-looking change makes you uneasy, or you ask what it could break somewhere else.
It does:
Finds the one fact the change's safety rests on, looks where a symbol search can't, and proves that fact with a script or test it runs.
You get:
What changed, the safety fact proven or marked unproven, confirmed risks with file:line, odds and cost, what was cleared, and the cheapest test to run before merging.
Runs:
Only when you call it.

Skill 6 of 14 in the pstack bundle, after interrogate and before technical-writing.

Borrows a step from pstack's why skill, sends wide changes to its arena skill and writes its report through unslop: install them alongside.

TL;DR

Listing the callers isn't the job, since grep does that in a second; the job is the breakage grep won't show. It reads the source of the library the code calls, with its pinned version and any local patch, works out when things run (microtasks, unmount and teardown, Solid versus React), and follows what a symbol search misses: the JSON an API returns, a database column, a wire format, another language reading the same bytes, a feature flag, code three hops downstream. Each fact gets a level of proof, from "you said so", worth nothing alone, through pointing at the line and walking the failure step by step, to a script that calls the real code and fails loudly, to a repro in the running app. A big or wide change goes to pstack's arena skill, so several models answer and their answers are merged. It pulls the PR and commits with step 2 of pstack's why skill, writes the report through unslop, and strips anything private before it goes public. It completes a set with how, which says what code does, and why, which says why it's shaped that way.

Summarizes the skill at 8ecfb19.

npx skills add https://github.com/cursor/plugins --skill blast-radius

skills.sh pageSource on GitHubAll skills from cursor/plugins

Total Downloads
7,000 on skills.sh, Nov 9, 2026
Repo stars
15,776 cursor/plugins
First seen
Jun 17, 2026 on skills.sh
Weekly Downloads
567
+52% over the 8 weeks to Nov 9
Weekly values
Week toInstalls
Sep 21373
Sep 28436
Oct 5528
Oct 12614
Oct 19548
Oct 26565
Nov 2601
Nov 9567
Category
category:debuggingcategory:software-engineering

Find root causes, review code and test what you built.

Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills.
Type
type:workflow

A multi-step process the agent follows: interview, debug, run a TDD loop, review.
Effect
effect:local

Its own steps create or change files, git state or local tools.
Needs
needs:subagents

Relies on the agent being able to spawn subagents.
Publisher
by:community

Everyone else. Unverified vendor claims default to community.
Topics
code-reviewverificationtesting

SKILL.md

From cursor/plugins at 8ecfb19. Checked daily, last changed Nov 6, 2026.

Frontmatter
name: blast-radius
description: "Find what a change could break somewhere else before it ships, beyond the diff, and prove the one fact it's safe because of by running real code instead of writing it up. Use for 'blast radius of X', 'what could this break', or reviewing a small diff you don't trust."
disable-model-invocation: true

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.

Companion to how and why. how tells you what the code does. why tells you why it's shaped that way. Blast radius tells you what it breaks somewhere else.

Listing the callers is not the job. The agent can grep those in a second. The job is the breakage grep won't show you.

Don't trust your own writeup

A blast-radius writeup that sounds right is worthless. It reads as convincing whether or not it's true. So don't hand back the writeup. Find the one or two facts the whole thing depends on and prove them by running code.

How sure are you

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

  1. You said so. Worthless on its own.
  2. You pointed at the line. A real file:line, or the library's own source.
  3. You showed the bad case can't happen. You walked the failure step by step and it doesn't reach.
  4. You ran it. A script or test that calls the real code and fails loud if you're wrong.
  5. You reproduced it in the running app.

Step 4 is usually one small script that imports the same library the app ships and calls the exact function you're worried about.

Steps

  1. Read the change. The diff, the symbols it adds, changes, and deletes, and what it now does differently, including the part the diff doesn't spell out. Use why step 2 to pull the PR and commits.
  2. Find the one fact it's safe because of. Most changes that look risky are safe because of a single fact, like "this call only drops already-dead cache entries and does nothing else". Find that fact. If it holds, most risky cases are cleared at once. Spend your time here, not on a long list of maybes.
  3. Look where grep stops. Read the source of the library you call, and check its pinned version and any local patch. Work out when things run: microtasks, unmount and teardown, Solid versus React. Follow what a symbol search misses: the JSON an API returns, a DB column, a wire format, another language reading the same bytes, a feature flag, code three hops downstream.
  4. Be honest about each risk. Give it a real chance of happening and a real cost if it does. Keep the risks you confirmed. List the ones you checked and cleared separately. Same rules as why. Cite a real file:line, a search that finds nothing is still an answer, and never make up a caller or an API.
  5. Prove the one fact. Write a script or test that runs the real code, run it, and paste what happened.
  6. For a big or wide change, run it as an arena. Ask more than one model the same question and merge the answers. Different models catch different real bugs.

What to hand back

  • What it does. What changed, including the part that isn't obvious.
  • The one fact it's safe because of. State it, say which step you got it to, and show the proof. If you couldn't prove it, write unproven.
  • Risks. Each names how it breaks, the file:line, how likely and how bad, and how to check. Paste the proof for the ones that matter.
  • Cleared. What you checked and why it's fine.
  • Before you merge. The cheapest test or repro that catches the real bug, including the script you wrote.

Write it through unslop, cite real code, and strip anything private before it goes anywhere public.

Reply: the writeup above, with the one safety fact either proven or marked unproven.