Work

/flow-next:work inspects the spec’s full ready frontier on every loop. It may dispatch a safe subset concurrently when dependencies, mutable surfaces, host capacity, workspace isolation, and integration are sound; otherwise it explains the constraint and serializes. Every task still gets a fresh-context worker and the same review, evidence, and completion gates.

Worker subagent model

Each task runs in its own subagent. The benefits compound:

• Fresh context per task prevents bleed between unrelated changes.
• Re-anchor information stays bundled with its implementation.
• Review cycles stay isolated to the task they belong to.
• The main conversation stays lean even on long specs.

flowchart TB
  Main["Main session"] --> Pick["Inspect ready frontier"]
  Pick --> Spawn["Dispatch safe wave"]
  Spawn --> Anchor["Worker re-reads spec"]
  Anchor --> Impl["Implement + commit in isolated workspace"]
  Impl --> Join["Join + integrate whole wave"]
  Join --> Review["Optional per-task review gate"]
  Review --> Done["Mark task done"]
  Done --> Sync["Plan-sync after joined wave"]
  Sync --> Pick

The re-anchor is a single flowctl anchor <task-id> call: one deterministic bundle carrying the task, the parent spec, git state, memory and glossary indices, and dependency summaries — byte-equivalent to the discrete reads it replaced, so each worker starts in one round-trip instead of eight. The bundle is a floor, not a ceiling: the worker still reads anything else it needs.

Quick commands - what gets verified, and how often

The spec’s ## Quick commands block is what every worker runs: once before its first edit, to prove the tree was green before the change, and again before it may mark the task done. The conductor runs the full gates once per spec at the end.

The scaffold’s convention is that per-task commands name focused suites for the files that task touches, while the full suite runs once at that final gate. Repeats are cheap by construction: a green receipt keyed to the exact commit and the exact command string skips a re-run at unchanged HEAD, and a docs-only diff drops to lint and format only.

Which means the tier is yours to set. Author focused commands and keep the full-suite entrypoint as the final-gate command if you want narrow per-task runs; list the full suite if your project would rather pay it every task; put the policy in CLAUDE.md / AGENTS.md if it should hold across specs. Selection is authored, never computed - it keeps needless full runs out of the loop, but it will not infer which distant suite your change actually touches. See the verification spine.

Branch modes

Mode	Use
current	Stay on the active branch. Default for solo or small changes.
new	Create a fresh feature branch off the current base.
worktree	Fully isolated parallel work via flow-next-worktree-kit.

Worktree mode is the right choice when more than one spec is in flight, or when a review cycle on a separate branch must not disturb the work in progress.

Plan-sync after each joined wave

When planSync.enabled is true in .flow/flow.yml, downstream task specs are checked for stale references after a serial task or after the conductor has joined and resolved an entire parallel wave. This avoids syncing against a partial integration. If a task changed an API or path that later tasks assumed, the drift surfaces with a reason. The user decides whether to update the downstream specs, regenerate them, or accept the drift explicitly.

Plan-sync is conservative: it never silently rewrites a spec; it only proposes.

Quality audit (large or risky changes)

In the quality phase — after tasks complete, alongside the full gates — the conductor may dispatch the quality-auditor subagent over the spec’s whole diff. The trigger is a judgment call, not a flag: it runs when the conductor judges the change large or risky, and is skipped for small routine changes. It dispatches as two parallel axis-scoped runs (correctness and standards), both reports come back verbatim, and only correctness-axis Criticals block.

Completion review gate

When all tasks are done, an optional /flow-next:spec-completion-review runs to verify the combined implementation matches the spec end-to-end. This is the place to catch criteria that no individual task fully owned.

Optional review

/flow-next:work <spec-id> --review=codex

--review=codex|rp|copilot|none runs a per-task adversarial review. The worker loops fix → review until SHIP before marking the task done.

Implementation offload

Handing the token-heavy part — writing code — to a second CLI agent is a routing decision you write, not a subsystem you configure. Name an implementer tier in your CLAUDE.md / AGENTS.md routing block, or just say it in the moment; the host drives the other CLI through a headless bridge for the draft. With no implementer tier, the session model implements — that is the default and needs no configuration.

Two rules are not optional:

• The bridged child writes code; the host keeps git, judgment, and the verdict. The child never commits, never decides scope, never issues a review verdict, and never spawns a bridge of its own. Everything on this page — re-anchor, Quick commands, review, plan-sync, flowctl done — is unchanged and still host-owned.
• Send clear, well-scoped tasks to the value tier. On well-specified work a value tier matches a strong tier on correctness for meaningfully less wall clock; escalate to the strong tier only for genuinely gnarly ones. Spec quality is what makes the trade safe — a vague brief burns the saving on rework.

Bridge recipes ship into your repo and are read on demand with flowctl usage (## Orchestration & model steering). Full doctrine: Orchestration → Implementation offload.

Coming from delegate:codex?

The packaged delegation mode and its work.delegate* config keys were removed in 4.0.0. Leftover keys in .flow/config.json are inert - flowctl names them once in a non-blocking advisory and otherwise ignores them. Run /flow-next:setup, accept the routing-block scaffold, and use the bridge recipes above.

Worked example

/flow-next:work fn-12-export-json-flag

ready frontier: [.1, .2]
selected wave: [.1, .2] (disjoint files, isolated worktrees)
  .1 -> worker: commit a1b2c3d, tests green, handover returned
  .2 -> worker: commit e4f5a6b, tests green, handover returned
join: 2/2 workers complete; commits integrated
per-task review + completion: SHIP; evidence recorded
plan-sync: no downstream drift after joined wave
impl-review (cross-model): SHIP - receipt on disk
Spec fn-12-export-json-flag: all tasks done.

Fresh context per task plus mandatory evidence is what makes the loop repeatable instead of lucky.

Tips

• flowctl done refuses completion without evidence JSON - if a worker “finished” without commits and test commands, it did not finish.
• The planner reports execution waves. The work conductor chooses a safe subset, isolation, integration order, and worker count from the live ready frontier; it serializes when those conditions are not sound.
• Atomic claims prevent duplicate ownership. They do not make simultaneous edits to one Git index or filesystem safe.
• Use --branch=worktree to isolate a spec’s changes in .worktrees/<name>/ without touching your current branch.

Dynamic usage

Recipes that compose with work in the cookbook:

• Parallelize - both supported forms of task-level parallelism, with the guardrails that keep them safe.
• Model routing - an implementer tier hands implementation to a second CLI while the host keeps git, review, and judgment.
• Skip & lighten - plan + work alone is a complete, evidence-backed workflow for small changes.

Next step

/flow-next:make-pr <spec-id>