What's the Difference Between spec, plan, and implementation? The Right Workflow for Superpowers

Earlier articles covered "activate habits first, brainstorm first to reach design consensus." The next common sticking point is: design is agreed upon — now what? Many people at this point just say "okay, start writing" — and the agent dives into modifying files, only to find halfway through that nobody ever wrote down "how many steps, and what to verify at each one." The spec, plan, and implementation in this article's title map to three plain-language levels below, and this article explains where writing-plans sits in the whole chain.

In this series, here's how to think about spec (specification): take the requirements and design that have been discussed and aligned, and write them into a document both you and the agent have confirmed — clearly stating what to build, what deliberately isn't being built, how to know it's done, and what constraints or interface agreements apply. It's not yet an execution table of "which file to modify in which step." Plan is that step-by-step execution guide with verification checkpoints (who does what, in what order, how to check each segment). Implementation is actually going to modify code, run tests, and deliver results according to the plan. One sentence for beginners: spec defines "what and the boundaries"; plan defines "what order to do it in"; implementation is "actually doing it."

The Difference Between Requirements, Design, Plan, and Implementation

The three terms above are a categorization by output type. If you break the first half down further into "how ideas grow," the progression from vague to specific usually looks like this:

Requirement: "What problem are we solving? Who uses it? What does success look like?" — still talking about why and for whom, details can still be rough.
Design: "Which approach, what are the boundaries, what's deliberately excluded, how does it connect to existing code?" — now talking about which path to take and what the trade-offs are. Brainstorming usually helps align this part.
Plan: "Which steps, what order, what to check after each step, where are the risk points?" — this is the executable roadmap. No code written yet, but "next step isn't guesswork" is already established.
Implementation: Actually modify files, run tests, open a PR — following the scope and done-definition from spec, in the order from plan.

Aligning 1 and 2 and writing them into a confirmed document is the spec from above. Only then do you move to plan at step 3, and finally to step 4. Many people treat "design is discussed" as "ready to build" — but the middle may still be missing the drop to spec (otherwise consensus only lives in conversation), and also missing the plan layer. Without them, implementation easily becomes inventing scope and process while writing code, and the chance of rework goes through the roof.

The Role of writing-plans

In Superpowers vocabulary, the role of a writing-plans process skill is simple: after you have a direction (or even a rough spec), write down "how to land it" in a plan that others (including future you) can follow without going off-track.

It's not repeating brainstorming: brainstorming focuses on selecting options, aligning intent; writing-plans focuses on breaking the chosen path into steps, marking checkpoints, and leaving room to backtrack. Think of it as: a project manager writing a sprint task list — except the reader is often an AI agent, so the plan needs to be explicit enough that the agent doesn't shortcut its way to the wrong destination.

In practice it often covers: which files or modules to touch, the recommended order, how to verify after each segment completes, where pitfalls are that need early testing. The point isn't to write beautifully — it's to be executable and verifiable.

The Right Order for Landing Work

Beginners can memorize this sequence, which connects to the earlier articles in the series:

using-superpowers: Confirm which workflows apply this time; don't write code the moment you arrive.
brainstorming (when needed): Clarify requirements, list options, pick a path and define boundaries — design consensus.
writing-plans (when there's scale or multiple steps): Write the landing path as a plan — who does what first, and how to verify.
Implementation skill / actual implementation: Follow the plan to modify code. If there are also quality guardrails like TDD, debugging, or verification-before-completion, attach them based on context (the next article covers this in detail).

Not every one-line fix needs a lengthy plan, but whenever you have the thought "this will probably take several steps" or "I'm afraid changing A will break B," writing a short plan is almost always cheaper than fighting fires later.

Why Jumping Into Implementation Without a Plan Is Dangerous

Without a plan, here are common scripts (learning from these counts as a win; better not to experience them firsthand):

The agent first modifies the easiest file to touch, only to realize later the order was wrong and the whole section needs to be rolled back.
Halfway through, missing a dependency, tests, or environment setup — the "plan" becomes "inventing as you go."
You thought it was done, but only the UI was finished or only half the API — because "done definition" was never written.
When multiple people or multiple conversations hand off the work, the next person can't tell "why it was changed this way" and has to do fresh telepathy.

A plan turns "I assumed you understood" into "it's written in black and white." Whether for humans or AI Agents: less guessing, less rework.

Next Steps

To understand TDD, debugging, and pre-completion verification — the three verification steps that follow implementation: TDD, systematic-debugging, verification-before-completion: Three Quality Guardrails for AI Agents.
To lay out the full path from start to finish: Superpowers Beginner Course.

Back to Series Overview

This article covers the levels of spec / plan / implementation and the role of writing-plans. To return to the series reading map and recommended order, open the Superpowers Beginner Course.