The Superpowers skill suite: what it covers and what it deliberately doesn't

Published 2026-05-11 by Owner

The default Claude Code session has no workflow structure. The model will write code, refactor code, suggest approaches, and fix bugs — but it has no built-in concept of “we should agree on a plan before writing anything” or “before we call this done, here’s the evidence checklist.” Whether that’s a problem depends on what you’re building. For small tasks, the absence of structure is fine. For anything that spans multiple sessions, multiple files, or multiple people, the lack of workflow discipline creates drift.

Superpowers is a community-maintained skill pack that adds that structure. It’s a suite of about a dozen skills that give Claude Code a consistent workflow discipline across the full development arc: from first idea to merged PR. This post is an honest account of what it covers, what each skill does, and — crucially — what the suite deliberately leaves alone.

The three design axes

The skills organize cleanly into three groups.

Workflow skills cover the sequence of work: turning an idea into a spec, a spec into a plan, and a plan into code. Brainstorming, writing-plans, and executing-plans are the core here. They’re designed to run in sequence, though nothing forces the sequence — each skill is independently useful. Subagent-driven-development also belongs here: it’s the execution model for plans that have separable tasks.

Discipline skills enforce good habits during execution: TDD, systematic debugging, and verification before claiming done. These are the ones that prevent the most common failure modes of agentic coding — the agent claims to have fixed the bug but hasn’t run the tests, or fixes a symptom without identifying the root cause. Discipline skills are usable without the workflow skills; nothing stops someone from adopting just the TDD skill while ignoring brainstorming entirely.

Integration skills handle the surrounding git workflow: creating and using worktrees, finishing a branch correctly, requesting and receiving code review. These are the operational hygiene pieces that are easy to skip and painful to reconstruct after the fact. Worktrees matter especially when subagent-driven-development runs multiple tasks in parallel — without worktrees, parallel agents writing to the same branch create conflict noise.

The design respects that not every project needs every axis. A solo developer on a short-lived project might use only the discipline skills. A team working on a long feature might use all three axes in the sequence the suite was designed for.

The flagship skills

brainstorming — Turns a rough idea into a structured spec through guided dialogue. Instead of jumping to implementation from a vague prompt, this skill asks clarifying questions, surfaces assumptions, and produces a document the next skill can consume. It’s the “understand the problem before solving it” gate.

writing-plans — Takes a spec (from brainstorming or written by hand) and breaks it into a task list with explicit sequencing and dependencies. The output is designed to be consumed by executing-plans. The emphasis is bite-sized tasks that each have a clear done state.

executing-plans — Works through a task list one item at a time. Each task gets its own focused context; the skill doesn’t try to hold the entire plan in one conversation. Pairs well with subagent-driven-development for running tasks in parallel.

subagent-driven-development — Dispatches independent tasks to fresh subagents rather than executing everything in one long-running session. Fresh context per task means each subagent isn’t carrying forward assumptions or errors from earlier work. Useful for plans with clearly separable tasks.

test-driven-development — Enforces the red-green-refactor cycle. The skill won’t let the agent claim a task is implemented until tests for that task exist and pass. It’s a discipline constraint, not a framework — it works with whatever test setup the project already has.

systematic-debugging — Requires root-cause identification before any fix is written. The pattern it enforces: reproduce the bug, trace the cause, verify the cause, then fix the cause. Symptom-suppression fixes (adding a null check because something was null, without asking why it was null) are explicitly excluded.

verification-before-completion — Before the session ends or a task is marked done, this skill runs an evidence checklist: tests pass, the stated goal is demonstrably met, no regressions in adjacent areas. The goal is to eliminate “the agent says it’s done but it isn’t” as a failure mode.

requesting-code-review / receiving-code-review — These are workflow hygiene for review cycles: what to include in a review request, how to handle the feedback received. Useful when review involves another person or when self-reviewing before a merge.

using-git-worktrees — Sets up and uses git worktrees to isolate feature work. Practical for running multiple tasks in parallel without branch contamination.

finishing-a-development-branch — The end-of-branch cleanup workflow: merge conflict resolution, final test run, PR creation, and cleanup. The skills that are easy to rush and easy to get wrong.

writing-skills — Meta: for authoring and editing skills themselves. Useful if extending the suite.

A day in the life

Here’s a concrete walkthrough of a feature addition using four of these skills in sequence.

The task: add CSV export to a reporting tool. The export should include all visible columns, respect the active filter state, and trigger a download.

Step 1: brainstorming. Before writing a line of code, the brainstorming skill runs through a dialogue: what columns, what delimiter, what encoding, what happens on empty results, what happens with very large result sets, what’s the filter state API. Twenty minutes of structured questions surfaces three edge cases that would have required rework mid-implementation.

Step 2: writing-plans. The brainstorming output feeds into writing-plans. The spec is one page. The resulting task list has six items: one for the CSV serialization utility, one for the filter-state integration, one for the download trigger, one for the empty-state handling, one for large-set streaming, one for tests. Each task has a clear input, clear output, and a test expectation.

Step 3: executing-plans with subagent-driven-development. Tasks 1, 2, and 3 are independent. They run in parallel via subagent-driven-development — three fresh subagents, each with a single task and its test expectation. Tasks 4 and 5 depend on tasks 1 and 2 completing first, so they run after. The TDD skill runs inside each subagent, enforcing the red-green cycle.

Step 4: finishing-a-development-branch. After the tasks pass, the finishing skill runs the full test suite, checks for regressions in the reporting module, creates the PR with a description that matches what was specced in step 1, and cleans up the worktrees from step 3.

Total time: about two hours. The brainstorming step alone prevented at least one mid-session pivot — the empty-result handling edge case wasn’t in the original prompt, and would have been discovered mid-implementation. The parallel subagent step saved probably thirty minutes over sequential execution.

The verification-before-completion skill ran at the end of each subagent session, not just at the end of the whole feature. That’s the right place for it: catching a test failure in the CSV serialization task before the filter-state task builds on top of it is far cheaper than discovering the failure at integration time.

What Superpowers doesn’t cover

This is the part of the design that’s worth paying attention to.

The suite covers meta-workflow — the discipline of how to work — and nothing else. It deliberately doesn’t touch:

Deployment. How to push to production, how to roll back, how to configure CI/CD pipelines. There are skill packs for this (gstack’s /setup-deploy and /land-and-deploy cover the deployment arc). Superpowers stops at the PR.

Language-specific frameworks. No React conventions, no Django patterns, no Rails idioms. The suite is language-agnostic by design. A TDD skill that only worked in TypeScript would be a TypeScript skill, not a workflow skill.

UI and design. No layout review, no component design, no visual critique. That’s a different skill family entirely (gstack’s /design-review and similar).

Security audit. No OWASP checks, no threat modeling, no CVE awareness. There are dedicated skills for this. Mixing security review into a generic workflow suite would either water down the security review or bloat the workflow.

The consistent logic: if a concern is domain-specific, it belongs in a domain-specific skill pack. Superpowers is the skeleton; other packs provide the flesh for specific domains.

This is a tradeoff worth naming honestly. The suite gives structure and discipline. It doesn’t give expertise. A systematic-debugging session still requires the developer to understand the codebase well enough to evaluate the root cause the skill surfaces. Brainstorming still requires the developer to ask the right clarifying questions. The skills provide scaffolding, not judgment.

The boundary also has a practical rationale. Domain-specific skills age faster than workflow skills. React conventions change; the principle of “agree on a plan before writing” does not. Keeping Superpowers at the meta-workflow layer means the suite stays useful across framework generations without constant updates.

When not to run the full suite

The brainstorm → plan → execute arc has overhead. For tasks under about thirty minutes, the overhead is a larger fraction of the work than the benefit it provides. A one-file refactor doesn’t need a spec. A typo fix doesn’t need a task list.

The skills most valuable at small scale are the discipline ones, not the workflow ones. Verification-before-completion is worth running on a two-line change as much as on a two-week feature. Systematic-debugging is worth running the first time a bug appears, regardless of how trivial it looks — bugs that look trivial and turn out to have deep roots are exactly where symptom-suppression fixes do the most damage.

A practical heuristic: use the workflow skills (brainstorming, writing-plans, executing-plans) when the task requires work in more than two files or takes more than a single focused session. Use the discipline skills always.

Installation and per-project scoping

Installation happens through the gstack CLI. The skills are installed globally by default, making them available across all projects.

# install the suite
gstack install superpowers

# verify what's available
# (skills appear in Claude Code's skill menu)

Per-project scoping uses the project’s .claude/settings.json. If a project doesn’t need the full suite — say, a small documentation repo where subagent-driven-development is overkill — specific skills can be disabled at the project level without affecting other projects.

{
  "skills": {
    "superpowers:subagent-driven-development": { "enabled": false },
    "superpowers:using-git-worktrees": { "enabled": false }
  }
}

When multiple skill packs are installed, precedence follows a simple rule: project-level settings override user-level settings, which override global defaults. A project .claude/settings.json that disables a skill takes priority over a user-level enablement of the same skill. If two packs provide skills with the same name, the one loaded last wins — which is configurable in the global settings.

Skills are invoked by name within a Claude Code session. Typing /superpowers:brainstorming at the start of a new feature is the typical entry point. The using-superpowers skill, if run at the start of a new conversation, gives Claude Code a full map of which skills exist and when each one applies — useful when onboarding a new team member to the workflow.

In practice, most projects want the full suite. The skills are lightweight enough that having them available and not using them costs nothing.

Where this leaves the workflow question

Superpowers doesn’t solve the underlying problem of agentic coding — that long-running sessions accumulate context, drift from the original goal, and produce work that’s harder to verify than the task warranted. What it does is insert deliberate checkpoints that interrupt that drift: agree on a plan before writing, verify before claiming done, understand the root cause before writing a fix.

Whether those checkpoints are worth the overhead depends on the task. For a ten-line change, the brainstorm/plan/execute sequence is too much. For a three-day feature, the discipline compounds. The skill descriptions above should give enough signal to decide which skills apply to which tasks without running all of them by reflex.

The suite is actively maintained and the skill descriptions in the system-reminder reflect the current versions. If the suite’s approach to workflow discipline fits the way a project is run, it’s worth installing. If it doesn’t fit — if the project is in an early exploration phase where structure is premature — the individual discipline skills (TDD, systematic-debugging, verification-before-completion) can be used standalone without adopting the full workflow arc.