skills/team-orchestration/SKILL.md
Creates and coordinates teams of persistent AI teammates with shared task lists, messaging, and lifecycle management. Use when spawning teammates, creating a team, setting up reviewers or implementers, coordinating multi-agent work, or any skill references "kit:team-orchestration". Provides the scaffolding for TeamCreate, teammate spawning, task dependencies, SendMessage communication, and graceful shutdown.
npx skillsauth add shousper/claude-kit team-orchestrationInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Shared foundation for team-aware skills. Defines how to create teams, spawn teammates, coordinate work, and shut down cleanly.
Core principle: Teams API replaces raw Task tool dispatch. Persistent teammates coordinate via shared task lists and messaging.
Announce at start: "I'm setting up a team using the team-orchestration skill."
TeamCreate with descriptive name derived from the work:
"implement-auth-feature", "fix-test-failures", "brainstorm-caching"Use the Task tool with team_name parameter to spawn teammates into the team.
Agent type selection:
general-purpose — teammates that write code, run commands, edit filesExplore — pure research/read-only work (scouts, analyzers)Plan — read-only, for architecture and planning work that uses ExitPlanModeNaming convention: Role-based, lowercase with hyphens: implementer, spec-reviewer, quality-reviewer, scout-1, scout-2.
After spawning, read the team config to confirm all members registered:
Read: ~/.claude/teams/<team-name>/config.json
Use TaskCreate with:
activeForm for spinner textUse TaskUpdate with addBlockedBy for ordering:
Use TaskUpdate with owner set to the teammate's name.
Use TaskList to check progress. All teammates see the same task list.
SendMessage with full task contextTeammates may ask questions via SendMessage. Answer promptly — they're blocked until you respond.
Teammates can DM each other directly. The team lead sees a summary in idle notifications.
When a teammate with plan_mode_required finishes planning:
ExitPlanMode — sends plan_approval_request to team leadplan_approval_response:
Only for critical blockers affecting the entire team. Each broadcast sends a separate message to every teammate.
Teammates are persistent — they stay alive across task assignments.
Spawn → Work → Idle → Wake (on message) → Work → Idle → ... → Shutdown
Do not re-spawn teammates for each task. Send new assignments via message.
| Safety | When | Examples | |--------|------|----------| | Safe | Read-only tasks | Reviews, research, analysis | | Conditional | Non-overlapping writes | Different files/modules | | Never | Same-file writes | Two teammates editing same file |
Team lead assesses parallelism safety per task pair. When uncertain, default to sequential.
TaskList — no pending/in_progress)shutdown_request to each teammateshutdown_response from eachTeamDelete to clean upReferenced by domain skills:
**Required:** kit:team-orchestration — set up team before starting
Domain skills bring their own workflow logic and prompt templates. This skill provides the coordination scaffolding.
Never:
Always:
development
Creates, edits, and tests Claude skill files (SKILL.md) using TDD methodology with baseline pressure testing and rationalization defense. Use when writing a new skill, modifying an existing skill, optimizing a skill description for discovery (CSO), testing whether a skill triggers correctly, or structuring skill documentation. Enforces RED-GREEN-REFACTOR for process documentation.
development
Creates detailed, bite-sized implementation plans with TDD structure, exact file paths, complete code, and test commands. Use when you have a spec, requirements, design doc, or feature request and need to plan before coding — especially for multi-step tasks, large features, or when handing off to another session. DO NOT TRIGGER when asked to write code directly or fix a simple bug.
testing
Removes git worktrees safely, cleans up associated branches, and pulls latest mainline after removal. Use when finished with a worktree, done with a branch, cleaning up after a merge or PR, abandoning work in a worktree, or when "git worktree list" shows stale entries. Checks for uncommitted changes, verifies no open PRs before branch deletion, and handles force-removal of locked worktrees.
development
Enforces fresh verification evidence before any completion or success claims. Use when about to say "done", "fixed", "tests pass", "build succeeds", or any synonym; before committing, creating PRs, or moving to the next task; before expressing satisfaction or positive statements about work state; and after agent delegation to independently verify results. Prevents unverified claims by requiring command execution, output inspection, and exit code confirmation.