Automation & Workflows · Blog Post
Superpowers: the skill-driven development methodology for Claude Code
Point a vanilla coding agent at a real project and it skips straight to code — no design pass, no tests first, no review. Jesse Vincent's Superpowers bundles a set of composable skills plus instructions that force brainstorming, planning, and TDD into the loop automatically, and it has become the single most-installed plugin in the Claude Code ecosystem.
By Mehadi Hasan 9 min read
What problem it solves
Software quality doesn't come from typing code fast — it comes from process: specification, task breakdown, tests before implementation, review, branch isolation. Left alone, an agent optimizes for "produce something that runs," which reliably means skipped tests, mixed responsibilities, and a fragile prototype you end up rewriting by hand. Superpowers, built by Jesse Vincent (GitHub handle obra), is his answer: "a complete software development methodology for your coding agents, built on top of a set of composable skills and some initial instructions that make sure your agent uses them."
The scale it has reached is itself notable — the repo has passed 262,000 GitHub stars, more than Anthropic's own claude-code CLI repository, and it is widely described as the most popular third-party plugin in the ecosystem.
At a glance
The skills split into three groups: testing & debugging (test-driven-development, systematic-debugging, verification-before-completion), collaboration (brainstorming, writing-plans, executing-plans, subagent-driven-development, requesting/receiving-code-review, using-git-worktrees, finishing-a-development-branch, dispatching-parallel-agents), and a small meta layer (writing-skills, using-superpowers) that teaches the agent how to extend the system with its own new skills.
The workflow: brainstorm → plan → TDD → review
Nothing here is invoked by name — a short set of always-on instructions tells the agent to check for a matching skill before starting any task, so the right stage triggers based on what you actually asked for:
- brainstorming — Refuses to write code until it has asked clarifying questions and proposed design options for you to accept
- writing-plans — Breaks the accepted design into 2–5 minute tasks with exact file paths and a verification step for each
- test-driven-development — Per task: write a failing test, watch it fail, write the minimal code to pass, watch it pass, commit
- subagent-driven-development — Dispatches a fresh subagent per task with only that task's spec, then runs a two-stage review — spec compliance, then code quality
The systematic-debugging skill runs the same discipline in reverse for bugs: a four-phase root-cause process instead of guess-and-patch. And verification-before-completion is the guardrail that stops an agent from marking a task done on the strength of "the code looks right" — it has to actually run the check.
TDD cycle enforced by the skill
RED write a test that fails for the right reason
→ run it, confirm it fails
GREEN write the minimal code to make it pass
→ run it, confirm it passes
REFACTOR clean up now that the behavior is locked in
COMMIT one task, one commit, verification step attached
Installation
Official Claude Code marketplace, one line:
Claude Code — official marketplace
/plugin install superpowers@claude-plugins-official
Or straight from obra's own marketplace, which tends to get updates first:
Claude Code — Superpowers marketplace
/plugin marketplace add obra/superpowers-marketplace /plugin install superpowers@superpowers-marketplace
The repo also ships plugin variants for Cursor, GitHub Copilot CLI, and Gemini CLI (its own .cursor-plugin, .codex-plugin, and .opencode directories are committed alongside the Claude Code one) — the skills themselves are plain Markdown, so the methodology travels even where the install mechanics differ. License is MIT throughout.
Using it day to day
You don't drive Superpowers with commands — you drive it by asking for the work you want ("add rate limiting to the API", "fix the flaky checkout test") and the initial instructions make the agent check its skill list before touching code. For a genuinely new feature, expect a real back-and-forth on the design before you see a diff; that friction is the entire point.
It's overkill for a one-line fix — a typo correction doesn't need a brainstorming pass. Where it earns its keep is anything at "build me a feature" scale, especially with subagent-driven-development: each task in the plan gets a fresh subagent with only that task's spec, then two review passes (spec compliance, then code quality) before it's considered done — which keeps a single agent from slowly accumulating an entire feature's context and drifting.
My take
The part that actually changes behavior isn't any single skill — it's that the instructions make the agent check its own workflow before starting, so drift from "we agreed to write a test first" becomes visible immediately instead of three files later. That's a genuinely different failure mode than the usual "the agent went off and did its own thing."
The honest tradeoff: it slows down small changes, and a team already running its own strict TDD/PR discipline may find the brainstorming and planning stages redundant with process they already have. Try it on a feature-sized task before deciding whether to keep it always-on.
Frequently asked questions
Do I have to invoke these skills by name?
No — that is the point. Superpowers ships a small set of always-on instructions that tell the agent to check for a matching skill before starting any task, so brainstorming, planning, and TDD trigger automatically based on what you asked for, not because you typed a slash command.
Will this slow me down on small changes?
For a one-line fix, yes, it is overhead you do not need. Superpowers is built for the "build me a feature" and "fix this bug" scale of work, where skipping design and tests is exactly what produces the throwaway code it is trying to prevent. Use it selectively rather than for every keystroke.
What does subagent-driven-development actually do?
For each task in a plan, it dispatches a fresh subagent with only that task's spec, then runs a two-stage review — one pass for spec compliance, a second for code quality — before the change is considered done. It keeps context clean per task instead of one agent slowly accumulating an entire feature's history.
Is this specific to Claude Code?
It started there, but the repo now ships plugin variants for Cursor, GitHub Copilot CLI, Gemini CLI, and a few others alongside the Claude Code plugin — the skills themselves are plain Markdown, so the methodology travels even if the marketplace mechanics differ per tool.