菜单
Execute implementation plans in parallel using agent teams with quality gates. Spawns implementer teammates in split panes, orchestrated by a team lead who enforces spec compliance and code quality reviews.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when you have an approved design or requirements for a multi-step task, before touching code. Turns designs into implementation plans with bite-sized TDD-oriented tasks, exact file paths, and verification steps. Save to docs/plans/.
Use when starting development work on a bug, feature, improvement, or task. Guides engineers through the full development pipeline: discover, brainstorm, plan, execute, review, ship. Invoked by "let's work on", "I need to build", "fix this bug", "start a new task", or /kickoff.
Use when exploring ideas, comparing approaches, or refining an unclear problem — at any point in the workflow. A discovery-time tool, not a pipeline stage. Invokable directly via /brainstorm or offered by kickoff during DISCOVER. Produces understanding, not artifacts.
Use when you have an implementation plan and want to execute it. Analyzes the plan's task graph, determines the best execution strategy (parallel via team-dev or serial via sdd), and orchestrates the full build with quality gates. The single entry point for plan execution — you don't need to choose between team-dev and sdd yourself.
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes. Enforces root cause investigation through four phases: investigation, pattern analysis, hypothesis testing, and implementation. Prevents guess-and-check thrashing.
Use when creating new skills, specialists, agents, or packs for the Jig framework. Guides the user through an interview to determine what to build, scaffolds the artifact with valid frontmatter, checks for overlap with existing artifacts, and verifies it loads correctly. Triggered by "create a skill", "add a specialist", "extend the framework", or /extend.
| name | team-dev |
| description | Execute implementation plans in parallel using agent teams with quality gates. Spawns implementer teammates in split panes, orchestrated by a team lead who enforces spec compliance and code quality reviews. |
| tier | workflow |
| alwaysApply | false |
Execute implementation plans by spawning implementer teammates that work in parallel, each in their own split pane. The team lead orchestrates a staggered review pipeline — as each implementer finishes, the lead dispatches spec compliance and code quality reviewer subagents. Quality gates are enforced: no task is complete until both reviews pass.
Core principle: Parallel implementation via agent teams + two-stage review gates = fast iteration with high quality.
flowchart TD
A{Have implementation<br/>plan?} -->|No| B[Use prd +<br/>plan first]
A -->|Yes| C{3+ independent<br/>tasks?}
C -->|No| D[Use sdd<br/>sequential]
C -->|Yes| E{Tasks touch mostly<br/>different files?}
E -->|No| F[Use sdd<br/>sequential]
E -->|Yes| G{Agent teams<br/>enabled?}
G -->|No| H[Enable agent teams<br/>or use sdd]
G -->|Yes| I[team-dev]
style I fill:#e8f5e9
| sdd | Parallel Agents | team-dev | |
|---|---|---|---|
| Execution | Sequential, one task at a time | Parallel, fire-and-forget | Parallel, staggered pipeline |
| Quality Gates | Spec + quality review | None | Spec + quality review |
| Visibility | Single session | Background subagents | Split panes, interactive |
| Feedback Loop | Synchronous within session | None | Bidirectional via SendMessage |
| Best For | Sequential or coupled tasks | Quick parallel research | Independent tasks with quality needs |
| Token Cost | Lowest | Medium | Highest (persistent sessions) |
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS: "1" in settingsteammateMode: "tmux" in ~/.claude/settings.json (recommended for split panes)tmux -CC in iTerm2 or tmux new -s claude then claudeplan)1. Enable agent teams — add to your project's .claude/settings.json:
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
2. Enable tmux teammate mode — add to your user settings at ~/.claude/settings.json:
{
"teammateMode": "tmux"
}
3. Launch Claude inside tmux:
# iTerm2 (recommended — gives you native iTerm2 tabs/panes)
tmux -CC
# Standard terminal
tmux new -s claude
Then run claude from inside the tmux session. Teammates appear as split panes automatically.
4. Have an implementation plan — use plan to generate one, or write one manually.
flowchart TD
read[1. Read plan<br/>Analyze dependencies + file overlap] --> count[2. Determine implementer count<br/>Bias toward 3]
count --> create[3. TeamCreate + TaskCreate<br/>Set blockedBy relationships]
create --> spawn[4. Spawn implementer teammates<br/>One per initial parallel task]
spawn --> work[Implementer works<br/>Implement, test, self-review]
work --> done[Implementer reports done]
done --> spec[Lead dispatches<br/>spec reviewer subagent]
spec --> spec_pass{Spec passes?}
spec_pass -->|No| spec_fix[Send feedback<br/>Implementer fixes] -.-> spec
spec_pass -->|Yes| quality[Lead dispatches<br/>swarm review - fast-pass]
quality --> qual_pass{Quality passes?}
qual_pass -->|No| qual_fix[Send feedback<br/>Implementer fixes] -.-> quality
qual_pass -->|Yes| complete[Task complete]
complete --> more{More unblocked tasks?}
more -->|Yes| related{Related to<br/>implementer's work?}
more -->|No| shutdown[Shut down implementer]
related -->|Yes| reuse[Reuse implementer<br/>Send next task] --> work
related -->|No| fresh[Shut down + spawn fresh] --> work
shutdown -.->|when all done| all_done[All tasks complete]
all_done --> integration[Final integration review]
integration --> cleanup[Shutdown teammates<br/>TeamDelete]
cleanup --> finish[finish]
| Template | Purpose | Invocation |
|---|---|---|
./implementer-prompt.md | Spawn an implementer teammate | Task tool with team_name |
./spec-reviewer-prompt.md | Dispatch spec compliance reviewer | Subagent (not teammate) |
review skill | Dispatch swarm quality review (fast-pass tier) | Subagent via skill pipeline |
./lead-playbook.md | Lead's orchestration decision logic | Reference for the lead |
Reviews happen as implementers finish — no waiting for all to complete. Multiple reviews can run in parallel since they are read-only.
An implementer does NOT start their next task until both reviews pass on their current task. This prevents messy context switches when review feedback arrives.
Reviewers are subagents (not teammates). They report to the lead, who decides next steps. This keeps the lead as the single quality gatekeeper.
| Independent Task Count | Recommended Implementers |
|---|---|
| 2 | 2 |
| 3-4 | 3 |
| 5-6 | 4-5 |
| 7+ | 5-6 (cap at 6) |
Bias toward 3. Scale up when tasks are truly independent. Scale down when overlap is high.
The lead groups tasks by file surface area before spawning. Tasks touching the same files never run in parallel — they use blockedBy dependencies instead.
Never:
If implementer asks questions:
If reviewer finds issues:
If implementer gets stuck:
Required workflow (in order):
Used during orchestration:
Implementer teammates use:
Alternative workflows:
| Situation | Use Instead |
|---|---|
| Fewer than 3 independent tasks | sdd |
| Tasks share many files | sdd |
| Agent teams not enabled | sdd |