I've read a lot of "here's what this change could break" writeups. Most of them are worthless. They sound convincing whether or not they're true, and they follow a predictable pattern: list some callers, mention a few edge cases, and call it a review. The author is usually just writing down what they already believe, not testing what's actually true.
That's the gap Aqua-123's blast-radius skill is trying to close. And honestly, I'm intrigued by the approach even though the skill is still very early — it has 7 stars on SkillsMP and gained zero in the last week, which tells you most people haven't even tried it yet.
What the skill actually does
blast-radius is a Codex plugin skill that forces a specific discipline when reviewing code changes. You give it a diff or a change description, and instead of handing you a writeup that sounds right, it pushes you to find the one fact that makes the change safe — and then prove that fact by running code.
The skill is part of the larger pstack-for-codex suite, a 48-skill, 23-playbook collection that's a Codex-native fork of the pstack project originally built for Cursor. blast-radius sits alongside companion skills like how (what does this code do) and why (why is it shaped this way). The ecosystem is coherent: each skill handles a different phase of understanding a codebase. blast-radius is the one that asks the hardest question — what does this break somewhere else?
Why this matters
Here's the uncomfortable truth: listing callers is not analysis. You can grep for callers in a second. The dangerous breakage is the thing grep won't show you — the JSON field an API returns that your code now assumes is non-null, the DB column that got dropped in a migration three hops downstream, the feature flag that's false in staging but true in production, the microtask timing that means a cleanup runs before your handler finishes.
blast-radius explicitly calls out this gap. Its instructions say "listing the callers is not the job. The agent can grep those in a second." The job is finding the breakage that grep won't show you.
The skill also has a strong opinion about confidence levels. For every safety claim, you're supposed to rate it on a five-step ladder: from "you said so" (worthless) all the way to "you reproduced it in the running app." Any claim that doesn't reach step 4 (running a script or test that fails loud if you're wrong) gets explicitly flagged as unproven. No rounding up. No hand-waving.
What I found compelling
Three things stand out from reading the SKILL.md:
First, the "one fact" heuristic. Instead of generating a long list of potential breakage scenarios (which is what most AI reviews default to), blast-radius forces you to find the single fact the change's safety depends on. "This call only drops already-dead cache entries and does nothing else" — if that holds, most of the scary cases die at once. It's a focus mechanism that prevents analysis paralysis.
Second, the honesty requirement. The skill explicitly says: "Any safety fact you can't get to step 4, say so out loud. Don't write it up as settled." This is rare in AI-assisted reviews, where the default behavior is to sound confident regardless of evidence quality.
Third, the arena integration. For big or wide changes, the skill suggests running it as an arena — asking several models the same question and merging answers. Different models catch different real bugs. It's a practical application of the "don't trust a single model's judgment" principle.
Who should install this
If you're a solo developer reviewing your own PRs and you tend to skip the "what could go wrong" step because it feels like busywork, this skill will force you into a better habit. The structure is clear enough that it does the heavy lifting of reminding you what to check.
If you're working in a codebase where the expensive mistakes are the ones nobody thought to test — integration points, wire formats, cross-language boundaries — blast-radius's emphasis on running real code instead of writing it up is exactly the right instinct.
If you're already using the pstack-for-codex suite, this fits naturally alongside how, why, and unslop. It's designed as part of a workflow, not a standalone tool.
Who should skip it
If you're not using Codex CLI, this is a non-starter. It's a Codex plugin, installed via codex plugin marketplace add Aqua-123/pstack-for-codex. There's no Claude Code version. If you're a Claude Code user, you'd need to wait for a separate adaptation or manually port the prompt logic.
If you want a quick scan of what changed and a list of affected files, this skill will frustrate you. It deliberately avoids that — it wants to go deeper than the diff and will push back if you try to shortcut the process.
If you're working on a codebase where you can't easily run the relevant code (embedded systems, proprietary dependencies, hardware-specific logic), the skill's step 4 requirement becomes a wall. It acknowledges this — you mark facts as unproven — but the workflow is built around the assumption that you can execute the code in question.
Concerns and limitations
Let me be direct about what's concerning. The skill has 7 stars and zero growth in a week. That's not necessarily a death sentence, but it means almost no one has used it in anger yet. The instructions are detailed and opinionated, which is great when they're right and painful when they clash with your actual workflow.
The dependency on the broader pstack-for-codex ecosystem is a real friction point. The skill references ../poteto-mode/references/codex-agent-runtime.md and works best alongside how, why, and unslop. Installing blast-radius in isolation means you're missing context about what the other skills do and how they chain together.
There's also the question of whether the "run real code" mandate is always practical. Writing a script that imports the same library and calls the exact function you're worried about sounds simple in a SKILL.md. In practice, it might require spinning up a test environment, mocking external services, or dealing with side effects that make reproduction expensive. The skill's honesty about marking things unproven helps, but it doesn't eliminate the friction.
The verdict
blast-radius is a skill with a genuinely good idea behind it. The philosophy — prove it by running code, don't trust your own writeup, find the one fact that matters — is sound and differentiates it from the flood of "review this diff" skills that just generate longer versions of the same shallow analysis.
But it's early, it's Codex-only, and it works best as part of the larger pstack suite. I'd install it if I'm already in the Codex ecosystem and I tend to skip blast radius analysis in my reviews. I wouldn't install it as a standalone for a quick PR check. The bar for "worth my time" is higher when the skill demands you run code to prove every safety claim.
If you're curious, the SKILL.md is worth reading on its own even if you don't install it. The five-step confidence ladder alone is something I've started applying to my own manual reviews — and it's made me more honest about what I actually know versus what I'm assuming.