AIDive

Video pack

Superpowers for Claude Code: verdict table, sources, checklist and go-further guide

9 min read

TL;DR

  • Superpowers is a process, not a toolbox: fourteen markdown skills that gate every feature behind a brainstorming session, a written plan and a chain of fresh subagents, each reviewed.
  • Install it if your Claude Code sessions build features that take hours. Skip it if your usage is throwaway scripts and two-line fixes: the entry check runs on every task and never switches off.
  • The token argument is real, but it comes from one section of one skill: Model Selection. The orchestrator assigns the cheapest model that can hold the role, so the expensive model only touches architecture and the final branch review.
  • The repo is healthy: 280,597 stars, 25,138 forks, 681 commits on main, release v6.3.0 on 2026-08-12, created on 2025-10-09.
  • The complaint that started the video, usage stats at 1 to 3 percent, is not a bug: it means the skills never trigger on your work, so you pay the gate and get nothing back.
  • The middle path is one sentence in your prompt: tell the agent to skip the process on tiny fixes, and let brainstorming alone run for a few days before adopting the rest.

What the sources say

The repository numbers were read on 2026-09-02: 280,597 stars, 25,138 forks and 681 commits on the main branch, with the last commit on main dated 2026-08-12 (v6.3.0) and a later push on 2026-08-31 to a non-main branch s1. The Issues tab showed 125 open issues that day; the API figure of 350 includes the 225 open pull requests, so quote the tab, not the API, when you compare it to other plugins s6. The project was created on 2025-10-09 and ships fourteen skills s2. The author's launch post explains the bet in one line: coding agents do not lack capability, they lack discipline, and that discipline can be distributed as plain markdown files anyone can read, fork and edit s5. The plugin is listed on the official marketplace, so installation is a single command and updates follow the marketplace s4.

The entry point is a skill the session-start hook loads before anything else. It tells the agent that if there is even a doubt about whether a skill applies, it must load it and check, before answering or writing code. That rule is the source of both the benefit and the fixed cost s14.

Brainstorming opens with a HARD-GATE: no code, no scaffolding, no implementation skill until you have validated an explicit intent. It then sorts the request into one of three paths: spike, when the output is an answer rather than code; bounded, for a small change inside a flow the repo already has; architectural, for anything that restructures the project. The agent announces the classification so you can contradict it, and the ratchet is one way: hidden complexity found mid-task moves the path up, never down s9.

The plan writing skill asks for a plan written for a competent developer who has no context on your codebase and, in the file's own words, questionable taste. Work is cut into tasks whose every step takes two to five minutes: write the failing test, run it to see it fail, write the minimal code, run the tests again, commit. Each task lists the exact files to create or modify, down to line numbers, and the plan opens with a mandatory header s10.

Execution is the subagent-driven development skill: one fresh subagent per task, a review after every task, a whole-branch review at the end. The main session stops coding and dispatches. Each subagent gets only its task's context, never your session history, which keeps your own window free for coordination. After the subagent implements, tests, commits and self-reviews, the orchestrator runs a two-part review, spec compliance first, code quality second, with a reviewer seat reserved for every task. The file caps the loop at five rounds maximum per task s11. Isolation of the work itself is delegated to a worktree skill, so a plan never runs on your current checkout s13.

The Model Selection section starts with one rule: use the least capable model that can hold the role. A well-specified mechanical task touching one or two files goes to a small model; when the plan already contains the code to write, implementation is transcription plus tests, so the cheapest tier is enough. Multi-file coordination and debugging go to a standard model. Architecture and the final branch review ask for the most capable model available. Two details matter in practice: always name the model explicitly at dispatch, and let the orchestrator rate each task's difficulty before choosing s12. This is the mechanism that makes the expensive model affordable on the twenty dollar Pro plan: it only works on the decisions that deserve it.

The documentation gain is a side effect of the process. Specs and plans are not chat messages that disappear; they are markdown files saved in the repo and committed with the work, so a reviewer later reads why a change was made, not only what changed s3.

The cost is the one the repo does not advertise. The thread that triggered the video reports usage stats at 1 to 3 percent and asks what the drawback is beyond not using it s7. The answer in the files is that brainstorming scales its ceremony to the task but never skips human validation s9. On a two-line fix you still answer framing questions, approve a two-sentence design and wait for the full cycle. Dispatch briefs, two reviews per task and the tracking ledger are tokens you pay every time, and that shows on the smallest tasks. Low usage stats mean the skills are not matching your work, which is the real signal to read.

Verdict by usage

Your Claude Code usage Install? Why
Features that take hours, several files, a branch Yes Framing avoids building the wrong thing, short tasks keep the agent away from context saturation, model selection stretches the quota, docs fall out of the process
Mixed: features some days, fixes most days Yes, with a skip rule Keep the gate for features, tell the agent in the prompt to skip the process on small fixes
Throwaway scripts, config typos, two-line fixes No The fixed cost of the gate runs on tasks that do not need it
Curious but not ready to adopt the whole method Brainstorming only It carries most of the gain; the other skills attach naturally afterwards

Do this Monday

  • Install from the official marketplace and open the plugin cache: read the fourteen SKILL.md files once, they are short and they are the whole product.
  • Run one real feature through the gate end to end: brainstorming, plan, subagent dispatch, branch review. Judge the process on that, not on a fix.
  • Check your usage stats after a week. Below a few percent, the skills are not matching your work: either your tasks are too small or you need to phrase requests as features.
  • Add a skip rule to your project instructions: on single-file fixes under a few lines, go straight to the change, no brainstorming.
  • Copy the Model Selection ladder into your own subagent prompts even if you drop the plugin: name the model explicitly on every dispatch.
  • Commit the specs and plans the plugin writes instead of deleting them; they are your design record.
  • Count the open issues on the Issues tab, not from the API number, before you compare the project to another plugin.

Go further

  • Read the launch post for the design intent before the skill files: it explains why discipline is distributed as markdown and not as code s5.
  • The philosophy section of the README is the short version of the method and the place to check whether it fits how you already work s3.
  • The skills library section lists the fourteen skills with a one-line purpose each; it is faster than browsing the directory s16.
  • The subagent skill's five rounds maximum per task is a hard stop worth copying into any orchestration you write by hand s11.
  • A thread asks whether this kind of plugin survives stronger models; the parts that survive are the framing gate and the committed plans, the parts the models absorb are the mechanics s19.
  • A report of a weekly usage limit burned by orchestration ceremony is the counter-case to read before adopting it on small work s20.
  • The comparison with a competing instruction set shows the trade: fewer, stricter skills versus a large catalogue of rules s18.
  • The open issues list is the fastest read on what breaks for other users today s6.

Sources

FAQ

Does Superpowers save tokens or burn them?

Both. On features, model selection sends mechanical tasks to small models and keeps the expensive model for architecture and the branch review, so the quota stretches. On small fixes, the briefs, the two reviews per task and the ledger are pure overhead.

What do usage stats at 1 to 3 percent mean?

The skills only trigger when a situation matches them. A low figure means your tasks are not features in the plugin's sense, so you pay the entry check and never reach the part that pays back.

Can I keep part of it?

Yes. Brainstorming alone carries most of the gain, and the Model Selection ladder works in any hand-written subagent prompt. Tell the agent to skip the process on tiny fixes and you keep control.