Superpowers Plugin for Claude Code: What I Actually Use

The superpowers plugin for Claude Code is a library of skills that change how Claude approaches a piece of work: think it through before building, write a plan before touching code, debug in a set order instead of guessing. It does not give Claude abilities it lacked. It gives Claude a procedure. At the time of writing it carries 14 skills, it is open source under the MIT license, and it installs from Anthropic's official plugin marketplace with one command.

I installed it for the building skills, test-driven-development and subagent-driven-development. Four months of my own logs say I reach for it for something else.

Key Takeaways

• The superpowers plugin gives Claude Code a set of working procedures, not new abilities.
• It ships in Anthropic's official plugin marketplace, and it was written by an outside developer and released under an open source license.
• Fourteen skills come with it. Five of them do almost all of the work.
• Across four months, the skills that run before Claude edits anything loaded about three times as often as the ones that write code.
• Installing it is one command, and it starts working on your next session.

Short on time? Jump to the five skills worth knowing, which is the part to act on today.

What the Superpowers Plugin for Claude Code Does

A skill is a set of written instructions paired with a one line description of when to use it. Claude sees the descriptions all the time and pulls in the full instructions when it judges that one matches what you asked for. Say "let's build a booking form" and Claude will usually pull in the brainstorming skill before writing anything, so it asks about the shape of the thing first. Say "this test is failing" and the debugging procedure tends to come in instead, so it forms a theory and checks it rather than trying edits until one sticks.

That is the whole idea. The model is the same model. What changes is the order it works in.

The 14 skills group into four kinds of work:

The rest cover writing your own skills, taking review feedback, checking work before calling it done, and one that reminds Claude to look for a skill in the first place. The full list lives in the plugin's repository, which is also the place to read what each one actually instructs Claude to do.

If you have not added a plugin to Claude Code before, the Claude Code plugins post covers how the marketplace works and what else is worth having installed.

The Five Skills I Actually Use

Here is four months of my own Claude Code logs, across every project I ran in that window. I counted the skill load lines in the session transcripts and turned the counts into shares, so each bar is that skill's portion of the times any superpowers skill loaded. Skills that never loaded at all do not appear.

Three skills take more than seven out of every ten loads, and all three of them run before Claude edits anything. brainstorming alone is more than a quarter. The two building skills I installed the plugin for, test-driven-development and subagent-driven-development, come to less than a quarter between them.

Put those two groups side by side and the skills that run before an edit loaded about three times as often as the ones that write code. That ratio held across the whole window, not just the first weeks while I was still learning what was in the box.

Those five are the ones worth knowing by name:

Why Thinking First Earns Its Keep

In working with a coding agent, the costly decisions all land before the typing starts.

A model that starts writing immediately will write something. It will run, and it will solve the problem it decided you had. The cost of that lands twenty minutes later, when you read it properly and find it built the wrong thing well. Nothing downstream catches this. Tests pass, because the tests were written against the same misunderstanding.

brainstorming opens with a hard instruction not to write anything until you have approved a design. It asks one question at a time, about what the thing is for and what happens at the edges. Its own wording applies that gate to every project regardless of how simple it looks. That is a slower first five minutes and a much shorter afternoon.

systematic-debugging works the same way on a different problem. Left alone, a model presented with a failing test will try a fix, then another, then another, and each attempt looks like progress. The skill asks it to state a theory first and check the theory before editing anything. Sometimes the theory is wrong and you have lost a minute. When it is right you have skipped the whole guessing phase.

Getting a usable plan out of a model before it acts is most of the skill in handing work to one, which is where a good part of the AI workshop goes.

What a Skill Actually Looks Like

The word skill makes this sound like machinery. It is a text file, and the fastest way to stop guessing what the plugin does is to open one. Here is the gate that sits near the top of brainstorming, quoted as it ships:

Do NOT invoke any implementation skill, write any code, scaffold any
project, or take any implementation action until you have presented a
design and the user has approved it. This applies to EVERY project
regardless of perceived simplicity.

Below it, the file takes on the obvious objection. Its heading is "Anti-Pattern: This Is Too Simple To Need A Design", and its answer is that a todo list, a single function utility and a config change all go through the process, because simple jobs are where unexamined assumptions cost the most. It concedes that the design can be a few sentences. It does not concede that you can skip it.

Then it gives Claude a numbered checklist to work through in order: explore the project context, offer a visual companion the first time a question would be clearer shown than described, ask clarifying questions one at a time, propose two or three approaches with trade offs and a recommendation, present the design in sections and get approval on each, write the design to a file and commit it, review that file for gaps, hand it to you to read, and only then move to planning the implementation.

That checklist is the entire product. There is no model change and no hidden service behind it. Someone wrote down how a careful engineer approaches new work, and the plugin hands that text to Claude at the moment it applies.

Two useful consequences follow. You can read any of these files before trusting it, which is a reasonable thing to do before letting a procedure shape your week. And you can disagree with one: the files are plain text on your disk, so a step that does not suit how you work can be edited, or copied into a skill of your own.

What I Expected, and What Happened

The tempting way to judge a plugin like this is by its most advanced feature. Superpowers has a good one, and it gets its own section below. That is the headline feature, and it is one of the two building skills I installed it for.

It is not the part that changed my week.

Across four months subagent-driven-development accounted for about one load in seven, against more than seven in ten for the skills that run before any edit. The advanced feature turned out to depend on the plain ones, because handing tasks to separate agents is only worth doing once you know what the tasks are, and working that out is the plan.

So the change was narrower than I expected. Building got more orderly. Deciding what to build, and working out what had already broken, both got genuinely better, and that is where the value showed up.

There is a real limit worth naming, and it follows from the gate above rather than from a flaw. These skills add steps, and steps cost time and fill up the context window. brainstorming is written to apply to every project however small, so it is written not to stand down on its own for a one line change. That is a deliberate choice by its author and mostly the right one, but it means the overriding is your job: on small work, say "just make the change, no plan" and move on.

The Two Subagent Skills, and Which One You Want

Superpowers carries two skills whose job is handing implementation work to other agents. They behave differently, and the names do not make the difference obvious, so it is worth being precise about which is which.

subagent-driven-development is the sequential one. The name points the wrong way here. Its own file describes dispatching a fresh implementer agent per task, running a review for spec compliance and code quality after each one, and a broader review across the whole branch at the end. It also says plainly never to dispatch implementation agents in parallel, because they conflict. The value is a clean context for each task and a checkpoint between tasks, so a bad task three gets caught before task four is built on top of it. Each fresh implementer also gets its own system prompt, which is the same reason Claude Code output styles you set for your own session do not carry over into the subagent it dispatches.

dispatching-parallel-agents is the concurrent one, and its own description gives the condition: two or more tasks that can be worked on without shared state or sequential dependencies. The example it gives is several unrelated failures in different test files, where working through them one after another costs time for no benefit.

So the deciding question is whether the work writes to the same place. Implementation goes one at a time, because agents editing the same tree at once collide. Separate investigations go wide.

One detail worth taking from that file, because it is easy to miss. Both skills want tasks that are mostly independent of each other. Where a plan is tightly coupled, the sequential skill's own routing sends you away from both, back to doing it by hand or to brainstorming the design again. That is a useful signal in itself: if neither fits, the plan is probably not broken into the right pieces yet.

Worth saying which of the two I lean on. Almost all of my work is the stacking kind, one feature at a time in one repository, so the sequential skill is the one that fires and the parallel one rarely has an honest case. If your week looks like a dozen unrelated bugs across separate subsystems, that balance would flip.

How to Install the Superpowers Plugin

Superpowers ships in Anthropic's official plugin marketplace, which Claude Code already knows about, so there is nothing to add first. Open Claude Code and run:

/plugin install superpowers@claude-plugins-official

Restart the session so the skills load. To check it worked, run /plugin and confirm superpowers is listed. Then ask for something new and watch for Claude to raise questions about the design before it writes anything. That is the brainstorming skill.

From there you mostly do not call anything by name. Describe what you want in plain language and Claude picks the skill that fits. Selection is a judgment call the model makes from those one line descriptions, so it will not fire every single time, and the fix when it does not is to name the skill you want: "use the brainstorming skill first."