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. None of them can spawn further agents — Task is disallowed on all four — so the orchestrating skill always stays in control of 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
Section titled “worker”Spawned by /flow-next:work, once per task. Inherits the caller’s model.
The heart of execution. For each ready task, work spawns a fresh worker so context never bleeds between unrelated changes. The worker:
- Re-anchors — re-reads the task spec, the parent spec, git state, and relevant memory. This step is mandatory and never skipped.
- Implements and commits the task.
- Optionally self-reviews — when
--review=codex|rp|copilotis set, it loops fix → review until the change ships. - 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"] Sync --> Pick
The opt-in delegate:codex mode keeps the worker as orchestrator — re-anchor, review, all git, and decisions — while offloading the token-heavy code-writing to a separate codex exec budget, with reasoning effort auto-escalated per batch by risk. See Codex delegation on the Work page for the full mechanics.
plan-sync
Section titled “plan-sync”Spawned by /flow-next:work after each task, and by /flow-next:sync on demand. 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
Section titled “quality-auditor”Spawned by /flow-next:work as an optional gate. Reasoning tier.
A pragmatic, adversarial code auditor invoked after implementation and before shipping. It pulls the diff and hunts for real risk, fast: leaked secrets and debug code, correctness slips (off-by-one, inverted conditions, unawaited promises), injection and other security vectors, and gaps in test coverage. It flags; it does not fix — the findings go back to the worker loop.
pr-comment-resolver
Section titled “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"]
Next step
Section titled “Next step”/flow-next:make-pr <spec-id>