Skip to content

Superpowers and Disciplined Workflows

The superpowers plugin (installed and enabled in this setup) is worth its own page because it encodes the practices the rest of this knowledge base preaches. It's a collection of workflow skills that turn good intentions — "plan first," "write the test first," "verify before claiming done" — into steps Claude actually follows. Where the foundations explain why, superpowers makes the how automatic.

Who this is for. Engineers who want Claude to follow a repeatable, reviewable process instead of vibe-coding. Non-engineers can read the Why and the walkthrough to see what disciplined AI work looks like.

The superpowers chain, from brainstorm to evidence-before-assertions — 2 min 11 s.

Why a workflow plugin at all

A capable model will happily implement the wrong thing very efficiently, declare a broken build "fixed," and skip the test that would have caught the regression. None of that is malice — it's a model optimizing for the prompt in front of it without the instinct to slow down. The superpowers skills supply that instinct: they front-load thinking, force evidence before claims, and keep large tasks from collapsing into one giant unreviewable diff.

Each skill below auto-invokes when the situation matches its description (see how skills get auto-invoked), or you can name it directly.

The core chain

These run roughly in sequence for any non-trivial piece of work.

brainstorming

Explores intent, requirements, and design before any code exists. It pushes back, asks what you actually want, and surfaces constraints and edge cases while they're still cheap to change. Why it matters: the costliest mistakes are the ones you build on top of. Pairs with Plan and Design First.

writing-plans

Turns the agreed design into a concrete, ordered implementation plan — steps, files, checkpoints. Why it matters: a written plan is a compact contract you can review in a paragraph instead of a pull request, and it keeps the model on course instead of wandering.

executing-plans / subagent-driven-development

Two ways to carry out a plan:

  • executing-plans runs the plan in a separate session with review checkpoints between steps — good for sequential work you want to watch.
  • subagent-driven-development dispatches independent plan steps to subagents in the current session — good when steps don't depend on each other.

Why it matters: executing in discrete, checkpointed units means you review working increments, not a 2,000-line surprise.

Isolation and parallelism

using-git-worktrees

Ensures work happens in an isolated workspace (a git worktree) rather than on top of your current branch. Why it matters: you can run multiple efforts at once without them stepping on each other, and abandoning an experiment costs nothing. This is the backbone of Parallel Sessions with Worktrees.

dispatching-parallel-agents

When you have 2+ genuinely independent tasks with no shared state, fan them out to parallel agents. Why it matters: independent work shouldn't run serially. (Use it only when tasks are truly independent — shared state means sequential.)

Quality gates

test-driven-development

Write the failing test before the implementation, for any feature or bugfix. Why it matters: the test defines "done" up front, so the model can't quietly move the goalposts, and a bug fix proves it actually fixes the bug.

systematic-debugging

When something breaks, investigate the root cause before proposing a fix. Why it matters: it stops the "try random changes until the error goes away" spiral that introduces two new bugs for every one it hides.

requesting-code-review / receiving-code-review

  • requesting-code-review asks for a structured review when a task or major feature is complete, before merging.
  • receiving-code-review handles incoming feedback with technical rigor — verifying suggestions rather than performing agreement or blindly implementing questionable advice.

Why it matters: review is where correctness and intent are checked against reality. For a heavier or independent second opinion, route to the codex or /code-review tools — see Verification and Review.

verification-before-completion

Before claiming work is done, fixed, or passing, run the verification commands and confirm the output. Why it matters: this is the single highest-value habit — evidence before assertions, always. No "should work"; show the green test run. Once everything passes, finishing-a-development-branch guides cleanly merging, opening a PR, or cleaning up.

The chain, end to end

A typical non-trivial task threads these together:

  1. brainstorming → agree on intent and design.
  2. writing-plans → produce a reviewable plan.
  3. using-git-worktrees → isolate the work.
  4. executing-plans or subagent-driven-development → build it in checkpointed steps, each guarded by test-driven-development.
  5. systematic-debugging → whenever something breaks.
  6. verification-before-completion → prove it works.
  7. requesting-code-review / receiving-code-review → get and act on a review, then finish the branch.

This is exactly the path described in Feature → Plan → Handoff, and it composes with Parallel Sessions with Worktrees when several features run at once.

Turn your own workflows into skills

When you notice yourself repeating the same instructions across sessions, that's a skill waiting to be written. The skill-creator plugin builds, edits, and evaluates skills, and superpowers' own writing-skills covers authoring conventions. Capture the procedure once, give it a sharp description, and Claude will reach for it automatically from then on. The full pattern — including hooks and automation — is in Reusable Skills and Automation.

Sources

  • Skills — https://code.claude.com/docs/en/skills
  • Create plugins — https://code.claude.com/docs/en/plugins
  • Subagents — https://code.claude.com/docs/en/sub-agents
  • superpowers plugin — https://github.com/anthropics/claude-plugins-official