Orchestrate parallel multi-session collaboration with independent Claude Code teammates. CK-native (v2.1.0) engine that spawns independent Claude Code sessions as teammates — each with own context window, task ownership, and persistent cross-session memory. Use when 3+ independent workstreams must run in parallel, workers need to discuss findings, competing hypotheses need evaluation, or multi-layer work (API + UI + DB) benefits from per-layer ownership.
$npx -y skills add trungdo9/ClauKit --skill team --agent claude-code
Installs into .claude/skills of the current project.
Are you the author of Team?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/trungdo9-team)
---
name: team
description: Orchestrate parallel multi-session collaboration with independent Claude Code teammates. CK-native (v2.1.0) engine that spawns independent Claude Code sessions as teammates — each with own context window, task ownership, and persistent cross-session memory. Use when 3+ independent workstreams must run in parallel, workers need to discuss findings, competing hypotheses need evaluation, or multi-layer work (API + UI + DB) benefits from per-layer ownership.
category: Orchestration
status: active
---
# Team
CK-native (v2.1.0) orchestration engine that spawns independent Claude Code sessions as teammates — each with their own context window, task ownership, and cross-session memory.
## What This Skill Does
Agent Teams let you run multiple Claude Code instances in parallel — each tackling a different workstream simultaneously. Teammates share a task list and communicate via messaging. Unlike subagents (fire-and-forget), teammates are persistent, event-driven, and able to discuss.
Templates auto-execute on spawn (changed in v2.1.0 — was manual in v1.x).
Distinct from:
- Subagents (e.g. via Agent tool) — short-lived, isolated context, fire-and-forget, no inter-worker communication.
- `[[cook]]` — single-feature gated pipeline; use `cook` template here only when 3+ features run in parallel.
## When to Use
- 3+ independent workstreams that can progress in parallel (e.g. auth + notifications + dashboard).
- Workers must discuss findings or hand off context mid-flight.
- Competing hypotheses need to be evaluated head-to-head (debug template).
- Long-running review where reviewers benefit from staying loaded with the diff.
- Token budget allows separate context windows per teammate.
**Avoid when:** task is single-focused, a short sequential chain (A → B → C), or token budget is tight — use a subagent instead.
Activation phrases: *"spin up a team to..."*, *"run these workstreams in parallel"*, *"competing investigators on..."*
## Templates
| Template | Teammates | Best For | Token Budget |
|----------|-----------|----------|--------------|
| `research` | 2-4 researchers | Competitive analysis, multi-source investigation | 150-300K (haiku) |
| `cook` | 1 lead + N devs | Parallel feature implementation | 400-800K (sonnet+haiku) |
| `review` | 2-3 reviewers | Code quality, security, performance audits | 100-200K (haiku) |
| `debug` | 3 debuggers (default) | Root-cause analysis via competing hypotheses | 200-400K (sonnet) |
## How to Use
```
/ck:team <template> <context> [flags]
```
**Flags:**
- `--devs N` — number of developer teammates
- `--researchers N` — number of researcher teammates
- `--reviewers N` — number of reviewer teammates
- `--debuggers N` — number of debugger teammates
- `--plan-approval` — require lead approval before implementation starts
- `--delegate` — lead coordinates only, never touches code directly
**Examples:**
- `/ck:team cook "implement auth + notifications + dashboard" --devs 3`
- `/ck:team research "compare React state management options" --researchers 2`
- `/ck:team review --reviewers 2`
- `/ck:team debug "race condition in payment flow" --plan-approval`
## Shared-Tree Protocol (canonical)
Teammates editing the same working tree is the **#1 lost-work shape** in the source data. ClauKit does not hand each teammate its own worktree — that was tried and retired (auto-provisioning fired on nearly every run, each tree paid a full dependency install, and stale trees accumulated). The replacement is **partition, don't isolate**:
1. **Declare disjoint path sets before dispatch.** Each editing teammate owns a set of paths no other editing teammate may touch. Record the partition in `plans/<plan>/STATE.md` so a resume re-establishes it.
2. **Overlap ⇒ serialize.** Two teammates whose sets would intersect run one after the other, not in parallel. Parallelism is the thing you give up, not correctness.
3. **`node .claude/hooks/file-claims.cjs list` is the live check.** A `FOREIGN` claim inside your partition means the partition is already violated: stop and re-partition, never push through.
4. **Read-only teammates are exempt.** Research and review teammates share the tree freely — they claim nothing.
Because each editing teammate stages only its own paths, `guard-destructive` Tier B stays quiet; a Tier B denial during a team run is a signal the partition leaked, not a nuisance to override.
## Requirements
Agent Teams must be enabled in your Claude Code environment:
```bash
# Claude Code < 2.1.33 (use env var)
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 claude
# Claude Code >= 2.1.33 (enabled by default)
```
## Event-Driven Monitoring
Teams emit hooks you can observe:
| Event | When | Use For |
|-------|------|---------|
| `TaskCompleted` | Teammate finishes a task | Track progress, trigger dependents |
| `TeammateIdle` | Teammate has no pending tasks | Reassign work, wind down |
## Agent Memory
Teammates persist knowledge across sessions via `.claude/agent-memory/<name>/`. Each teammate maintains:
- Prior context and findings
- Decisions made
- Files owned
Memory is scoped per teammate — not shared between teammates unless handed off explicitly via messaging or task update.
## Team vs Subagents
| Situation | Agent Teams | Subagents |
|-----------|:-----------:|:---------:|
| 3+ independent parallel workstreams | Yes | No |
| Workers need to discuss findings | Yes | No |
| Competing hypotheses to evaluate | Yes | No |
| Multi-layer work (API + UI + DB) | Yes | Yes |
| Single focused task | No | Yes |
| Sequential chain (A then B then C) | No | Yes |
| Limited token budget | No | Yes |
## Display Modes
Teams render based on your terminal:
- **auto** — detects best mode for your environment
- **in-process** — inline output (navigate with Shift+Up/Down)
- **tmux** — split-pane view per teammate
- **split** — separate terminal windows
## Failure Recovery
If a teammate crashes or goes idle unexpectedly:
1. Inspect `TaskList` for orphaned in-progress tasks.
2. Reassign via `TaskUpdate` to another teammate or self.
3. Teammate agent memory preserves context for handoff.
4. If repeated crashes, halt the team and run `[[retro]]` on the spawn config.
## Anti-Patterns
- **Team-for-everything**: spawning a 4-teammate review for a 20-line diff. Use a single reviewer subagent instead.
- **No ownership**: teammates picking tasks ad-hoc with no file-ownership boundaries → merge conflicts. Define owners up front.
- **Silent handoffs**: passing work between teammates without recording context in agent memory or task notes.
## References
In-depth playbooks live in `references/`:
- `template-cook.md` — parallel implementation: file ownership, lead vs `--delegate`, merge sequencing
- `template-debug.md` — competing-hypotheses methodology (assign, score, converge)
- `agent-memory.md` — what to persist per teammate, handoff format, hygiene
- `failure-recovery.md` — crashes, idle stalls, conflict-resolution playbook
## Related Skills
- `[[cook]]` — single-feature lifecycle engine; `team cook` parallelizes across features
- `[[planning]]` — generate plans before handing off to teams
- `[[retro]]` — postmortem when team runs go sideways
- `[[context-engineering]]` — per-teammate token budgets and layer caps