Skip to content

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:

Plugin split after smarter models
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_discipline

To find which subcommands I still reach for, I look at what I actually call:

Audit which Superpower subcommands you still invoke
grep -r "^\s*/" ~/.claude/commands/ | sort | uniq -c | sort -rn

Then I fill a table per install. Here is what mine looks like after the Opus 5.0 update:

Superpower subcommandNative now?Enforces discipline?Action
/brainstormingUltracodenoDROP
Multi-step task planningWorkflownoDROP
/tdd red/green/refactornoyes (run-suite gate)KEEP
Spec-driven scaffoldingpartialpartlyKEEP 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