Practical tips for the Superpowers workflow

If you use an agentic coding setup, you have probably seen skills: small instruction files that tell the model how to behave on certain kinds of tasks. Superpowers is a popular set of those skills. They are easy to install and much harder to run consistently, because each one encodes a gate (wait for design approval, do not fix before root cause, do not say “done” without a command you actually ran).

Why skills beat “just be careful”

Vague prompts produce vague behavior. Skills turn recurring discipline into something the session can load and follow: design before implementation, plans with verifiable steps, debugging that forbids guess-fix loops, verification before success claims.

The trick is not collecting skills. It is naming the workflow in chat so the agent actually follows the right one. On some platforms you invoke a Skill tool; on others you paste or attach the skill. The mechanism differs; the habit is the same: pick the process before the keystrokes.

The one-percent rule and ordering

Superpowers’ entry skill, using-superpowers, pushes a simple rule: if there is any chance a skill applies to what you are doing, open it first, then act. That feels heavy until you notice how often “I will just peek at the repo” turns into implementation without a spec.

When multiple skills could apply, prefer process skills before implementation skills. Roughly: figure out what and why (brainstorming, debugging) before how (framework-specific or build skills). “Add a feature” is not permission to skip design; “fix this bug” is not permission to skip root-cause investigation.

Quick starter playbook

Keep this somewhere you see it until it is muscle memory:

1. New behavior or feature
   1. Use brainstorming.
   2. Then use writing-plans.
   3. Execute with preferred subagent-driven-development (or executing-plans when needed).
   4. Run verification-before-completion.
   5. Finish with finishing-a-development-branch.
2. Bug, failing test, weird runtime
   1. Start with systematic-debugging.
   2. Use test-driven-development for the fix when applicable.
   3. Confirm via verification-before-completion.

Brainstorming: short design, hard gate

The brainstorming skill is built around a hard gate: no implementation until a design is presented and approved, then written to a spec the human reviews. That applies to “small” work too. The point is not bureaucracy; it is that one-line requests hide assumptions (error handling, migrations, who owns rollback). A design can be a few sentences if the change is truly local—but it should still name boundaries, failure behavior, and what “done” means.

Practical habits:

• One clarifying question per message so you do not drown in a questionnaire.
• Prefer multiple-choice when the answer shapes architecture (storage vs in-memory, sync vs async).
• If the ask bundles several systems (auth, billing, analytics in one breath), stop and decompose before refining details.

Writing plans: if the step is not checkable, it is not a step

writing-plans expects plans that another engineer—or another agent—can execute without extra context: exact paths, commands with expected output, code snippets for code steps, and checkbox granularity (roughly two to five minutes per step). Plans belong in dated markdown under a conventional docs path unless your repo overrides that.

Tips that save real time:

• Replace “add appropriate validation” with concrete predicates and tests that fail until they pass.
• If Task 7 repeats Task 3’s pattern, repeat the content anyway; readers jump around; “same as above” plans fail in practice.
• Put the required execution skill in the plan header (subagent-driven-development vs executing-plans) so nobody improvises a third path halfway through.

Execution fork: subagents vs one session

After a plan exists, Superpowers suggests two main executors, but I recommend starting with a default preference:

• Preferred: subagent-driven-development. It uses fresh subagents per task plus review loops (spec fit, then quality). The big win is low context pollution: each subagent gets only the task-specific context, so stale assumptions, unrelated file history, and previous debugging noise are less likely to leak into the current implementation.
• Alternative: executing-plans. It is useful when you cannot or do not want to run subagents, but a single long-lived session accumulates more conversational and code context, which can increase drift over time. The upstream guidance also notes quality tends to be higher with subagent support.

Systematic debugging and TDD as anti-thrash

systematic-debugging centers on an iron rule: no fixes before root-cause investigation. Read errors and stack traces completely, reproduce reliably, diff recent changes, and in layered systems add simple boundary logs so you know which layer lies before you edit the wrong one. When you have tried three real fixes and the ground keeps shifting, treat that as a signal to question architecture with a human before a fourth guess.

test-driven-development adds another brake: no production code without a failing test first, then minimal green, then refactor. If you wrote implementation code before the test, the strict approach is to remove that code, write the failing test first, and then re-implement from the test. It feels strict, but it helps expose tests that would have passed even if the feature were broken.

When the model reaches for phrases like quick fix or probably fine, treat that as a cue to name debugging or TDD explicitly in your next message.

Parallel agents only when work is independent

dispatching-parallel-agents is for independent problem domains (different subsystems, unrelated failing suites) where investigations do not share mutable state. It is a poor fit when fixing one area might fix the others, or when two agents would edit the same files. Give each agent only the files, commands, and hypotheses it needs; do not dump your whole session history into every dispatch.

Verification before completion: evidence, not vibes

verification-before-completion is blunt for good reason: claiming tests pass, the build is clean, or the bug is fixed without a fresh command run in the same turn is misrepresentation, not speed. Decide what command proves the claim, run all of it, read exit codes and failure counts, then speak.

Ask the agent for command, exit code, and a one-line summary of failures before you merge or tag a release. For regression tests, insist on a red-green story: see the new test fail for the right reason, then pass after the fix.

Code review skills: do not rubber-stamp the model

If you use requesting-code-review and receiving-code-review, treat them as a reminder that review is verification of claims and design fit, not politeness. Push back when a suggestion is vague; verify when a refactor is larger than the bug warrants.

Rationalizations worth interrupting

These thoughts usually mean “slow down and load the right skill”:

Adopting this in a week (without heroics)

Week 1 — Skill check and verification. On every task, start by naming which skill applies (even if brief). Before any “done,” require a proof command in the same response.

Week 2 — Brainstorming gate for behavior changes. No implementation messages until a design is approved; write the spec to your repo’s docs location when the skill expects it.

Week 3 — Written plans for multi-step work. If it is more than one commit in your head, it needs writing-plans granularity. Execute with subagent-driven-development or executing-plans, then finishing-a-development-branch for merge or cleanup options.

Ongoing. Use using-git-worktrees when isolation matters. Keep user and repo rules above plugin defaults when they conflict—they are the real source of truth for your project.

Superpowers does not replace judgment; it bundles judgment you already believe in into something you can invoke on demand. If you only adopt three habits from this post, make them: skill-first, plans with verifiable steps, and no completion claims without fresh command output. Everything else is elaboration.

Related: I Vibe Coded a Windows XP Hugo Theme — a real-world example of using Claude Code to build a complete project from scratch.