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.

Each route uses the same execution discipline, records task evidence, and applies the review policy you chose. The record shows which route ran and what it checked.

You rarely compose by hand. /flow-next:flow picks the route in seconds and adds a stage only where the risk calls for it. The work itself comes back in about the time plain Claude Code, or your harness, takes, often less, across more than 170 full end-to-end runs. The result is better than the plain agent’s even before any review; the optional stages (cross-model review, live QA) widen the gap to up to 25% better outcomes, especially on large and long-horizon work.

What holds on every route

• The execution contract. Work follows the same discipline (re-anchor on the spec, implement, commit, verify) whether you stepped through five stages or chained them in one message. A single-task spec is built inline in the conversation; workers take over when there are several tasks or you send a task to a chosen model.
• The evidence contract. The work and review contracts require the implementation commits and the test evidence before a task closes, with PR links added when they exist. flowctl done records the summary and evidence JSON it receives. The fast routes go through that record 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 the same way on every route, by risk: three reviewers from another family for persisted or shared state, concurrency, security, data layout or migrations, and multi-file features; one otherwise. A small output, wording, or display fix is not reviewed, and the skip is recorded with its reason, so the record shows what ran and why.
• The route is reproducible. Code decides a live spec’s lifecycle from its recorded state, and the host decides the rest from the shared route matrix, so an attended and an unattended run take the same route. Routing never asks the optional Jev judge, so a run with a TypeSafe key and one without take the same route too. See Optional Jev judgments.

Use those records to inspect a short run or a larger chain.

Start from the baseline, then tune it

A small local change goes direct: changed, checked, and handed back with no spec, and a PR only if you ask. Every larger route keeps a strong spec, review by risk, verification, evidence, and a reviewable PR. For a ready spec with no tasks, direct execution through /flow-next:work <spec-id> --no-plan is the default. Plan is chosen only on a positive signal: you asked for a plan, separate human owners will implement, or delivery is staged across several PRs. Risk, size, and file count never trigger plan on their own. Design risk routes to /flow-next:plan-review, which reviews a zero-task spec; unresolved product or authority choices route to /flow-next:refine (interview).

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 refine pass still produces evidence. A one-shot chain still gets reviewed. The work and review contracts require evidence on the fastest route exactly as on the slowest, and flowctl done records it.
• 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:flow --explain prints that route and its reason without writing anything; plain /flow-next:flow runs it and stops at the next decision that is yours. Optional /flow-next:chart is discovery for one oversized unclear idea before capture.

Nothing to memorize

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 moves, in one place

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:flow fix the typo in the export help text ⧉

✓ A small local change goes direct: no spec, checked, handed back. A small wording or display fix is not reviewed, and the skip is recorded.

All skip recipes →

If someone told you it was a conveyor belt

Choose the route from the work and the agent available, then keep the configured contracts. Explicit no-plan consent changes task decomposition; it does not change review or QA defaults.

Where to go next

• How Flow chooses - fifteen request shapes this doctrine produces, from full epic to docs chore, each with the signal that selects it.
• Flow and the road ahead - why the routing lives in one reference, and how one driver serves attended and unattended work.
• 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.