- name
- team
- description
- Spin up a native Claude Code Teams fleet to tackle a multi-step task — lead orchestrates, specialists work in parallel worktrees, critic + verifier loop guards quality. Use when the task has 3+ independent sub-tasks, when you need different specialists, or when isolation between concerns is required. Triggers on /team, "spin up a team", "fan out", "fleet this".
- when_to_use
- Use for tasks with 3+ independent units of work that benefit from specialization. Do NOT use for trivial single-file fixes or tasks with heavy shared state — sequential is faster.
- allowed-tools
- Agent, Task, TodoWrite, Bash, Read, Write, Edit, Glob, Grep, Skill
- arguments
- ["goal"]
# /team — Native Claude Code Teams Orchestrator
`/team <goal>` runs the closed-loop multi-agent protocol from `~/.claude/rules/agent-team-os.md` end-to-end with native primitives. Replaces Shipwright; depends only on the Claude Code harness.
## The protocol you run
```
1. SCOPE — distill goal into 3–8 testable contracts (with user)
2. PLAN — write the plan; identify which contracts are independent (parallel) vs sequential
3. SPAWN — Agent tool with isolation: worktree, model: sonnet, tools scoped to role
4. WATCH — TodoWrite tracks tasks; agents report back via TaskUpdate
5. VERIFY — for each task close, spawn verifier (model: sonnet)
6. CRITIQUE — every N completions, spawn critic to find half-fixes & cross-agent regressions
7. REFLEX — recurring failures from same agent → spawn agent-tuner with /tune-agent
8. MERGE — git diff each worktree, merge sequentially with tests between, surface conflicts
9. CLOSE — write closing report + update knowledge + run /mine-transcripts on this session
```
## Hard rules
- **Never** call `TeamDelete`, `git worktree remove`, or `ExitWorktree` until **after** all branches are merged. See `rules/worktree-merge-before-cleanup.md`.
- **Never** mark a task complete without `RESULT_verifier=PASS`.
- **Never** skip the critic on the closure of CRITICAL or REGRESSION-tagged tasks.
- **Always** keep the active task list in `TodoWrite` — every spawn updates it.
- **Always** report cost+token totals in the closing summary. If the run cost >$10, flag it.
## Step-by-step
### Step 1 — Scope (with user)
- Distill the goal into 3–8 testable contracts. Each contract is one sentence: "X must do Y when Z."
- If you can't list ≥3 contracts, the goal is too small for /team — just do it.
- Confirm with the user before spawning anyone.
### Step 2 — Plan
- Group contracts into independent vs sequential clusters.
- For each cluster, decide: which specialist(s) handle this?
- General task → `general-purpose`
- Migration → `migration-planner`
- Bug regression → `regression-hunter`
- Perf → `latency-profiler`
- Security → `security-reviewer`
- (See `~/.claude/agents/` for the full roster — match agent description to task.)
- Write the plan inline in this conversation. Don't burn context with a separate plan file unless the user wants one.
### Step 3 — Spawn
For each independent unit:
```
Agent({
description: "<short description>",
subagent_type: "general-purpose", // or specialist
isolation: "worktree", // ALWAYS for implementation tasks
prompt: "..." // include: contract, file paths, no-go zones, when to /verify
})
```
For parallel dispatch: emit multiple `Agent` calls in a SINGLE message. Don't sequentially await unless there's a real dependency.
### Step 4 — Watch
- `TodoWrite` immediately after spawn: each task in_progress
- When an agent reports back, mark its task completed (after verify passes)
- If the user asks for a status, just `TodoWrite` view + a 2-line summary
### Step 5 — Verify (per task close)
- Spawn `/verify` (which spawns the `verifier` agent)
- Read `RESULT_verifier=...`
- PASS → `TodoWrite` mark complete
- FAIL → keep task open, surface the failure, prompt the responsible agent to fix
- INCONCLUSIVE → escalate to user; do not silently pass
### Step 6 — Critique (every 3 completions, or at fleet end)
- Spawn the `critic` agent (read-only) with the list of just-completed tasks
- Critic returns CRITICAL / HIGH / MED findings; CRITICAL ones become new tasks (CRITIC- prefix)
- Critic also checks for cross-agent regressions: did Agent A's change break Agent B's work?
### Step 7 — Reflexion (only if pattern emerges)
- If verifier or critic finds the SAME failure mode from the SAME agent twice, that's a tuning candidate
- Spawn `/tune-agent <agent-name>` with the failure evidence
- It proposes a prompt patch; you (lead) approve or reject
- Approved patches land in the agent's `.md` with backup at `~/.claude/agents/.history/`
### Step 8 — Merge
- `git worktree list` shows all branches
- For each: `git diff <main>..<branch>`, then merge
- After every merge, run the project's test suite — surface failures immediately
- DO NOT remove worktrees until all merges complete
### Step 9 — Close
- Write a closing report to the conversation:
- Goal recap, contracts satisfied (link to evidence)
- Tasks: completed / deferred (with reason)
- Critic findings: addressed / accepted as known issues
- Cost / tokens / wall time
- Lessons learned (auto-extracted from this session)
- Run `/mine-transcripts --since 1h` to capture this fleet's lessons
- Update `~/.claude/knowledge/connections/` if a new architectural insight emerged
## Output discipline
- Status updates: 2 lines max per teammate update — don't paste their work back to the user
- Use `TodoWrite` as the source of truth, not chat narration
- Closing report under 500 words
## Common failure modes you must avoid
1. **Spawning a fleet for a 1-hour task** — overhead exceeds value
2. **Spawning agents without contracts** — they thrash because they can't tell when they're done
3. **Skipping verifier because "it obviously works"** — that exact phrase has cost users tens of hours
4. **Removing worktrees before merge** — destroys all the agent's work
5. **Critic running on unrelated work** — scope the critic to just-closed tasks
6. **Letting the critic loop run forever** — cap at 3 critic passes; remaining findings become explicit deferred tasks
View on GitHub