# Superpowers Fixes Claude Code, But It Has One Real Cost

Video: https://www.youtube.com/watch?v=l7P_TQzyd7Q
Article: https://aidive.dev/videos/superpowers-plugin/
Published: 2026-09-02

## Chapters

- [0:00](https://www.youtube.com/watch?v=l7P_TQzyd7Q&t=0s) The plugin with 280,000 stars
- [1:04](https://www.youtube.com/watch?v=l7P_TQzyd7Q&t=64s) What Superpowers actually is
- [2:31](https://www.youtube.com/watch?v=l7P_TQzyd7Q&t=151s) Brainstorming: the gate before any code
- [4:06](https://www.youtube.com/watch?v=l7P_TQzyd7Q&t=246s) Plans made of tasks too small to hallucinate
- [5:45](https://www.youtube.com/watch?v=l7P_TQzyd7Q&t=345s) One subagent per task, one review every time
- [7:27](https://www.youtube.com/watch?v=l7P_TQzyd7Q&t=447s) The right model for every task
- [8:50](https://www.youtube.com/watch?v=l7P_TQzyd7Q&t=530s) Committed plans: documentation for free
- [9:55](https://www.youtube.com/watch?v=l7P_TQzyd7Q&t=595s) What it really costs you
- [11:22](https://www.youtube.com/watch?v=l7P_TQzyd7Q&t=682s) Our verdict

## TL;DR

- Superpowers is worth installing if you build features that take hours with Claude Code, and a waste of fixed ceremony if your usage is throwaway scripts and two-line fixes.
- It is not a toolbox but a methodology: a brainstorming gate before any code, plans cut into two-to-five-minute tasks, one fresh subagent per task with a review every time, and a model sized to each task.
- The token argument holds: model selection lets the expensive model work only on the decisions that deserve it, which makes Opus or Fable viable on the twenty dollar Pro plan.
- Specs and plans are committed with the code, so documentation falls out of the process on its own.
- The cost never switches off: usage stats at a few percent mean the skills never trigger and you pay the entry check for nothing, so tell the agent to skip the process on tiny fixes.

## The plugin with 280,000 stars

Superpowers is a plugin for Claude Code written by Jesse Vincent, who has been shipping open-source developer tools since the 1990s. He released it in October, and less than a year later the repository sits at 280,000 stars and 25,000 forks, with the last push landing two days before we recorded. The project is already on its sixth major version with 681 commits on the main branch, so this is not a prompt collection somebody abandoned after a launch spike.

| Signal | Value |
|---|---|
| GitHub stars | 280,000 |
| Forks | 25,000 |
| Major version | 6 |
| Commits on main | 681 |
| Open issues | 125 |

Vincent's bet fits in one sentence: what coding agents are missing is not capability, it is discipline. That discipline ships as plain markdown files anyone can read, fork and adapt. We installed the plugin, read all fourteen skills line by line, and looked at what it changes on four fronts: productivity, code reliability, token spend and documentation.

## What Superpowers actually is

Superpowers is a free, open-source plugin for Claude Code. It lives on Anthropic's official plugin marketplace and installs with a single command. The same methodology exists for more than a dozen other harnesses, including Cursor, Codex and Gemini, each with its own install path.

The core is fourteen skills: markdown instruction files the agent loads whenever a situation matches them. Brainstorming, plan writing, subagent-driven development, test-driven development and systematic debugging each encode a complete way of working, with their own checklists and guardrails. The debugging skill forbids proposing a fix before the root cause is isolated. A verification skill makes the agent prove a job is finished instead of claiming it. Each skill announces itself when it loads, so you always know which mode the agent is working in.

A hook at session start forces Claude to check, before every task, whether one of these skills applies. The rule is written into the entry skill: if there is even a one percent chance a skill is relevant, the agent has to load it. The result behaves less like a toolbox and more like a development methodology injected into the agent.

Vincent describes the origin on his blog. He built the skills by mining 2,249 markdown files of lessons his own agents had learned, then pressure-tested the drafts against those same archives. The methodology was extracted from real agent failures rather than written from theory.

## Brainstorming: the gate before any code

Brainstorming is the skill everything passes through. The moment you ask for a feature, Claude loads it and acts as a requirements expert for the length of the framing conversation. The whole method fits in one readable file.

The file opens on a hard gate: no code, no scaffolding, no implementation skill of any kind until you have approved an explicit intent. Nothing gets built on a hunch, and the gate applies to every task however small it looks. The skill then sorts every request into one of three paths.

| Path | Definition | Output |
|---|---|---|
| Spike | A feasibility question | An answer, not code you keep |
| Bounded | A small change to a flow that already exists in the repo | A scoped change |
| Architectural | Anything that restructures how the project fits together | A spec you validate, then an implementation plan |

The agent says its classification out loud so you can override it, and the ratchet only turns one way: hidden complexity discovered midway through a task upgrades the path, never the reverse. The file ships a table of red flags, thoughts like "this is too simple to need a design", with the rebuttal next to them: simple tasks are exactly where unexamined assumptions cost the most. Even a spike keeps its guardrail. Whatever the agent builds to answer the question stays labeled throwaway, and keeping that code becomes a new request to classify.

During the dialogue the agent asks the questions a lead engineer would ask and presents its design in digestible sections. On our own pipeline this phase has already killed features we would have built for nothing.

## Plans made of tasks too small to hallucinate

The plan-writing skill opens with an instruction that sets its tone: write the plan for a skilled developer who has zero context on your codebase and, in the file's own words, questionable taste.

Concretely, the work is cut into tasks where every step takes two to five minutes: write the failing test, run it to make sure it fails, write the minimal code that passes it, run the tests again, commit. One action, one verification, and the work moves forward in frequent commits. That is the test-driven development cycle, enforced by another skill in the plugin, so every task carries its own test cycle.

Each task lists the exact files to create or touch, down to line numbers. The plan opens with a mandatory header: the goal in one sentence, the architecture in two or three, the tech stack, a link to the spec, and the project's global constraints copied word for word. If the spec covers several independent subsystems, the skill demands separate plans, one per subsystem, each producing software that is testable on its own.

Task sizing is the heart of the reliability argument. A short task means an agent that finishes its work with a context window that is still mostly empty. It never reaches the moment where the session overflows, the agent loses the thread and starts inventing functions that do not exist. No five-minute demo shows this problem, but it decides everything on a real project: an agent's quality at the end of a session has nothing to do with its quality on the first prompt. Less saturated context means mechanically fewer hallucinations, and code that does what the plan said.

## One subagent per task, one review every time

At execution time, a dedicated skill isolates the work in a git worktree, a separate working copy of the repository, so the plan runs without stepping on whatever you are doing next to it.

The executing skill drives development through subagents. Its principle fits in one line of the file: a fresh subagent per task, a review after every task, and a broad review of the whole branch at the end. Your main session becomes an orchestrator. It no longer codes, it dispatches. Each subagent gets exactly the context its task needs and never your session's history, which avoids context pollution and keeps your own window free for coordination.

The subagent can ask questions before starting, then implements, tests, commits and reviews its own work. When it is done, the orchestrator runs a two-part review, spec compliance first and code quality second, with a dedicated reviewer seat for every task. Nothing is improvised: the skill ships a template prompt for every role (implementer, task reviewer, and the reviewer that rechecks fixes) that the orchestrator fills with the task's context.

| Review outcome | What happens |
|---|---|
| Pass | The orchestrator logs the completion in a ledger and moves down the plan |
| Fail, rounds 1 to 3 | The original implementer resumes, since it already knows the code and its own choices |
| Fail, round 4 | A fresh implementer is dispatched on a more capable model |
| Fail, round 5 | A breaker trips and the orchestrator rules on every open finding itself |

The skill also avoids the opposite excess: a burst of tiny mechanical tasks goes out as one grouped dispatch, reviewed as a single unit. Nothing gets merged without passing a reviewer. The result is what a human team calls a code review process, except it runs on its own, task after task.

## The right model for every task

The dispatch system opens the door to a third win: token economics. The skill has a model selection section that starts with one rule: use the least powerful model that can handle each role. The orchestrator sizes up the difficulty of every task in the plan and assigns the model to match.

| Task | Model tier |
|---|---|
| Well-specified mechanical task touching a file or two, or a plan that already contains the code to write | The cheapest tier (implementation becomes transcription plus testing) |
| Coordination across several files, debugging | A standard model |
| Architecture, the final branch review | The most capable model available |

The file adds two subtleties. 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 work with many steps and end up costing more overall, which is why reviewers and implementers working from prose get a floor one tier up instead of the bargain bin.

This setup makes something counterintuitive viable: running Opus or Fable, the most expensive models in the catalog, on the twenty dollar Pro plan. The expensive model only works on the few decisions that deserve it, and the rest of the plan runs on models that consume a fraction of your quota.

## Committed plans: documentation for free

The last win is the one nobody thinks about when installing the plugin. Specs and plans are not chat messages that vanish when the session ends. They are markdown files saved inside the repository and committed together with the work. The skill fixes the location: a dated plans folder, one file per feature, with the goal, the architecture and the link to the spec in the header.

The spec travels with the plan, and conflicts between the two resolve against the spec: the document is the authority, not the agent's memory. The git history no longer just tells you what changed. It tells you why, and what the agent had decided at the time. Six months later, mentioning the plan file in a prompt lets the agent pick the original feature's context right back up, and a new feature touching the same subsystem builds on the existing spec instead of rediscovering the terrain.

There is no such thing as an untracked task anymore: everything an agent did on the codebase left a document behind, from the first brainstorm to the last commit. The project sums its philosophy up in two principles, systematic over ad hoc and evidence over claims. Documentation falls out of the process on its own.

## What it really costs you

The limit is real and the repository does not advertise it: all this discipline has a fixed cost, and that cost never switches off. The entry skill is blunt. At the slightest doubt the agent must load the skill, and the brainstorming file states that the ceremony scales with the task but the human approval never does.

On a fix of two lines, that means answering framing questions, approving a design of two sentences, then waiting for the full cycle before you see the fix. For a typo in a config file, the complete process is simply slower than fixing it yourself. The orchestration itself consumes tokens: dispatch briefs, two reviews per task and the ledger are paid every single time, which you feel most on the smallest tasks.

There is an opposite symptom too, and it answers the Reddit question directly. If your usage stats show the plugin at a few percent, your requests almost never trigger the skills, so you are paying the entry check every session without ever touching the gains. A fix loop that goes the full five rounds is five diffs, five more reviews and an arbitration, for a task that was supposed to take minutes. The project also never sits still: it went from a first version to a sixth in under a year and still has 125 open issues, so the skills you read today will have changed by the next update.

The plugin plans its own exit. Its instructions put your directives above the skills, so you can tell the agent, explicitly, to skip the process. Our rule: Superpowers on by default for any feature work, and a deliberate skip for tiny fixes.

## Our verdict

| Your Claude Code usage | Verdict |
|---|---|
| Features that take hours | Install it: the framing keeps you from implementing the wrong thing, short tasks keep the agent away from context saturation, model selection stretches your quota, and you inherit documentation you would never have written |
| Throwaway scripts and small fixes | Walk on by: you would pay the fixed cost of the process on tasks that do not need it |
| In between | Install it and learn to say skip: one sentence in your prompt hands control back to you |

If you want to test it without adopting everything, let only the brainstorming skill run for a few days. It carries most of the gain, and the other skills graft on naturally after it. The plugin keeps its four promises as long as you feed it features worthy of its ceremony. It now runs on our own projects, and the brainstorming phase is the one we would not switch off anymore. The repository is free and open source, with 280,000 people in line ahead of you.

## FAQ

### What is the Superpowers plugin for Claude Code?

A free, open-source plugin by Jesse Vincent, on Anthropic's official plugin marketplace, made of fourteen markdown skills the agent loads when a situation matches: brainstorming, plan writing, subagent-driven development, test-driven development, systematic debugging and others. A session-start hook forces Claude to check whether a skill applies before every task.

### Is Superpowers worth it or a tokens killer?

Both, depending on your work. On feature work that takes hours it pays on four fronts: framing, reliability, token spend and documentation. On small fixes its fixed ceremony costs more than it returns. If your usage stats show the plugin at a few percent, the skills never trigger and you pay the entry check without the gains.

### How does Superpowers reduce hallucinations in Claude Code?

By cutting plans into tasks where every step takes two to five minutes and running each one in a fresh subagent. The agent finishes its work with a context window that is still mostly empty, so it never reaches the point where the session overflows and it starts inventing functions that do not exist.

### Does Superpowers save tokens?

Its model selection rule assigns the least powerful model that can handle each role: the cheapest tier for well-specified mechanical tasks, a standard model for coordination and debugging, the most capable model for architecture and the final branch review. That keeps the expensive model on the few decisions that deserve it.

### How do you skip Superpowers on a small fix?

Tell the agent explicitly to skip the process. The plugin's instructions put your directives above the skills, so one sentence in your prompt hands control back to you. Our rule: Superpowers on by default for feature work, a deliberate skip for tiny fixes.

### Which Superpowers skill should you try first?

Brainstorming. It is the gate everything passes through: no code until you approve an explicit intent, three paths (spike, bounded, architectural) and a spec plus a plan on the way out. It carries most of the gain, and the other skills graft on naturally after it.

## Sources

- [obra/superpowers on GitHub](https://github.com/obra/superpowers) — GitHub
- [The fourteen skills (skills/ directory)](https://github.com/obra/superpowers/tree/main/skills) — GitHub
- [Superpowers philosophy (README)](https://github.com/obra/superpowers#philosophy) — GitHub
- [Superpowers on the Claude plugin marketplace](https://claude.com/plugins/superpowers) — Anthropic
- [Superpowers for Claude Code (origin story)](https://blog.fsck.com/2025/10/09/superpowers/) — Jesse Vincent
- [Open issues, obra/superpowers](https://github.com/obra/superpowers/issues) — GitHub
- [Whats u experience with superpowers plugin? Is it worth it or a tokens killer?](https://www.reddit.com/r/ClaudeCode/comments/1v3xie6/whats_u_experience_with_superpowers_plugin_is_it/) — r/ClaudeCode