team

team differs from ralph: ralph is sequential single-track persistence with strong TDD-per-story discipline; team is parallel multi-track decomposition for tasks where multiple independent surfaces can be worked on at once.

<Use_When>

• The task naturally decomposes into ≥ 3 independent stories that can run in parallel (different files, no shared state, no ordering dependency).
• User says "/team", "team", "팀으로 진행", "parallel agents".
• A plan (.dt-handoff/<slug>/plan.md) explicitly identifies workstreams that can run concurrently.
• autopilot Phase 3 chooses team over ralph because the plan has high parallelism.
• A large refactor touches multiple modules, each handled independently. </Use_When>

<Do_Not_Use_When>

• The task has a strict sequential dependency chain (each story unblocks the next) — use ralph.
• The task is a single story or single bug fix — delegate to executor directly.
• The task is requirements capture (WHAT, not HOW) — clarify the requirements into a spec first; team executes a plan.
• The task is consensus planning — use ralplan.
• The user wants automatic commit/PR — refuse; team stops at "ready for commit".
• Total story count is ≥ 20 — split into multiple ralplan sessions first. </Do_Not_Use_When>

<Why_This_Exists> Tasks that decompose into independent surfaces waste wall-clock time when run sequentially. A 6-story refactor where each story touches a different module finishes in roughly the duration of the longest story, not the sum. The pipeline makes that parallelism explicit and safe by enforcing stage boundaries: every story is decomposed before any is implemented, every implementation is verified before any is shipped, and the verify→fix loop is bounded so it cannot grind forever.

Handoff documents between stages exist because lead context must transfer cleanly across phase boundaries; without them the lead re-derives decisions every stage or carries stale assumptions across phases. One short markdown file per stage keeps the lead honest and the trail auditable.

Stage-aware worker routing (planner decomposes, executor implements, test-engineer tests, architect reviews design, verifier gates completion, code-simplifier cleans up) avoids a one-size-fits-all worker that either over-skills cheap tasks or under-skills complex ones. A dedicated verifier gate removes self-approval: the agent that produced the work is never the one that confirms it is done. </Why_This_Exists>

<Execution_Policy> Output language: handoff docs, story descriptions, progress entries use $LANGUAGE. JSON field names stay English; field values use $LANGUAGE.

TDD Iron Law (non-negotiable): every story that adds production behavior MUST have a Red test authored by test-engineer BEFORE executor runs. The Red step is sequential within a story, even though stories run in parallel.

Parallel execution rules:

• Stages are sequential globally (plan → prd → exec → verify → fix loop). Within a story, Red → Green → Refactor is sequential.
• Stage 3 (team-exec): independent stories' Red/Green steps run in parallel — fire N Task calls in ONE message per batch, capped by --max-parallel. Within a wave, Red→Green is pipelined per story: each story's executor fires as soon as that story's test-engineer returns (Red still precedes Green within the story — the Iron Law holds; there is no cross-story barrier between Red and Green).
• Stage 4 verify: reviewer and critic run in parallel — the one documented exception to the "no parallel reviewers" rule, justified because they review the same final artifact independently at partitioned altitudes (reviewer owns code-level findings; critic owns spec-level gaps — not a second full code review) and it saves wall-clock. --no-critic skips critic.
• verifier runs once per stage, NOT per wave: one call after all Stage 3 waves, one call after each Stage 5 fix round.