The SkillsMP marketplace has been quietly filling a niche that most AI coding tool catalogs ignore: deliberate, single-purpose engineering skills that don't try to do everything. Aqua-123's pstack-for-codex suite is the most ambitious effort I've seen in this space — 48 explicit-only skills and 23 playbooks packaged as a Codex plugin. blast-radius is one of the sharper pieces in that collection, and it's the one I keep coming back to when I'm reviewing a diff I don't fully trust.
That said, let me be upfront: this skill has 7 stars on SkillsMP and gained zero in the last week. It's not trending. If you're looking for the next viral hit, look elsewhere. What it is, however, is a genuinely thoughtful approach to a problem most developers gloss over — and that's worth a closer look.
What blast-radius actually does
The core premise is disarmingly simple: when you make a code change, the diff tells you what you changed, but it almost never tells you what that change breaks somewhere else. The agent can grep for callers in a second — that's not the hard part. The hard part is finding the breakage that a symbol search won't reveal. The JSON an API returns. The DB column a query depends on. The wire format another service reads. The feature flag that gates behavior three hops downstream. The microtask timing that means your unmount handler fires after the thing it was supposed to clean up.
blast-radius is designed to find those gaps. But here's the part that really hooked me: it refuses to hand you a writeup. The skill's author makes a point I agree with wholeheartedly — a blast-radius analysis that sounds right is worthless, because it reads as convincing whether or not it's true. So the skill forces you to prove the one fact the change is safe because of, by running real code, not by writing it up.
Why this matters
Most code review workflows — whether human or AI-assisted — produce prose. "This looks safe because it only touches cache entries." "This should be fine because the function is idempotent." Those statements are hypotheses, not evidence. They feel right, and that's exactly the trap the skill warns about.
blast-radius structures confidence as a ladder. For each safety fact, you either: 1. Said so (worthless) 2. Pointed at the line (better) 3. Walked the failure step by step and showed it can't reach (good) 4. Ran a script or test that calls the real code and fails loud if you're wrong (solid) 5. Reproduced it in the running app (definitive)
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. That's a discipline most reviews skip entirely, and it's the single most useful thing about this skill.
Key capabilities I found useful
First, the skill forces you to find the one fact the change is safe because of, rather than generating a long list of maybes. Most changes that look scary are safe because of a single invariant. Finding that invariant collapses most of the risk at once.
Second, it tells you to "look where grep stops." That means reading the source of libraries you call, checking pinned versions, looking at local patches, and following what a symbol search misses — JSON shapes, DB columns, wire formats, feature flags, code in other languages reading the same bytes.
Third, the output format is rigorous. You get: what it does (including the non-obvious part), the one safety fact with its proof step, real risks with file:line citations and honest probability/cost assessments, what you checked and cleared, and the cheapest test or repro that catches the real bug. No filler.
Fourth, for big or wide changes, it suggests running as an arena — asking several models the same question and merging answers. Different models catch different real bugs. That's a pragmatic use of multi-model evaluation that I haven't seen baked into other skills.
Fifth, the companion skill $unslop is referenced explicitly: write it through unslop, cite real code, strip anything private. The output discipline matters.
Who should install this — and who shouldn't
Install this if you're someone who reviews diffs regularly and has been burned by a change that "looked fine" but broke something downstream. If you work in a codebase with complex integrations — APIs, message queues, shared state, multi-service architectures — this skill's approach to finding the invisible breakage is directly relevant. If you value evidence over narrative in your code reviews, this aligns with your instincts.
Don't install this if you're looking for a quick automated reviewer that generates a summary in seconds. This is a methodology, not a linter. It requires the agent to actually run code, and if your workflow doesn't support that, you'll be frustrated. Also, if you're not working with Codex, read the limitations section below before you commit.
How to install
This skill is part of the pstack-for-codex Codex plugin. The official install path is:
codex plugin marketplace add Aqua-123/pstack-for-codex
codex plugin add pstack-for-codex@pstack-for-codex-local
Then start a new task so Codex reloads the plugin catalog. Invoke it with $blast-radius in a prompt.
If you're using Claude Code rather than Codex, there's no official adapter. You can manually copy the skill files into ~/.claude/skills/blast-radius/, but you'll lose the Codex-specific runtime integration — the poteto-mode orchestration, the agent profiles, the arena multi-model invocation. You'd essentially be using the methodology as a prompt template, which still has value, but you're not getting the full experience.
Concerns and limitations
Honest ones, in no particular order:
The skill is Codex-native. The entire pstack-for-codex suite is built around Codex CLI 0.153.4 and its plugin architecture. It is not a Claude Code skill, despite being listed on SkillsMP. The README even notes that Codex CLI 0.153.4 doesn't expose an offline runtime skill-index command, so skill discovery only works at prompt time. That's a real constraint.
Seven stars and zero growth in a week tells me this hasn't found a broad audience yet. That could mean it's ahead of its time, or it could mean there are friction points I'm not seeing. I lean toward the former, but I'd like to see more community feedback.
The skill demands that you run real code to prove safety facts. In practice, this means the agent needs access to the codebase, its dependencies, and a runtime environment. If you're reviewing a change in a locked-down CI environment or a read-only fork, the skill's core methodology breaks down.
The poteto-mode dependency mentioned in the SKILL.md adds complexity. blast-radius can presumably be invoked standalone, but the full integration with the Poteto Mode playbook system requires the broader plugin setup.
Verdict
blast-radius is the kind of skill that makes you rethink your review process. It's not flashy, it's not a viral hit, and it won't generate a polished summary in one shot. But the core insight — that a writeup that sounds right is worthless, and that you should prove safety facts by running code — is the kind of discipline that prevents real incidents.
I'd recommend it to any developer or AI power user who works with Codex and takes code review seriously. If you're on Claude Code, you can still extract value from the methodology by adapting the prompt structure manually, but you're not getting the full experience. At 7 stars, it's a niche tool with a sharp edge — and for the right workflow, that edge is exactly what you need.
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