Confirm that the user explicitly asked for phase-gated multi-agent work. If not, do the task directly: the ceremony costs more than a single agent for small tasks. Map the host's features before promising parallelism (host capabilities).
Phase 1: write the requirements baseline, with IDs, acceptance conditions, and verification methods (requirements). Close its gate.
Phase 2: write the design baseline and the work plan, with owned paths and dependencies (design). Run python3 scripts/check_work_items.py PLAN.json until it passes. Close the gate.
Phase 3: spawn one wave at a time, with complete briefs (brief) in isolated worktrees (isolation). Accept a result only when it has evidence and stays in scope (results). Optionally, spawn one independent reviewer per unit (review).
Phase 4: cross-check each report against the others and against its diff (cross-check), then integrate in the planned order, partition failures by owner and cause, and fill in the verification matrix (verification).
Phase 5: prepare the release from the verified revision. Publish only with explicit approval (release).
At every gate, run python3 scripts/check_gate.py GATE.json, and keep the gate open until it passes (gates). Changes to a frozen baseline go through a change request that reopens every downstream gate (change).

Route the situation to a card

Situation	Card
Which host features exist	Host capabilities
Writing requirements	Phase 1
Breaking work into items	Phase 2, waves
Spawning workers	Brief, phase 3
Parallel edits	Worktree isolation
Worker says "done"	Result contract
Reviewing a unit	Independent review
Reports disagree, or a diff doesn't match	Cross-checking reports
Integration failures	Phase 4, failure diagnosis
May we move on?	Gate decision
Requirement or interface must change	Change request
Release	Phase 5

Rules

The user's goal and the frozen baselines control each assignment. A worker's proposal is evidence, not authority.
Parallel items must pass check_work_items.py: no shared owned paths, and no items from another phase.
Workers write only in their owned paths and their own worktree, and never run destructive git commands. The orchestrator integrates.
A gate closes only on passed evidence with commands. Keep failed, unavailable, and not-run evidence distinct.
Never weaken a check to make it pass.
Publishing, pushing, and deploying need explicit user approval.

scripts/check_work_items.py PLAN.json [--json] reports errors and parallel waves. It exits 0 when the plan is safe.
scripts/check_gate.py GATE.json exits 0 when the gate may close, and 1 with the reasons when it may not.
scripts/test_checks.py tests both checkers.
assets/examples/: a good and a conflicting work plan, a closing and an open gate record, and verify.sh.
Templates in assets/:
- requirements baseline;
- design baseline;
- work item;
- defect review;
- requirement verification;
- phase completion;
- baseline change request.

The gate record of each phase, and the check_gate.py output.
The work plan, and the check_work_items.py output with its waves.
For each worker: its brief, its result with commands, and an in-scope diff check.
The cross-check of reports against each other and against each worktree's diff, before integration.
Review findings with their dispositions, and the change requests with the gates they reopened.
The final verification matrix, and what stays unavailable or not run.

A gate cannot close without evidence that needs access or approval.
A change request alters the scope the user accepted.
The host cannot isolate parallel writers, and the work cannot be serialized within the time available.