Skip to content

Compose the pipeline

Every stage is a composable primitive. Run them one at a time, chain the whole pipeline in a single message, drop the ones this change does not need, reorder them, prompt into any of them, split disjoint tasks across parallel workers, and send each step to a different model.

Whatever arrangement you pick, three contracts hold. That guarantee is the product. A prompt chain can be rearranged too; what it cannot do is promise that the fast route still produces evidence, still gets reviewed, and still leaves a record you can audit six months later.

  • The execution contract. Work happens through the same worker discipline (re-anchor on the spec, implement, commit, verify) whether you stepped through five stages or chained them in one message.
  • The evidence contract. A task is done when flowctl done receives a summary and evidence JSON: commits, tests, PRs. The fast routes go through it rather than around it.
  • The review contract. Whatever review you configured (a cross-model backend, a per-task pin, or a deliberate --review=none) applies identically on every route. A skipped review is a visible decision with a receipt, so the record shows what you chose.

The guarantees live in the contracts rather than in the ceremony, which is what makes an arrangement safe to invent.

Flow-Next runs the same pipeline the same way every time: capture, interview, spec, plan, plan review, work, QA, review, PR. Follow it blind and you get a predictable, high-quality result without memorizing anything, which is what makes it safe to hand to a newcomer or an autonomous loop.

From there you steer in plain language: point a stage at one spec, reshape a plan, pick a different model for a step, adapt to a brownfield codebase. The determinism is the floor and your prompting is the ceiling.

Four ideas carry the whole doctrine, and they come out of field coaching:

  • The default stages exist so you never have to think about process. They were never there to stop you thinking about the problem.
  • The spec is the ratchet and the handover object. You can read code, prototype, or research whenever you like; the spec is what stops the next stage, the next person, or the next agent from silently losing what you learned. The sharpest version of that is to prototype first and capture what the prototype proved, which has its own page: Explore first, then capture.
  • The primitives compose. A skipped interview still produces evidence. A one-shot chain still gets reviewed. flowctl done demands evidence JSON on the fastest route exactly as it does on the slowest.
  • Use the smallest sufficient workflow. A one-file fix does not need a discovery interview; a nine-task migration does. Match the ceremony to the risk. /flow-next:guide picks that route for you, and optional /flow-next:chart is discovery for one oversized unclear idea before capture.

Steering is plain language. Every skill runs from a sentence, and every flag has a sentence equivalent: “implement fn-12 on a new branch, review it with codex” does exactly what /flow-next:work fn-12 --branch=new --review=codex does. The slash commands and flags are the precise, copy-pasteable form. The menu is a menu of intentions.

The Cookbook collects the verified recipes, each one a real scenario, the exact invocation, and one line on why the gates still hold. Its section index is the catalog of moves this doctrine produces: say it in plain language, skip and lighten, prompt into a stage, one-shot chains, evidence-first, model routing, parallelize, autonomy dial, integration tricks, team patterns, compose beyond the pipeline, and frontier moves.

Small fix? Skip the ceremony.

/flow-next:plan fn-9 && /flow-next:work fn-9

Fewer stages, same contracts: the plan still gates the work, and done still demands evidence.

All skip recipes →

If someone told you it was a conveyor belt

Section titled “If someone told you it was a conveyor belt”

The most common misreading, straight from real coaching sessions, is that Flow-Next is a rigid conveyor: interview, spec, plan, work, review, PR, every time, in order. The default is an order, because a predictable order is what a newcomer and an unattended loop both need. Everything above is what you do once you no longer need it.

  • Choosing your route - six worked routes this doctrine produces, from full epic to docs chore, selected by risk and unknowns.
  • Cookbook - the full recipe collection, copy-paste ready.
  • Model routing & steering - the routing half of the menu: tiers, backends, bridges, and how parameters and prompting compose.
  • The Pipeline - the baseline itself: every stage, every handover, every gate.
  • Concepts - the vocabulary the recipes are written in.