Execution & Review

The scouts only read. These four subagents are the ones that change code, keep the plan honest, and guard quality. They are spawned by /flow-next:work, /flow-next:sync, and /flow-next:resolve-pr. worker and pr-comment-resolver may dispatch subagents of their own: research and scouting for both, parallel implementation for the worker, every one joined before the change is committed. plan-sync (no Write, no Task) and read-only quality-auditor (no Edit, Write or Task) cannot: an agent that can spawn a writing subagent is no longer read-only. The orchestrating skill still owns git, the review gates, and the loop.

The Reasoning tier and Inherits below are platform-neutral - they map to a concrete model per runtime (see the model-tier note on the overview).

worker

Spawned by /flow-next:work when a spec has several tasks, or when a task goes to a chosen model or tier. Inherits the caller’s model.

A single-task spec is built inline in the conversation, with no worker. When there are several tasks, work spawns a fresh worker per task so context never bleeds between unrelated changes (rolling scheduling by default, waves as the fallback). The worker:

1. Re-anchors - re-reads the task spec, the parent spec, git state, and relevant memory. This step is mandatory and never skipped.
2. Implements and commits the task.
3. Reviews by risk - when a review backend is set and the risk rule selects the change, it runs impl-review until SHIP (or a recorded override); a change the rule does not select skips review with the reason recorded. Under parallel scheduling the conductor owns the review instead.
4. Marks the task done with a summary and evidence.

flowchart TB
  Work["/flow-next:work"] --> Pick["Pick next ready task"]
  Pick --> Spawn["Spawn worker (fresh context)"]
  Spawn --> Anchor["Re-anchor on spec + git + memory"]
  Anchor --> Impl["Implement + commit"]
  Impl --> Review["Optional review loop"]
  Review --> Done["Mark task done"]
  Done --> Sync["plan-sync downstream (opt-in)"]
  Sync --> Pick

Naming an implementer tier keeps the worker as orchestrator - re-anchor, review, all git, and decisions - while the token-heavy code-writing goes out to a second CLI agent over a headless bridge. The bridged child writes code and nothing else. With no implementer tier the worker implements on the session model, which is the default. See Implementation offload.

plan-sync

Spawned by /flow-next:sync on demand, and by /flow-next:work per wave when planSync.enabled is on (off by default). Reasoning tier.

When a task changes an API or a path that a later task assumed, the downstream specs are now subtly wrong. plan-sync re-anchors on what the completed task actually did, checks the remaining tasks for stale references, and proposes updates. It is conservative by design: it never silently rewrites a spec - it surfaces the drift with a reason and lets you decide. It also reads the glossary, recorded decisions, and STRATEGY.md so its proposals stay consistent with the project’s direction.

quality-auditor

Spawned by /flow-next:work in its quality phase when the conductor judges the change large or risky - a judgment call, not a config flag - twice, once per axis. Reasoning tier.

A pragmatic, adversarial code auditor invoked after implementation and before shipping. It pulls the diff and hunts for real risk, fast. Since 3.21.0 the audit runs as two axis-scoped dispatches in parallel, each answering exactly one question:

• AXIS: correctness - does the code do what the spec said? Spec conformance, misread requirements, silent regressions, weakened assertions, leaked secrets and debug code, correctness slips (off-by-one, inverted conditions, unawaited promises), injection and other security vectors, gaps in test coverage.
• AXIS: standards - is this code you’d want to keep? Simplicity, duplication, dead code, over-engineering, naming, vocabulary, performance shape.

Both reports come back verbatim under their own headings - never merged, reranked, or summarized into one list. Severity has an owner: only the correctness axis can raise a Critical finding or call the change shippable; the standards axis is capped at Should-Fix by construction, and hands any outage-grade suspicion across as a short untiered note for the correctness axis to judge. A dispatch missing its axis line defaults visibly to correctness. The auditor flags; it does not fix - the findings go back to the worker loop.

pr-comment-resolver

Spawned by /flow-next:resolve-pr, once per review thread or cluster. Inherits the caller’s model.

Takes a single PR review thread, reads enough surrounding code to understand it (never just the cited line), and decides whether the feedback is valid. When it is, the resolver implements the fix; when it is not, it drafts a reply explaining why. Either way it returns a structured verdict. It never commits or pushes - the orchestrating resolve-pr skill owns git and the GraphQL reply/resolve, bounded at two fix-verify cycles before escalation.

flowchart LR
  Resolve["/flow-next:resolve-pr"] --> Fetch["Fetch unresolved threads"]
  Fetch --> Spawn["Spawn pr-comment-resolver per thread"]
  Spawn --> Verdict["Fix or reply → structured verdict"]
  Verdict --> Commit["Skill commits + replies + resolves"]

Note

worker and pr-comment-resolver are the only subagents in flow-next that write code in your working tree (plan-sync edits task specs only). Any subagent they dispatch is joined before the change is committed, and the orchestrating skill keeps git and the review gates.