Superpowers: the plugin that makes Claude Code slow down

An agent that is wrong quickly is more expensive than a colleague who is wrong slowly, because it has already written eleven files by the time you notice. Superpowers is a free, open-source plugin that installs the habits that catch that: think before building, write the plan down, debug from evidence, prove it works before saying it does. Here is what actually changes in your sessions, how to install it, and the three skills you will feel in the first hour.

The problem: fast, and confidently finished

Give a coding agent a task and it will start immediately. That feels great for about four minutes. Then you notice it never asked what you meant by the ambiguous half of the request, it picked an approach you would have rejected, and it told you the work was done without running anything.

None of those are intelligence failures. They are process failures, and they are the same three failures that show up on any team without process: no shared understanding before work starts, no written plan, no definition of done. Humans solved this with brainstorms, design docs, and QA. Agents ship without any of it unless you install it.

That is the gap Superpowers fills. It is not a smarter model or a better prompt. It is an engineering culture, packaged as files the agent reads.

What the plugin actually is

Two pieces of vocabulary, and then the whole thing makes sense.

A skill is a plain Markdown file with a name, a description of when it applies, and a set of instructions. Claude Code scans the descriptions of every skill it can see and loads the body of one when the work in front of it matches. You have probably already used this pattern: the skills library in the Academy classroom is exactly the same format.

A plugin is a bundle of those, distributed through a marketplace so you install it once instead of copying files around. Superpowers is a plugin whose skills are all about how to work rather than what to build. Brainstorming. Writing plans. Executing plans. Systematic debugging. Test-driven development. Verification before completion. Requesting and receiving code review. Dispatching parallel agents. Using git worktrees. Even a skill for writing new skills.

It is a community project, built in public by Jesse Vincent and the Prime Radiant team, and it describes itself as an agentic skills framework and software development methodology. It is not ours, we did not commission it, and we recommend it anyway. The code is open, so you can read every instruction it will give your agent before you install it. That is a reasonable thing to do with anything that changes how an agent behaves on your files.

Installing it

It ships in Anthropic's official Claude Code plugin marketplace, so the install is one line. Open Claude Code in any project and run:

/plugin install superpowers@claude-plugins-official

Restart the session so the skills load. That is the whole setup: no configuration file, no API key, nothing to wire up. If you would rather track the author's own marketplace, add it first and install from there instead:

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

Two things worth knowing before you do it:

• Plugin distribution is young. Install lines change more often than the plugin does, so if one of the above is rejected, run bare /plugin to browse marketplaces from inside Claude Code and check the project's own page.
• Skills apply themselves. Once installed, you do not invoke them by name for the common cases. The agent reads the descriptions and pulls in the relevant one. You can still name a skill explicitly when it should have fired and didn't.

The three skills you feel first

There are more than a dozen in the bundle. Three of them account for most of the difference in the first week.

1. Brainstorming, before anything gets built

Ask for a feature and the agent stops to interrogate the request instead of starting it. What is this actually for, who uses it, what happens in the failure case, which of these two readings of your sentence did you mean. It is mildly annoying for about a minute, and then it saves you an hour, because the version it would have built was the wrong one and you would not have known until you read it.

This is the same move as the honest brainstorm in our planning workflow: the value is in being asked the question you were skipping.

2. Writing plans, before multi-step work

For anything past a one-line change, the agent writes the plan to a file first: the steps, the files it intends to touch, what could break, how each step gets verified. You read it and push back before a single edit happens.

The file matters more than it looks. A plan in the chat scrolls away and dies with the session. A plan in a file can be handed to a fresh session tomorrow, or split across several agents working in parallel, and it survives you closing the laptop.

3. Verification before completion

This is the one to install even if you ignore the rest. The rule it enforces is short: no claim of success without evidence, and the evidence has to be pasted. Tests run, output shown. Page loaded, console checked. Command exited zero, here is the zero.

Left alone, models write "the fix is working" as a prediction of what would probably happen, because that is what the surrounding text usually says next. That sentence has a completely different meaning to you than it does to the model. This skill closes that gap by making the agent go and look.

A fourth is worth naming: systematic debugging. It stops the guess-and-check spiral where the agent changes three things at once, the symptom moves, and neither of you can say why. Read the error, form one hypothesis, test that hypothesis, then fix. It is slower per attempt and much faster to the actual bug.

What changes in a session

Concretely, here is what looks different after you install it:

• You get asked more questions up front. Sometimes several rounds before any work starts.
• Plans land as files in the project, usually under a plans folder, with dated filenames. They become a record of why the work was shaped the way it was.
• "Done" comes with output attached. The command that was run, and what it printed.
• Debugging gets narrated. Here is the hypothesis, here is the test of it, here is what that ruled out.
• Big jobs get split. Independent chunks go to parallel agents with the plan file as the shared contract.

The net effect is fewer sessions that end with you quietly reverting everything.

What it doesn't fix

Four honest limits, because you should know them before you install anything that changes how your agent works.

It does not make the model correct

It makes the model show its work. Those are different things. A confident wrong plan is still a wrong plan, and the only reason the plan step helps is that you read it. Skip the reading and you have added ceremony without adding a check.

It costs turns and tokens

Every question, plan, and verification pass is more of both. On a two-minute copy edit that overhead is pure friction, and you will feel it. Use judgment: the discipline pays for itself on multi-step work and taxes you on trivia.

Skills fire on the model's judgment

Loading happens because a description matched, which means it sometimes doesn't. When you know a task deserves a plan and no plan appears, say so directly: "write a plan first." Naming the skill you want is allowed and it works.

It is someone else's opinion about process

A good one, and still an opinion. If a rule in it fights how you work, read the skill file and change it. They are Markdown. That is the whole point of the format.

Your turn: one small multi-step task

Do not test this on something important, and do not test it on a typo. Pick something in the middle.

1. Install the plugin through /plugin and restart your session.
2. Pick a task with three or four steps in a project you own. Reorganizing a folder, adding a section to a page, cleaning up a spreadsheet export.
3. Describe the outcome, not the steps. Let it ask you questions. Answer them honestly, including the parts you had not decided yet.
4. Read the plan file before approving it. Look specifically for the thing it plans to touch that you did not expect. That line is the one this whole workflow exists to surface.
5. When it says it's done, check that it pasted evidence. If it didn't, ask: "what did you run, and what did it print?"

Compare it to how the same task would have gone last week. The output quality is often similar. What changes is how much of your afternoon you spend finding out that it wasn't.

Back to

All workflows

→