Every few weeks the same thread comes back on r/ClaudeCode. Someone installed the Superpowers plugin because everybody recommended it, checked their usage stats, and found it sitting at 1 to 3 percent. No visible change in the code either. Is it worth it, or is it a tokens killer?
The plugin has 280,000 stars, 25,000 forks and is on its sixth major version in under a year, so this is not a prompt pack somebody abandoned after launch. Jesse Vincent, who has been shipping open source developer tools since the 90s, built it by mining 2,249 markdown files of lessons his own agents had learned.
I installed it, read the 14 skill files line by line, and ran it on my own projects. The short answer to the Reddit question: both camps are right, and which one you land in depends on what you feed it.
What I actually looked at
Superpowers is a free plugin on Anthropic's plugin marketplace, one command to install. The core is 14 skills: markdown instruction files the agent loads whenever a situation matches. Brainstorming, plan writing, subagent driven development, test driven development, systematic debugging, verification before completion, and so on.
A hook at session start forces Claude to check, before every task, whether one of these skills applies. The entry skill is blunt about it: if there is even a 1 percent chance a skill is relevant, load it. So this behaves less like a toolbox and more like a development methodology injected into your agent.
I read every file, then watched what each one did on real feature work and on real small fixes.
The gain sits upstream of the code
The brainstorming skill opens on a hard gate: no code, no scaffolding, no implementation skill of any kind until you have approved an explicit intent. Every request gets sorted into one of three paths. A spike is a feasibility question whose output is an answer, not code you keep. Bounded is a small change to a flow that already exists. Architectural is anything that restructures how the project fits together. The agent says its classification out loud so you can override it, and hidden complexity found mid task can upgrade the path, never downgrade it.
On my own project this phase has already killed features I would have built for nothing. That alone paid for the install.
Out of the architectural path come two documents: a spec you validate, then an implementation plan. The plan skill's opening instruction sets the tone. Write it for a skilled developer with zero context on the codebase and, in the file's own words, questionable taste. The work gets cut into tasks of two to five minutes each:
write the failing test
run it, confirm it fails
write the minimal code that passes
run the tests again
commit
Each task lists the exact files to touch, down to line numbers. This sizing is the reliability argument in one line: a short task means an agent that finishes with a context window still mostly empty. It never reaches the moment where the session overflows and the agent starts inventing functions that do not exist.
The cost is the execution loop, and it never switches off
At execution time your main session stops coding and becomes an orchestrator. It dispatches one fresh subagent per task, with exactly the context that task needs and none of your session history. When the subagent is done, the orchestrator runs a two part review: spec compliance first, then code quality. If the review fails, a fix loop starts, capped at five rounds. The first three resume the original implementer, round four dispatches a fresh one on a more capable model, and at round five a breaker trips and the orchestrator rules on every open finding itself.
That is a real code review process running on its own, task after task. It is also where the tokens go. Dispatch briefs, two reviews per task and the completion ledger are paid every single time, and you feel it on the smallest tasks.
The brainstorming file is explicit that the ceremony scales with the task. The human approval step does not. On a two line fix, that means answering framing questions, approving a two sentence design, then waiting for the full cycle. For a typo in a config file, the complete process is simply slower than fixing it yourself.
And here is the answer to the 1 to 3 percent question. If your usage stats show the plugin that low, your requests almost never trigger the skills. You are paying the session start check every time without ever touching the gains.
The setting that decides whether it pays
The execution skill has a model selection section that starts with one rule: use the least powerful model that can handle each role. A well specified mechanical task touching a file or two goes to a small model. Coordination across several files and debugging go to a standard model. Architecture and the final branch review go to the most capable one.
Two subtleties in that file I had not seen anywhere else.
First, always name the model explicitly when you dispatch. A subagent without one inherits your session's model, often the most expensive one, which silently defeats the whole section.
Second, turn count beats token price. The cheapest models take more turns on multi step work and end up costing more overall, so reviewers and implementers working from prose get a floor one tier up.
This is what makes running Opus or Fable on the 20 dollar Pro plan workable with the plugin: the expensive model only touches the few decisions that deserve it.
The win nobody installs it for
Specs and plans are not chat messages that vanish. They are markdown files saved in a dated plans folder inside the repo and committed with the work. The spec travels with the plan, and conflicts resolve against the spec, so the document is the authority rather than the agent's memory.
Six months later you mention the plan file in a prompt and the agent picks the feature's context right back up. Your git history stops telling you only what changed and starts telling you why. Documentation falls out of the process without anyone sitting down to write it.
What this does not prove
I read the files and used the plugin on my own projects. I did not run a controlled benchmark with token counts per task, so "it burns quota on small fixes" is an observation, not a measurement. The repo also moves fast: sixth major version in under a year, 125 open issues, so the skills you read today will have changed by the next update.
The plugin plans its own exit, though. Its instructions put your directives above the skills, so telling the agent to skip the process works.
The rule I ended up with
Superpowers on by default for any feature work. An explicit skip for tiny fixes.
If you build features that take hours with Claude Code, install it. If your usage is throwaway scripts and small fixes, walk on by. In between, install it and learn to say skip, or let just the brainstorming skill run for a few days. It carries most of the gain and the other skills graft on after it.
The full read
The video shows the actual skill files on screen, section by section, which is hard to convey in prose.
Which camp are you in? A) On all the time B) On for features, off for fixes C) Deleted it, saved my quota D) Never installed it
The reading, the runs and the opinions are mine. I used an editing tool to polish the English.
Top comments (0)