Seven stars. Zero gained in the last week. If you're scanning SkillsMP for what's trending, blast-radius isn't it. But here's the thing about trending skills — they're usually the ones that sell well, not the ones that actually change how you think about a problem. This one does something that most review skills in the ecosystem avoid entirely: it refuses to accept your reasoning as proof.
I installed blast-radius from the pstack-for-codex suite by Aqua-123. It's a Codex-native plugin, which already tells you something important — this was built for a specific runtime, and I'll get into what that means for Claude Code users in a moment. But the philosophy inside it is portable, and it's the kind of philosophy that should make any developer stop and think.
What this skill actually does
The premise is disarmingly simple. When you make a change — even a small one — the instinct is to write up what might break. "This touches the cache layer, so I should check if anything else invalidates it." That instinct is the trap. A blast-radius writeup that sounds convincing is worthless because it reads as convincing whether or not it's true. You're essentially writing fiction and calling it analysis.
Blast-radius forces you to find the one fact that makes a change safe, and then prove that fact by running real code. Not by pointing at a line. Not by arguing logically. By executing something that fails loudly if you're wrong. The skill calls this a confidence ladder, and it's five rungs deep: from "you said so" (worthless) all the way to "you reproduced it in the running app" (bulletproof). Any safety claim that doesn't reach step four — a script or test that calls the real code — gets explicitly marked as unproven. Not buried. Not softened. Marked.
The gap it fills
Most code review tools and skills focus on what the diff changes. Grep for callers. Check the test coverage. Scan for obvious pitfalls. That's table stakes. The real danger in most codebases isn't what the diff touches — it's what the diff doesn't touch but depends on. A JSON shape returned by an API three services downstream. A feature flag that defaults to true in staging but false in production. A microtask that fires after the component unmounts. A library version that changed the semantics of a function you've been calling for six months.
Blast-radius explicitly calls out what grep misses: wire formats, DB columns, another language reading the same bytes, timing semantics. The skill tells you that listing callers isn't the job — the agent can do that in a second. The job is the breakage grep won't show you. That's a distinction most review workflows completely skip.
What stands out
Five things I found genuinely compelling about how this skill is structured.
First, the "one fact it's safe because of" heuristic. Most changes that look scary are safe because of a single fact. If you find that fact and prove it, most of the scary cases die at once. The skill makes you spend your time there instead of generating a laundry list of maybes that amount to anxiety without insight.
Second, the honest unproven marker. The skill literally instructs you to say "unproven" out loud if you couldn't get a safety fact to step four. No rounding up. No hedging language that makes it sound settled. This is rare in AI-assisted workflows, where the default mode is to sound confident regardless.
Third, the step about looking where grep stops. Reading the source of the library you call, checking its pinned version, any local patch. Working out when things run — microtasks, unmount and teardown, Solid versus React. This is the kind of deep-dive that most automated review tools completely skip because it requires understanding runtime semantics, not just syntax.
Fourth, the arena integration for bigger changes. If the change is wide enough, the skill tells you to run it as an arena — ask several models the same question and merge the answers. Different models catch different real bugs. This is a practical use of multi-model evaluation that goes beyond the usual "compare two outputs" approach.
Fifth, the companion skill ecosystem. Blast-radius explicitly references $how for tracing how a subsystem works and $why for reconstructing why code reached its current shape. These aren't standalone tools — they're a workflow. You use why to pull the PR and commits, then blast-radius to find what breaks. That kind of intentional sequencing is what separates a skill from a prompt template.
Who should install this
If you're the kind of developer who ships changes to code you didn't write entirely, and you care about what happens in production — install it. If you work on systems where a single bad change can cascade (distributed systems, shared libraries, infrastructure code), this skill's methodology is directly applicable. If you've ever been burned by a "small refactor" that broke something three layers away, this will resonate.
Who shouldn't: if you're working on throwaway scripts or prototypes where the cost of breakage is low, the overhead of this workflow will feel absurd. And if you're not willing to actually write scripts and run tests — if you want the AI to just tell you it's safe — this skill will frustrate you. It's not designed to give you comfort. It's designed to give you evidence.
The honest limitations
The biggest one: this is a Codex-native skill. The installation is through the Codex plugin marketplace. The skill references ../poteto-mode/references/codex-agent-runtime.md and relies on Codex-specific infrastructure. If you're a Claude Code user, you can't just drop this into ~/.claude/skills/ and expect it to work the same way. The methodology is portable — the confidence ladder, the emphasis on running code over writing up reasoning — but the execution is tied to Codex's runtime.
Seven stars is also a signal worth respecting. It means very few people have actually used this in production. The methodology might be sound, but the prompt engineering, the edge cases, the failure modes — those are largely untested by the broader community. You're adopting something that hasn't been stress-tested at scale.
There's also the question of whether the skill's rigor holds up when the AI is actually executing it. The skill demands that you prove facts by running code. But the AI writing the script might write a script that doesn't actually test what you think it tests. The skill acknowledges this partially by saying to check the pinned library version and local patches, but it doesn't fully guard against the AI constructing a convincing but circular proof.
My verdict
Blast-radius is worth installing if you're in the Codex ecosystem and you care about the quality of your pre-ship analysis. The methodology is genuinely better than what most developers do — which is write a paragraph of "I don't think this will break anything" and move on. The insistence on running code to prove safety facts is the single most valuable idea in the skill, and it's an idea that should be adopted more broadly.
But I'd be dishonest if I said this is a drop-in solution for Claude Code users. The Codex dependency is real, and the skill count of seven means you're essentially adopting this on faith. Try it. See if the workflow changes how you think about your own reviews even when you're not using the skill directly. If the "one fact it's safe because of" heuristic sticks in your head during your next PR review, the skill has done its job regardless of whether you keep it installed.
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