Does the Superpowers Plugin Actually 10x Claude Code?

The rework trap does not announce itself during the first week of AI-assisted coding. The first week feels like a revelation. You describe a feature, the agent builds something, and the result is close enough to what you imagined that you treat it as done and move on. Then somewhere around week three, if you are paying attention, you notice that your sessions are getting longer without your output growing proportionally. The agent is writing more lines than ever, but you are spending more time correcting them. Not because the code is wrong in a syntactic sense. Because it is right for a slightly different interpretation of what you asked.

I started calling this the rework trap. The form you described does not include the validation rule you assumed was obvious. The API endpoint handles the main path but quietly drops the edge case you forgot to mention. The database schema is clean except for one field name that conflicts with a reserved word in your framework, which anyone who reviewed a plan before execution would have caught immediately. None of these are failures of intelligence on the agent's part. They are the natural outcome of jumping to code on a description that was not specific enough at exactly the right level.

The expensive part of AI coding is not the first attempt. It is every subsequent correction that a clearer question at the start would have prevented. That is the sentence that reframes everything I am going to say about a free, open-source plugin called Superpowers.

The five-phase discipline and why slowing down makes the total faster

Superpowers was built by Jesse Vincent and installs a set of skills that make Claude Code behave like an engineer who does discovery before writing anything. The workflow it enforces has five stages: clarify, design, plan, code, and verify. Those words are not novel. Every experienced developer knows they represent good process. What the plugin does is make the model execute them in that order and refuse to skip ahead to code before the earlier stages are done.

A master skill fires at the start of every session and acts as a dispatcher. It surveys the other fourteen available skills and routes the task to the ones it actually needs. Simple jobs do not drag the full ceremony along. The dispatcher is intelligent enough to recognize that a one-line change does not need five stages of process, and to engage only the minimal steps before proceeding. Complex builds get the full structure. That routing is essential because a uniform five-stage mandate applied to both trivial and complex tasks would produce the opposite of the intended effect on simple work.

The design skill is where the real value becomes concrete. Before any code runs, the agent opens a small dashboard locally and presents three distinct approaches to the task with trade-offs laid out side by side. That presentation costs about two minutes. It eliminates the failure mode that dominates AI-assisted development at scale: not bad code, but correct code for the wrong interpretation of the requirement. After you pick a direction, the agent asks clarifying questions before building anything. In testing it typically asks around five, sharp questions that pull requirements out of your head that you did not know were implicit until you were asked to state them explicitly.

The planning skill translates confirmed requirements into a file-path-level plan where each task is two to five minutes of work, names the exact file that will be touched, and has the code block present and tested before execution begins. The plan is saved so a long session can be paused and resumed without losing the thread. Execution dispatches fresh sub-agents per task, reviews each one, and stops at genuine blockers instead of inventing a path forward that quietly introduces a bug. Quality gates write the failing test before any production code, following test-driven development from the first line of the build.

The total elapsed time including all those phases is longer than jumping straight to code. The total finished time, accounting for corrections, re-directions, and the sessions spent chasing down the gaps that formed when discovery was skipped, is often considerably shorter. That trade is not obvious until you have lived through enough correction cycles to understand what they actually cost in time and momentum.

What twelve runs across three task types actually showed

To test the claim that Superpowers meaningfully improves results, Madhuranjan Kumar ran a controlled experiment: twelve Claude Code sessions on Opus 4.6, six with the plugin active and six without, split evenly across simple, medium, and complex tasks. Each run was capped at two dollars in spending and removed human interaction entirely so the results would reflect the plugin's autonomous behavior rather than a curated demonstration.

Overall the results showed roughly nine percent cost savings and fourteen percent fewer tokens when Superpowers was active. On medium and complex tasks the savings were more pronounced and the code structure was noticeably cleaner on review. On trivial tasks the plugin used more tokens than a direct answer would have, because the discovery overhead is real and adds no value when the task fits in a single, unambiguous sentence that the agent can handle correctly without asking a single clarifying question.

The variance finding matters as much as the averages. Sessions without Superpowers showed two to three times more variation in token usage from run to run on the same task type. That unpredictability is its own problem. When you cannot estimate what a session will cost, budgeting for AI assistance becomes guesswork, and the instinct that follows is to use the tools more cautiously than makes practical sense. The plugin narrowed the spread significantly. Even where the average savings were modest, cost became more predictable, and predictability has real financial value independent of the percentage saved on any single run.

Two honest limitations the data revealed: the zero-human-interaction setup understates the plugin's real value because the clarifying questions that are its strongest feature were bypassed by the design of the test. In a live session where the agent asks real questions and a human provides accurate answers in real time, the quality gap would be larger. The second limitation is that raw domain knowledge and strict specification compliance did not measurably change with or without the plugin. The model's knowledge is the model's knowledge. The plugin improves process, not intelligence.

The law firm scenario: when a compliance-critical build needs the full discipline

The clearest illustration of where Superpowers earns its place is a build where a silent omission carries real cost. Consider a small law firm building an internal intake tool: a form that captures new client details, checks for conflicts against existing matters, and generates an engagement letter with the correct fee structure based on matter type.

Without structured phases, an agent producing this tool might build a polished, functional-looking form that skips the conflict check. Nothing crashes. The interface looks finished. The gap sits invisible until the first real intake runs into a conflict the tool failed to flag, creating professional liability exposure that did not have to exist. That outcome is not invented. It is the predictable result of an agent that starts coding on a description that left the conflict-check requirement unstated because the person writing the prompt assumed it was obvious enough not to mention.

With Superpowers, the clarifying questions surface that requirement before a line of code is written. The design phase presents the options for how the check could work: against a flat file of matter numbers, against a live database query, or against a client-name comparison with a manual-review flag for near-matches. The firm picks the approach that fits their existing systems and their risk tolerance. The planning skill writes each task at file-path level, tests each code block in the plan, and saves the whole plan as a reviewable document that anyone in the firm can examine before execution begins.

The quality gate writes the failing test for the conflict check first, then the minimum production code to pass it. The result is a tool that is genuinely finished, with the compliance-critical step verified by a test that documents the requirement, not just by a visual inspection of a screen that looks correct. The difference between those two forms of verification matters enormously in a professional-services context where a failure has consequences beyond the technical.

The plan file and the test suite produce something the direct-to-code approach almost never delivers: an auditable record of what was built and why each decision was made. Three months later, when a paralegal needs to understand why the intake form works the way it does, or when the firm wants to modify the fee logic for a new matter type, the record exists and does not require reverse-engineering finished code. That level of documentation is standard for experienced developers building compliance-sensitive tools. For an AI agent, it exists only if a structure enforces it.

The honest ceiling: what the plugin does not fix

The name Superpowers suggests something larger than the data supports. Nine percent and fourteen percent are real numbers, but they are also the conservative floor of the return and insufficient on their own to justify calling this a ten-times improvement. The accurate framing is narrower: on the tasks that genuinely benefit from structured phases, the improvement in finished output quality and cost predictability is meaningful. On simple tasks, the plugin actively costs more.

The plugin does not improve the model's underlying knowledge. If a task requires deep domain expertise the model does not have, the five phases do not invent that expertise. The model still reasons from what it knows. The plugin improves the process by which that reasoning is directed. Confusing process improvement with intelligence improvement leads to expectations the tool cannot meet.

It does not eliminate the need for judgment. The design phase presents options and a human must choose. The clarifying questions surface requirements and a human must answer them accurately. The plugin creates the structured moments where judgment needs to be exercised. It does not replace that judgment with automation, and relying on it to do so will produce the same kind of gap the direct-to-code approach produces, just at a different stage of the process.

It does not help on simple work. On a one-line ask, the overhead of discovery costs more time than a correction would cost if something were slightly off. The skill dispatcher handles some of this routing, but the right instinct is to actively avoid the full pipeline on anything that fits in one precise sentence with no ambiguity.

How to decide when to engage the full pipeline and when to skip it

Two signals are worth tracking: task length and stakes. If a task would take an experienced developer less than thirty minutes with a clear spec, ask the agent directly. The discovery overhead is real and for a task that small the added time exceeds what a single correction would cost if something were slightly off.

If the task would take more than thirty minutes, or if there is any genuine ambiguity about what done looks like, engage the full pipeline. The clarifying questions will surface something you did not think to state. The design brainstorm will prevent a direction mistake that would have taken two corrective sessions to undo. The plan file gives you a reviewable record instead of a wall of code that appeared from somewhere you cannot trace back.

Stakes adjust the calculation. Even a short build deserves the full discipline when the cost of a silent error is high. A conflict check in a legal tool, a calculation feeding a financial decision, a validation rule that determines access: these warrant the five phases even when the build itself is not long. The phases cost real time, but that cost is small compared to discovering a gap after the tool is already being used by people whose work depends on it.

There is also a compound benefit that goes beyond individual sessions. When a team is using Superpowers consistently across a series of builds, the plan files accumulate into a record of architectural decisions. That record has value when the same codebase is extended, when someone new needs to understand it, or when the original developer returns to a project after months away. Structured development, even when assisted by an AI, produces artifacts beyond the code itself. Unstructured development usually does not, and the absence of those artifacts is invisible at build time and expensive at maintenance time.

Superpowers installs once at the user level, which means every Claude Code project inherits the fourteen skills without you managing it per project. The setup is about five seconds. What it adds is an agent that asks better questions before it writes anything, plans at the level of detail most developers skip under time pressure, and verifies its own output before calling the job done. The nine percent and fourteen percent in the controlled experiment are the conservative floor. The true return on the builds that genuinely need the discipline is a finished tool that works correctly from the first use, instead of one that needs three more sessions to actually close.