task

Run the single-task implementation pipeline (no planning phase). If no task is provided, ask first. Load agent files on demand — never pre-load all at once; use references/output-format.md headers and show a Pipeline Summary after each Verdict.

Full sub-task loop detail: references/loop.md.

Contract

• Input: a single coding task (tech stack derived from the existing codebase if present).
• Output: implemented, tested sub-tasks, each with a Verdict, its own reviewed PR into release/{slug}-{key}, and a [{key}]-prefixed PROGRESS.md entry at repo root; then a PR from release/{slug}-{key} to main, reviewed by /pr-review with its findings posted.
• Boundary: no full planning phase — starts at Architecture; per sub-task max ~200 lines with a clear interface boundary, split if not independently testable.
• Rules: Coder owns tests + implementation, written against the frozen Test Case table and falsified before handoff; story ACs + that table are the frozen acceptance contract; Reviewer and StressTester run only after QA approval or escalation; unmitigated CRITICAL security is automatic NOT READY.

Model assignment

Dispatch the Architect on opus; Scrum Master, Plan Reviewer, QA, Reviewer, Stress, Verdict, and the orchestrator on sonnet; the Coder (core + backend/frontend overlay), Tuner, DevOps, and any read-side Explore/mapping sub-agent on haiku (see CLAUDE.md Model assignment table).

Steps

1. Delivery setup (once) — derive the slug + key from the task name, create .worktrees/dlv-{key}/ on branch release/{slug}-{key}, and run everything inside it, per ../../references/delivery-and-worktree.md. An existing worktree for the key means resume, not recreate. Never commit or merge to main — the terminal step is a PR from the release branch.
2. Planning (once) — follow skills/planning/SKILL.md from Phase 0.5 (Codebase Discovery), then Architecture, then the Phase 2.5 plan review — Priya must return PLAN APPROVED (or her leftover findings must reach the human) before any code; run the Backend-Driven Architecture tier check; produce and confirm a Task Manifest (sizing rules and tier check detail in references/loop.md). If the session is not the orchestrator (prompt does not open with "You are the delivery orchestrator") and the manifest has ≥ 2 sub-tasks or the codebase map shows a wide blast radius, print once, then continue (never stop): "Exit, then run: claude --agent orchestrator, and inside it: /task {args}". A narrow single-sub-task change prints nothing.
3. Execution options — planning's own step 8 runs the checkpoint (bench-context.py --manifest): dispatch counts and a token range for as-planned / all-standard / legacy-full-loop. Do not enter the sub-task loop until the operator has picked or edited the manifest's rosters.
4. Sub-task loop — repeat per sub-task, one at a time (sub-tasks share the delivery worktree, so never dispatch two Coders concurrently), roster-driven: each sub-task's manifest Roster decides which of A story (ScrumMaster, only when the manifest has ≥ 2 rows) → B code on feat/{key}-{story-slug} cut from the release branch — implement to spec, write the specified tests, falsify each (Coder + one tier overlay) → C QA audit + gates → D review (Reviewer folds in the Stress lens on light/standard; StressTester dispatched separately only for roster full) → E verdict → F story PR into release/* as a draft, reviewed inline by step D's Reviewer — no story-level /pr-review — merge --no-ff once no findings remain, then checkpoint + PROGRESS.md. Exact dispatch, routing signals, Bug-Fix Loop, Tuner limits, checkpoint table, and context budget are in references/loop.md.
5. Finish — when a sub-task is PRODUCTION READY, load agents/devops.md for Docker/CI artifacts; otherwise continue to the next sub-task. When all sub-tasks are done, push the release branch (ask first) and open a PR to main.
6. Delivery PR review — run /pr-review on the release PR with the delivery file, Reuse Map, Blast Radius, and manifest in context. Each sub-task was already reviewed on its own story PR; this second pass has a different job, because no story review saw the delivery as one diff, so cross-sub-task duplication and plan drift are only visible here. It posts inline comments and prints the Gaps block (unimplemented ACs · spec drift · missing Test Case rows · duplication %). Then print the final summary. Never merge — the PR stays open for the human.