The interesting part is not the seven-phase workflow. It is that Superpowers does not wait to be found relevant — it pushes its rules into every single session at startup. That is why it works, and it is also the bill.
superpowers (by Jesse Vincent, MIT; per the GitHub repo page, 2026-09, roughly 282k stars / 25k forks; per the repo's RELEASE-NOTES.md, latest is v6.3.0, released 2026-08) is not one skill. It is fourteen skills that add up to a development methodology, plus a hook that injects it into every session. The thing it kills for you is simple: the agent starting to write code before it has understood the job. This issue names all fourteen, links each one, says when to skip it, then takes apart the mechanism that makes the rules stick — and what that enforcement costs on small tasks.
# Claude Code: from the official plugin source
/plugin install superpowers@claude-plugins-official
# The README gives one line per harness:
Cursor: /add-plugin superpowers
Gemini CLI: gemini extensions install https://github.com/obra/superpowers
Copilot CLI: copilot plugin install superpowers@superpowers-marketplace
Devin CLI: devin plugins install obra/superpowers
Kimi Code: /plugins install https://github.com/obra/superpowers
# First thing that runs: type no command at all, just say
# "I want to add X to this project"
# It will not start coding. It will ask you questions. That is brainstorming firing.
The seven-phase workflow is just those strung together: brainstorming to using-git-worktrees to writing-plans to subagent-driven-development to test-driven-development to requesting-code-review to finishing-a-development-branch. You install the whole plugin; there are no checkboxes.
hooks/hooks.json in the repo registers a SessionStart hook matching three moments: startup|clear|compact. The hooks/session-start script reads the entire text of skills/using-superpowers/SKILL.md and injects it wrapped in an <EXTREMELY_IMPORTANT> tag. So "triggers automatically" is literal here: it is present before you ask for anything, and it comes back after you clear the context or after an auto-compaction.
The injected using-superpowers is 63 lines, about 3.1 KB (per the repo file, 2026-09), and most of it is a table of excuses — every rationalization the model might use to skip the process, answered in advance. "This is just a simple question" becomes "questions are tasks." "Let me explore the codebase first" becomes "skills tell you HOW to explore." "The skill is overkill" becomes "simple things become complex." It also fixes precedence: process skills come before implementation skills, and your CLAUDE.md / AGENTS.md and direct instructions outrank any skill.
requesting-code-review is the piece worth stealing on its own. The main agent does not read the diff. It captures BASE_SHA and HEAD_SHA, dispatches a general-purpose subagent, and fills the repo's code-reviewer.md template. The SKILL.md states the reasoning plainly: the reviewer gets precisely crafted context and never your session history — so it looks at the work product rather than at your train of thought, and the diff plus the whole evaluation stay in the subagent's context while only findings come back. subagent-driven-development scales that up: a fresh implementer per task, a review after each task, and one broad review of the whole branch at the end.
The loudest early complaint was that asking a small question triggered a two-document ceremony. Per the repo's RELEASE-NOTES.md (v6.3.0, 2026-08), it now classifies the request first and says the classification out loud so you can override it: spike (a feasibility question whose output is an answer, not code you keep — two or three sentences, then go find out), bounded (a change to a flow that already exists in this repo — design presented in chat, no spec file), architectural (new subsystems — full questions, sectioned design, spec, then writing-plans). The rule is take the heavier path when in doubt, and the ratchet only goes up. What does not scale down is the approval gate: on all three paths it stops before implementing.
test-driven-development's iron law: no production code without a failing test first. Wrote the implementation first? Delete it and start over — not kept as reference, not adapted while writing tests. The only exceptions are throwaway prototypes, generated code and config files, and it is told to ask you first.systematic-debugging's four phases: no fixes proposed before root-cause investigation is complete, and in multi-component systems it wants diagnostic logging at each boundary before anyone guesses. It explicitly says to use it especially under time pressure.writing-plans's premise: write the plan for an engineer with no context for your codebase and questionable taste — tasks sliced to two to five minutes, exact file paths, how to verify each one, saved to docs/superpowers/plans/.subagent-driven-development's execution discipline: once running it does not check in between tasks; plan conflicts get a recorded ruling and work continues. Only four things stop it — an irreversible or destructive operation, a security-sensitive action, a side effect outside the worktree (a merge, a push to a shared branch, a publish), and a plan broken beyond repair.Where it fits: multi-file refactors, new subsystems, repos with a working test baseline, and any run where you want to walk away and let it work. Where it does not: copy changes, styling tweaks, one-off scripts, and bugs whose error message already names the cause.
/clear, and after every auto-compaction. Small on its own, but it is non-negotiable and permanent — a different cost model from a skill that is free until it fires.using-superpowers puts CLAUDE.md, AGENTS.md and your direct requests above skills — so the correct way to pause it is to say so in the repo conventions or in the request ("this is a spike, skip TDD"), not to hope it notices the task is small./plan (see the official permission modes docs) proposes before it touches disk. Kills acting before agreeing, at nearly zero cost. Where it runs out: no tests, no review, no trace that survives the session.skills/systematic-debugging/ or skills/test-driven-development/ into ~/.claude/skills/ as folders. They trigger from their own descriptions, with no hook attached. This is the entry route this issue recommends — most of the value, none of the standing tax. Where it runs out: when the un-skippable enforcement is exactly what you wanted.CLAUDE.md / AGENTS.md. Kills repeating yourself every session. Where it runs out: conventions are soft, and a model in a hurry skips soft things.skill-creator from the official anthropics/skills repo, or read superpowers' own writing-skills as the model. Where it runs out: before you have accumulated the things you re-explain every time, what you write is an empty shell.Install these three first (if you only want part of superpowers): skills/systematic-debugging/ + skills/test-driven-development/ + skills/verification-before-completion/ — three folders copied into ~/.claude/skills/, each useful standalone, no SessionStart hook.
When the whole plugin is worth it: the work in front of you is a multi-file refactor or a new subsystem · the repo has a test suite that runs · you intend to let it work a long stretch instead of watching every step. All three, or it does not pay.
When to skip it: ten-minute changes · legacy repos with no test baseline · you already have strict CI and human review · your day is mostly copy and styling.
Review two weeks in: how many plans piled up in docs/superpowers/plans/, and how many did you actually go back and read? If the answer is none, your work never needed this layer.
/clear, or context compaction; its output is injected into the context. Superpowers uses one to place its charter in every session — the root of how it differs from an ordinary skill.skill-creator lives here