Menu, Not a Rail

The most common misreading of Flow-Next, straight from real coaching sessions, goes like this: “Flow-Next is a rigid conveyor. Interview, spec, plan, work, review, PR - every time, in order, no exceptions.”

That reading is wrong, and this page exists to kill it.

The default pipeline is a menu, not a rail. The stages are opinionated defaults that produce a predictable, high-quality result when you follow them blind - that is what makes Flow-Next safe to hand to a newcomer or an autonomous loop. But every stage is a composable primitive. You can skip stages, reorder them, prompt into any of them, one-shot chain the whole pipeline in a single message, parallelize disjoint tasks, and route a different model to every step. Both routes - the rails and the shortcuts - keep the same execution, evidence, and review contracts.

The doctrine

Four lines carry the whole idea. They come from field coaching, and they are the canonical answers to the rigid-conveyor misreading:

“The default stages are rails, not a prohibition on exploration.” The pipeline is there so you never have to think about process. It was never there to stop you from thinking.

“The spec is the ratchet and the handover object - not the permission to explore.” You do not need a spec’s blessing to read code, prototype, or research. The spec exists to lock in what you learned so the next stage (or the next person, or the next agent) cannot silently lose it.

“The primitives are composable. Both routes retain the same execution, evidence, and review contracts.” A skipped interview does not skip evidence. A one-shot chain does not skip review. 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, not to a ritual.

The tunable baseline

Flow-Next runs the same pipeline the same way every time: capture, interview, spec, plan, plan review, work, QA, review, PR. That reproducibility is the point when you are getting started. Follow the baseline and you get a predictable, high-quality result without memorising the steps.

The baseline is not static. You steer Flow-Next in plain language, so you can tune a run as you go: point it at a specific spec, reshape a plan, pick a different model for a stage, or adapt to a brownfield codebase instead of a greenfield one. Nothing is locked.

The determinism is the floor; your prompting is the ceiling. Flow-Next is neither a black box nor freeform vibe-coding. It is a tunable baseline: reproducible by default, steerable when you need it.

What holds on every route

Flexibility is cheap to claim and expensive to make safe. What makes the menu safe is that the contracts do not bend when the route does:

• 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.
• Evidence contract - a task is only done when flowctl done receives a summary and evidence JSON (commits, tests, PRs). There is no fast route around it, because the fast routes go through it.
• Review contract - whatever review you configured (cross-model backend, per-task pin, or a conscious --review=none) applies identically on every route. Skipping review is a visible decision, never a side effect of moving fast.

This is why the shortcuts are marketable at all: the pipeline’s guarantees live in the contracts, not in the ceremony.

Nothing to memorize

Steering is not a syntax you have to learn. Every skill runs from plain language, and every flag has a plain-language 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; describing what you want is the everyday one. The menu below is a menu of intentions, not commands to recite.

The moves

The Cookbook collects the verified recipes - each one a real scenario, the exact invocation, and one line on why the gates still hold. They organize into these moves:

Move	The idea
Say it in plain language	No slash command or flag required - describe what you want; the host maps it onto the skill.
Skip & lighten	Drop stages the change does not need; the contracts stay.
Prompt into a stage	Every skill takes plain-language steering next to its arguments.
One-shot chains	Chain the pipeline in a single message; each stage still fires its gates.
Evidence-first	Put proof at the center: your research, your tests, live-app verdicts.
Model routing	Route reviewers, workers, and delegates per step - parameter or sentence.
Parallelize	Disjoint tasks in parallel: multiple sessions or one prompted dispatch.
Autonomy dial	One dial from interactive to Ralph; gates fire identically at every rung.
Integration tricks	Trackers, feature maps, readiness checks, external reviewers.
Team patterns	Specs as PRs, atomic claims, handover breadcrumbs.
Compose beyond the pipeline	Research, test, or eval first - then let the result write the spec.
Frontier moves	N-model review juries, best-of-N implementations, reproduction-driven specs, memory mining, harness-hopping.

A taste of the register:

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 →

Where to go next

• Cookbook - the full recipe collection, copy-paste ready.
• Orchestration & Model Routing - the routing half of the menu: tiers, backends, bridges, and the “parameters set the floor, prompting steers above it” doctrine.
• The Pipeline - the rails themselves: every stage, every handover, every gate.
• Core Concepts - the vocabulary the recipes are written in.