I'm going to be upfront: I almost didn't install this skill. Seven stars, zero growth in the last week, and buried inside a 48-skill Codex plugin suite from a creator I hadn't heard of? That's a hard sell when you're browsing SkillsMP during a lunch break. But the description stopped me cold: "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." That's not another diff summarizer. That's a direct challenge to how most of us do code review. So I installed it, ran it against a few real changes in my projects, and here's what I found.
What This Skill Actually Does
The core premise is deceptively simple. When you hand someone a blast-radius analysis, it reads convincing whether or not it's true. That's the trap. This skill refuses to let you walk away with a writeup. It forces you to find the one or two facts that make a change safe, then run code to prove them. Not "here's my reasoning." Proof. A script that calls the real function, a test that fails loud if you're wrong.
It positions itself as a companion to two other skills in the pstack suite — $how (what does the code do) and $why (why is it shaped this way). Blast radius answers the question nobody else asks: what does this break somewhere else? And it explicitly says listing callers isn't the job. You can grep those in a second. The real value is in the breakage that grep won't show you — the JSON an API returns, the DB column it reads, the feature flag that gates it, the microtask timing that changes everything.
Why It Matters
Here's the gap this skill fills. Every developer has written a blast-radius analysis that sounded airtight at 2 AM but was full of assumptions dressed up as facts. "This only touches dead cache entries." "The upstream service handles this gracefully." "It can't happen because of X." Most of the time, we never verify these claims. We write them up, they get accepted, and three months later something breaks in a place nobody thought to check.
What makes this skill different from just thinking harder is the confidence ladder. For each safety fact, you have to get it as far down this list as you can:
- You said so (worthless)
- You pointed at the line (better)
- You walked the failure step by step and it doesn't reach (good)
- You ran it — a script or test that calls real code (solid)
- You reproduced it in the running app (bulletproof)
And if you can't get to step 4, you have to say so out loud. No rounding up. No hand-waving. That discipline alone is worth more than most skill reviews I've seen.
Key Capabilities
The skill's workflow is structured around six steps, and a few stand out:
Finding the one fact it's safe because of. Most scary-looking changes are safe because of a single fact. The skill makes you hunt for that fact instead of drowning in a list of maybes. If that one fact holds, most of the scary cases die at once. This is genuinely smart prioritization.
Looking where grep stops. The skill explicitly tells you to read the source of libraries you call, check pinned versions, look for local patches, and follow what a symbol search misses — JSON responses, wire formats, feature flags, code three hops downstream. This is where real bugs live, and grep won't find them.
The arena mode for big changes. For wide-reaching changes, you run it as an arena — asking several models the same question and merging answers. Different models catch different real bugs. It's a pragmatic use of multi-model reasoning that most skill ecosystems ignore.
The unslop requirement. You write through $unslop before anything goes public. Vague, machine-shaped prose gets stripped. That's a small detail that shows the author understands how these workflows actually get used in production.
Who Should Install This
If you review PRs regularly and you've ever caught yourself saying "this looks fine" without actually verifying the blast radius, install this. If you work on systems where a single bad change can cascade — shared libraries, API surfaces, database schemas, infrastructure configs — this skill will make you a better reviewer. If you're the kind of developer who writes tests because you believe in them, not because CI requires them, the step-4 proof requirement will feel natural.
Who shouldn't bother: if you only review trivial changes (one-line fixes, typo corrections), the overhead of running scripts and proving safety facts is overkill. And if you're working exclusively in environments where you can't run the actual code (closed-source dependencies, proprietary systems with no local dev environment), the skill's core methodology will constantly hit a wall. It also assumes you're using Codex. If you're on Claude Code exclusively, the installation path and skill invocation format may not translate cleanly — the pstack suite is explicitly Codex-native.
Concerns and Limitations
Let me be honest about what I'm not convinced by. First, the ecosystem lock-in is real. This skill lives inside a 48-skill Codex plugin. You're not just installing a tool; you're committing to a workflow system. The companion skills ($how, $why, $arena, $unslop) are designed to work together, and the blast-radius skill references ../poteto-mode/references/codex-agent-runtime.md for delegation and capabilities. If you're not already in the pstack ecosystem, you're adopting it whether you planned to or not.
Second, the star count tells me this hasn't been battle-tested by a large community yet. Seven stars means either it's very new or it hasn't resonated widely. Neither is disqualifying, but it means you're an early adopter. There could be edge cases the author hasn't considered, and the skill's instructions might need iteration based on real-world usage patterns.
Third, the "run real code" requirement is powerful but not always feasible. In my testing, some of the safety facts I wanted to prove required mocking or stubbing that defeated the purpose. If the code you're analyzing depends on services you can't spin up locally, step 4 becomes step 3 at best. The skill acknowledges this — it says to mark things unproven — but in practice, "unproven" on a critical safety fact is a red flag that might not be visible to whoever's reading your review.
Verdict
I'm going to recommend this with a caveat. The methodology is sound, the discipline it enforces is genuinely useful, and the confidence ladder is one of the most practical things I've seen in any skill review framework. If you're a Codex user who takes code review seriously, this skill will make you slower and more careful — which is exactly what you need.
But go in knowing what you're getting: a Codex-first tool from a small creator, with a modest track record, that demands you do the hard work of running code rather than writing explanations. If that sounds like what you need, it's worth the install. If you're looking for a quick diff summarizer or you're not in the Codex ecosystem, look elsewhere.
Links
SkillsMP page: https://skillsmp.com/creators/aqua-123/pstack-for-codex/skills-blast-radius GitHub: https://github.com/Aqua-123/pstack-for-codex/tree/main/skills/blast-radius