The dev-suite: run the whole build as one flow

This is the companion to part three, the last one in the series. Part one installed superpowers, the process your agent follows to build one feature. Part two added the backlog it works from. This part ties them into a single flow you run from an idea to a shipped feature, and it ends with a prompt that builds you your own.

What a flow is

A flow is a workflow written as data. It is an ordered list of steps, read left to right, that you and the agent walk through together. A few words to learn, and you will use them today:

• A step is one unit of work, like "write the spec" or "run QA". Each step says what to do and which skill to run for it.
• A manifest is the small file that remembers where this project is in the flow. It is the only thing that changes as you move.

The engine that runs all this is tiny. It reads the list, prints the step you are on, and moves to the next one when you say the current one is done. Everything interesting lives in the data, not the engine.

You have already seen most of a real one. Part two taught the planning stretch, from grilling the idea to slicing it into tickets. Part one taught the build, from the first plan to the passing tests. In the flow, each of those becomes one step, and the rest of the work sits on either side.

The steps around them are the ones we have not covered yet. The two before are insights, where you decide what is worth building, and opportunity, where you lay out a few ways to build it. The two after are deploy, where the work ships, and wrap-up, where the flow records what changed so the next feature starts from the truth.

One engine, many flows

Here is the part that makes this worth learning. The engine does not know anything about software. It runs whatever list you hand it. So one project's flow can look nothing like another's, and the same small engine runs both.

The flow you just saw is the software one. We call it the dev-suite. A different project keeps the same engine and swaps the steps. This very video runs on one, with steps like research and editing instead of code. A phone app could add a step that boots an emulator before QA. A client project could add a step that emails the client when the work ships. You are not editing the engine for any of this. You are editing a list.

That editing has an order to it. When a project needs its own version of a step, it drops a file in the project, and the engine picks the project's version over the shared default. That is how one team runs many projects on one engine without any of them stepping on each other.

Build your own

There is nothing to install. An agent builds your own version. Paste the prompt below into your coding agent, in a project you already have. It writes a small engine and a starter flow, then interviews you to fit that flow to your project.

I want you to build me a small workflow engine and my first workflow, then set it up for this project.

Background: a workflow is data. It is an ordered list of steps, read left to right, that you and I move through together. The engine only tracks where we are; each step says what to do and which skill to run.

Do this in order:

1. Read this project so you understand what it is and how it is built, and check which of my skills are installed so you know what each step can call.

2. Write a workflow definition at .claude/flows/dev.md as plain markdown, one Steps section with a numbered list in order. Start with these five and keep the names:
     1 insights, 2 project management, 3 build, 4 qa, 5 wrap-up.
   Under each step, write one line for what it does and which skill runs it. If I have the skill, name it; if I don't, write the step as plain instructions you follow directly.
   - insights: decide what is worth building next.
   - project management: grill the idea into a spec, then cut it into tickets. Uses Matt Pocock's planning skills if I have them.
   - build: take the next ticket and build it. Uses the superpowers skill if I have it.
   - qa: check the work against the spec.
   - wrap-up: record what shipped so the next feature starts from the truth.

3. Write a tiny engine as one script, under 150 lines. Given the definition and a saved position,
   it prints the current step with its instructions and advances when I say the step is done.
   Save the position in a manifest, a small file next to the definition.

4. Interview me, one question at a time, to fit the flow to this project. Ask which step is
   missing for how I actually work, whether any step should be split or renamed, and which skill
   each step should call. Recommend an answer to every question, then add, drop, or reword steps
   from what I tell you.

5. Show me the finished flow, left to right, and wait before we run it on a real feature.

The flow you get is yours. The names and the steps bend to how your project actually works, because you answered the interview and your agent wrote it down.