Superpowers, tested: does a forced methodology help or just add steps?

Single comparison, one model, one run per task. I ran the same 20-line feature request twice, once the way I normally work and once with Superpowers installed and its SKILL.md open in front of me, then counted what each run cost. Treat every figure below as a direction, not a distribution.

What it does

obra/superpowers (301,784 stars, MIT, created 2025-10-09, last push 2026-10-10; figures read 2026-10-19) is not a single skill. The installer drops 15 at once, and four of them decide what the agent actually does:

• using-superpowers is the entry point, written as an order rather than advice: “If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill.” It asks the model to read a skill before answering a question or opening a file.
• brainstorming turns the request into an interview. The first message is one line offering to skip the questions plus one open question; after that, one question per message, waiting for an answer. The output is a design document under docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md. Its HARD-GATE is explicit: nothing gets built, not even dependencies or scaffolding, until a human approves.
• writing-plans converts that design into checkbox tasks under docs/superpowers/plans/YYYY-MM-DD-<feature>.md, each carrying its own red-green-commit cycle.
• test-driven-development states its rule as an iron law: NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST. Code written before the test should be deleted, not kept as reference.

Installing is one command, and on this machine it took 9.8 seconds: 15 folders in .agents/skills/, copied into .claude/skills/ for Claude Code. No switch is flipped. The files sit on disk until a harness lists them for the model, which matters later.

The test

The request was identical in both runs:

In a small Node CLI that only supports add, add a --csv export and tests. node cli.js add 2 3 --csv prints 2,3,5; without the flag nothing changes; the flag works in any position; npm test passes; no dependencies.

The starting repo was the same both times: a 44-line cli.js with add <a> <b> and --help, a 22-line test file, two passing tests, a clean tree.

How the numbers were taken: wall clock from the first command to the last, including model thinking; one tool call per read, write, or command; line counts from git diff --numstat; docs counted separately so they cannot inflate the code total.

The baseline is not a lucky run. I did it twice, in two separate repos, and both times produced the same +23/-3 diff and three green tests. The second baseline took 26 seconds rather than 18 because two extra reads were forced by the tool policy, which is why the table uses the first one.

Where the nine extra calls went: four reads of SKILL.md files, two documents written, two source files read, one failing test written, one red run, three edits (parsing, output branch, help text), one green run plus a commit.

The shape of the change stayed small in both runs: strip --csv out of argv, then print either the sum or a three-field row. The extra code came from the definition of done rather than the feature: a help line, and a test suite that pins three cases instead of one. That is the part people miss when they compare line counts of process-heavy and process-light runs: the methodology did not write a bigger feature, it wrote a bigger definition of done.

Where it helps

1. I actually watched a test fail. The baseline path was “change the code, add a test, watch everything pass”, so the test arrived after the behaviour and never proved it could catch anything. With the TDD skill, the first npm test failed with 用法: calc add <a> <b> and exit code 1, because --csv had been swallowed as the first number. Five seconds, but it is the difference between a test and a decoration.
2. It separates what the requester said from what the executor decided. The design doc forces a section for calls I made on my own, such as “no header row”. In a team that argument happens before the code instead of in review.
3. The plan’s Review Focus list produced one test I would not have written: add -1.5 2 --csv must print -1.5,2,0.5. That is the only place in this comparison where the skill produced measurably better output. Everything else was cost.

Problems

1. It is slower and heavier, and the gap is not close. 18 seconds became 52. Five tool calls became 14. An 11-line code change arrived with 118 lines of process documentation, a 50-line spec and a 68-line plan. The documentation is not garbage; it is a real design record. But for a feature this small, writing and reading it costs more than the feature. Anyone who says the process pays for itself should show you a small-task number, because this one is the opposite.

2. The install fails before you ever see a skill. My first attempt died inside git clone, and the error reads like GitHub is down:

   fatal: unable to access 'https://github.com/obra/superpowers.git/': Failed to connect to github.com port 443 via 127.0.0.1 after 2057 ms: Could not connect to server

   The cause was local: global git config pointed http.proxy and https.proxy at 127.0.0.1:7890, where nothing was listening. Port 7897 was. Overriding both with GIT_CONFIG_* environment variables made git ls-remote return in 3.3 seconds and the install finish in 9.8. Worth checking before you conclude the network is blocked.

3. Installing does not touch the session you are already in. After the install the skill list available to me gained nothing: the 15 new folders were on disk, but using-superpowers and brainstorming were not among the skills I could invoke in that session. I only followed the workflow because I opened .claude/skills/using-superpowers/SKILL.md by hand. The older copy on this machine, installed in August 2026, was a different case: it did appear in the session’s skill list as superpowers, but listed is not loaded, and loading still depends on the model choosing to read it. That is the honest limit of this comparison too. The model already knew these skills existed, so the baseline is “unloaded”, not “unaware”, and a run by someone who had never heard of Superpowers could behave differently.

4. Brainstorming assumes a human who answers. One question per message, then wait. This test had nobody to wait for, so I answered my own questions and logged it as a deviation. Which means I cannot claim to have measured the skill unattended; I measured what happens when its central loop is skipped. The review step has the same shape: it wants a fresh subagent, delegation was unavailable in this session, so I reviewed my own diff. Both are honest gaps, not passes.

When not to use it

1. Bug fixes measured in single-digit lines. Reading the code settles correctness; the interview, the plan, and the red light all end at the same diff.
2. Throwaway spikes. The skill does have an escape hatch for prototypes, meaning no tests, no plan, no review, but you have to know it exists and say the word. Otherwise the default process holds you at the document stage.
3. Unattended automation. CI patches, scheduled maintenance, batch migrations. No human means the approval gate either stalls the run or gets bypassed, and a bypassed gate leaves you with the documents and without the discipline.

Verdict

Install it for shared work, skip it for small work. Multi-file changes that someone else reviews, or that may change hands mid-flight, are where the design record and the red light earn their keep. For a twenty-line feature written by one person in one sitting, the 118 lines are the product and the feature is the by-product. One model, one run per task: read the 18-versus-52 as a direction, not a rate.