The default development workflow

Speedwave ships the superpowers plugin enabled by default, so most sessions that build or change something follow a staged workflow rather than jumping straight to code. This page walks through what you see at each stage and what Speedwave asks you to approve. For the full inventory of what ships in every container, see built-in skills and plugins.

Brainstorming

When you ask Speedwave to build or change something, it starts by asking questions rather than writing code. Expect a short back-and-forth to pin down what you actually want, followed by a design written out in chunks, each one presented for you to approve before Speedwave moves to the next. You stay in control of scope here: if a question does not matter to you, say so and Speedwave moves on.

An isolated workspace

Once the design is approved, Speedwave sets up an isolated branch or worktree to work in, and checks that the existing tests pass there before making any change. This keeps the work separate from whatever else is on your main branch, and gives Speedwave a known-good baseline to compare against as it goes.

Writing the plan

Speedwave breaks the approved design into small, concrete tasks, each scoped to a few minutes of work with the exact files it touches and how to verify it succeeded. You see this plan before implementation starts, so you can catch a wrong turn while it is still cheap to redirect.

Execution

Each task in the plan runs in a fresh subagent that only knows that one task, not the whole conversation history. Every piece of work gets a two-stage review before Speedwave considers it done: first, does it match what the plan asked for, then, is the code itself good. You see this as a stream of small, reviewed steps rather than one large, opaque change.

Test-driven development

For each piece of implementation, Speedwave writes a failing test first, then just enough code to make it pass, then cleans up the result. You will see a failing test appear before the code that satisfies it, in that order, for each piece of the plan.

Code review

Before wrapping up, Speedwave re-reads the finished work against the original plan and flags anything that does not match, sorting what it finds by how serious it is. This is a check against the plan you already approved, not a second design discussion.

This plan check is the first tier of review, not the only one. For an everyday review of a diff, or to review a pull or merge request on GitHub or GitLab, use Claude Code’s built-in /code-review command, the flow described in AI-assisted code review. When you want the strongest pass Speedwave offers, invoke /speedwave-code-review: it runs fourteen specialized reviewers in parallel (security, performance, duplication, test coverage, and more) over any changeset and merges only the verified findings. See built-in skills and plugins for the full reviewer list.

Finishing the branch

At the end, Speedwave verifies the work again and then asks you how to conclude it: merge, open a pull or merge request, or clean up and stop. Nothing lands on a shared branch without you choosing that option.

Debugging and verification, throughout

Two behaviors apply outside the staged flow above, whenever they are relevant. When Speedwave hits a bug or a failing test, it works through root-cause analysis in structured phases instead of guessing at a fix. And before Speedwave tells you something is done, fixed, or passing, it runs the verification for that claim first, rather than asserting it from confidence alone.

How this relates to planning and user stories

This workflow is about how Speedwave builds inside a session, breaking one piece of work into reviewed, test-driven steps. Planning and user stories is about where requirements live before that: Jira, Confluence, or Redmine, tracked through those integrations. The two meet where a plan step references or updates an issue in one of those systems; neither replaces the other.

Opting out

Disable the whole flow for a project’s container with /plugin disable superpowers. That choice persists across restarts; Speedwave does not reinstall it for you. Within a session, you can also just tell Speedwave to skip the ceremony for something trivial, a one-line fix does not need a brainstorm and a plan, and Speedwave will scale down accordingly.