New Features, Bug Fixes, Wrap-Ups: Superpowers in Real-World Workflows

Writing code looks like "modifying files" on the surface, but in practice it's mostly: figure out what to do first, then act, then prove it didn't break, then hand it off. Superpowers has a lot of skills that can sound like a lot to track — but in real work, think of it as a cheat sheet for "when I hit this situation, what do I call first." This article doesn't re-explain all the earlier articles in full — it just maps the most common four scenarios into copy-paste-ready sequences. By the end, you'll at least know: which workflow to activate right now, instead of letting the agent charge ahead the moment you open a conversation.

Scenario 1: Building a New Feature

Step 1: using-superpowers.
Not a superstitious ritual — it gets the agent into "read the skills first, sequence the workflows first" mode, so it doesn't start modifying ten files the moment you open your mouth.

Step 2: Requirements still in the fog → brainstorming.
As long as you have a thought like "I'm not really sure what the best approach is," hold off on implementation. Surface the intent, constraints, and trade-offs — turn options into multiple choice instead of guesswork.

Step 3: Scope grows, steps multiply → writing-plans (or your environment's equivalent "write the plan before acting" workflow).
Plan before implementing, and rework drops dramatically. The spec/plan/implementation article in this series goes deeper on this — for now, just remember: big feature = write the roadmap first.

Step 4: Ready to touch code → implement according to the plan; if your team prefers test-first, pair with test-driven-development.
The point isn't to memorize the name — it's "define what correct looks like first, then code until it's correct."

Mnemonic: New feature = activate habits first → align requirements → plan big work first → then implement and verify.

Scenario 2: Fixing a Bug

Step 1: Still using-superpowers.
Getting halfway through a bug fix only to realize "we were fixing the wrong battlefield" is extremely common. Opening with the workflow keeps your mindset stable.

Step 2: systematic-debugging.
Replace "guessing" with "evidence-based elimination": reproduction steps, observe the phenomenon, narrow the scope, validate the hypothesis. What beginners most commonly lack isn't intelligence — it's one more question: "how do I know this is where it's broken?"

Step 3: Root cause found, before writing code — if the change might touch multiple areas → go back to a short plan or at least list the blast radius.
Small fixes can be brief, but whenever your gut says "what if this breaks something else," write two lines of trade-off notes before acting.

Step 4: Change complete → the verification-before-completion type of verification habit.
Run the commands that need running, check the output that needs checking, then say "done." This is much more pleasant than being tagged by a teammate at midnight.

Mnemonic: Bug fix = using-superpowers to open → systematic debugging → think through impact before changing → verify before saying it's done.

Scenario 3: Responding to a Code Review

Why does step 1 here say receiving-code-review instead of using-superpowers like the first two scenarios? Plain answer: if you and the agent are already in the same task context (e.g., you just finished implementing and are now processing PR comments), responding to a review is naturally "the next step in an existing workflow" — calling receiving-code-review directly is the most fitting. By contrast, new features and bug fixes often enter from a blank slate, and need using-superpowers first to activate the "follow the workflow" habit. If you're starting a brand new conversation, or switching to a completely fresh context and feel uncertain, you can still do using-superpowers first to confirm which skill applies, then go into receiving-code-review. The two approaches don't conflict — the difference is where in the workflow you're standing when you enter.

Step 1: receiving-code-review.
The spirit of this skill: first understand what the feedback is saying, which items must change, and which need discussion — don't swing between "okay I'll change everything" and "you don't get it" right away.

Step 2: Need to add tests, cover edge cases, or the change grows → use a plan or checklist to break down "tasks from this review."
Treat review comments as mini-requirements: each comment corresponds to one verifiable outcome.

Step 3: After changes, verify → the "need evidence before done" habit applies here too.
Responding to review isn't just modifying code — it includes being able to say "here's how I know there's no regression."

Mnemonic: Review = read and categorize first → treat as tasks to break down → close with verification.

Scenario 4: Wrap-Up and Delivery

Step 1: verification-before-completion.
Before merging, releasing, or submitting a PR — run through your committed checks first: tests, lint, manual happy-path walkthrough — evidence before declarations.

Step 2: If the change is large or involves multiple people → requesting-code-review (or have another agent / teammate do a structured review).
The goal isn't to nitpick — it's to catch one more round of blind spots before merging into the mainline.

Step 3: How to converge work on the branch → finishing-a-development-branch type "wrap-up decision" habit.
Merge, open a PR, or clean up WIP — pick one clear path. Don't let branches become archaeological dig sites.

Mnemonic: Delivery = verify first → request a review when needed → then converge the branch in a clear way.

Beginner Minimum Viable Playbook

If your brain can only hold one set right now, remember these five words in order: Activate → Clarify → Plan → Build → Prove.

Activate: using-superpowers — get the agent into "knows how to use skills" mode.
Clarify: Uncertain what to build → brainstorming; uncertain what's broken → systematic-debugging.
Plan: Big tasks get a plan first (writing-plans track).
Build: Then implement; if test-first is available, use the TDD habit as a guide.
Prove: Before saying it's done, run one round with verification-before-completion rhythm; add review / wrap-up workflows before handing off.

This isn't the only right answer, but for beginners, the most expensive mistakes are usually wrong order: writing code when you should be clarifying, debating when you should be verifying. Lock down the order first — and efficiency will weirdly improve.

Next Steps

To fill in the landing workflow with spec, plan, implementation: What's the Difference Between spec, plan, and implementation? The Right Workflow for Superpowers.
To understand why brainstorming before building matters: using-superpowers and brainstorming: Why You Can't Skip Design and Jump Straight to Building.
To see the full series path and map at a glance: Superpowers Beginner Course.

Back to Series Overview

This article covers the four most common real-world scenarios and the recommended skill order for each. To return to the series reading map, recommended order, and other article topics, open the Superpowers Beginner Course.