Is the Claude Code Superpower Plugin Still Worth Using After Opus 5.0?
Purpose
I run the Superpower style community plugins on top of Claude Code. After Opus 5.0 and the native Ultracode plus Workflow features landed, I noticed my /brainstorming usage dropped a lot, because Ultracode and Workflow do “a lot of those things naturally without me explicitly asking.”
That left me with a real question: is the Superpower plugin still worth keeping as the base model gets smarter, or am I now paying tokens, latency, and prompt bloat for work the model does natively?
This post walks through the audit I use to answer that per subcommand, not for the whole plugin.
Environment
- Claude Code on Opus 5.0
- Native features enabled: Ultracode, Workflow
- Third-party: Superpower plugin (slash commands under
~/.claude/commands/) - Source of the question: an r/ClaudeCode discussion thread (score ~18, upvote ratio 0.85, flair “Discussion”)
What happened?
I expected smarter models to make plugins smaller. In practice it split the plugin in two halves:
Superpower subcommands├── Generic reasoning/planning ──► now done natively by Ultracode + Workflow└── Discipline enforcers ──► still stickier (TDD is the loudest one)The thread author said the exact same thing: native Ultracode and Workflow now do “a lot of the things Superpowers can do,” so they stopped calling /brainstorming. But they still keep the plugin for TDD. That matches my own usage — the reasoning-shaped commands faded, the gate-shaped ones stayed.
So the real problem is not “keep or drop the plugin.” It is “which subcommands duplicate native behavior, and which enforce a step the model would otherwise skip?”
How to solve it?
I run a small audit per slash command I actually invoke. Two tests, then a decision.
Decision rule per command: native_now = does Opus 5.0 / Ultracode + Workflow do this without the command? enforces_discipline = does it force a step the model would otherwise skip? keep if NOT native_now OR enforces_discipline drop if native_now AND NOT enforces_disciplineTo find which subcommands I still reach for, I look at what I actually call:
grep -r "^\s*/" ~/.claude/commands/ | sort | uniq -c | sort -rnThen I fill a table per install. Here is what mine looks like after the Opus 5.0 update:
| Superpower subcommand | Native now? | Enforces discipline? | Action |
|---|---|---|---|
/brainstorming | Ultracode | no | DROP |
| Multi-step task planning | Workflow | no | DROP |
/tdd red/green/refactor | no | yes (run-suite gate) | KEEP |
| Spec-driven scaffolding | partial | partly | KEEP or thin |
The two columns that matter are Native now? and Enforces discipline?. Everything that is “native + not a forcing function” gets dropped. Everything that is “native-ish but still gates a step” gets kept, sometimes as a thin shim so I do not get two planners fighting.
The reason
I think the key reason the plugin does not disappear wholesale is that model capability and model discipline are different things. A smarter model can describe TDD, plan a multi-step task, or brainstorm trade-offs. It does not automatically hold the line under pressure. In long sessions I still see it jump to implementation, regress to fix-then-test, or skip the run-suite step because it is confident the test “should pass.”
That gap is exactly what a discipline-enforcing plugin protects. So the audit rule collapses to one sentence:
If the base model now does it natively AND the plugin does not force a step, drop it.Otherwise keep it.The mistake I want to avoid is the inverse: assuming “smarter model = no process needed.” Smarter reasoning is not the same as guaranteed process. The plugin’s value, when it survives, is the forcing function — not the knowledge.
Summary
In this post, I audited the Superpower plugin against Opus 5.0 plus native Ultracode and Workflow. The key point is to evaluate each subcommand with two tests — does the base model do this natively now, and does the plugin force a step the model would otherwise skip — then keep only the ones that pass either test. For me that meant dropping the generic brainstorming/planning commands onto native Workflow, and keeping TDD because it is the stickiest discipline enforcer.
Final Words + More Resources
My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me
Here are also the most important links from this article along with some further resources that will help you in this scope:
Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!
Comments