From pro-workflow
Coordinates multiple Claude Code sessions as lead + teammates with shared tasks, messaging, file locks for parallel repo development. Includes sizing, decomposition patterns.
npx claudepluginhub rohitg00/pro-workflow --plugin pro-workflowThis skill uses the workspace's default tool permissions.
Coordinate multiple Claude Code sessions working on the same codebase simultaneously.
Coordinates multiple Claude Code instances as agent teams with shared tasks, inter-agent messaging, and management for parallel research, feature development, debugging, and cross-layer coordination.
Coordinates Claude Code Agent Teams with shared planning files for parallel work on complex tasks like code review, debugging, and feature development. Requires experimental agent teams enabled.
Coordinates multiple Claude Code instances as agent teams for workflows needing inter-agent communication. Covers TeamCreate, SendMessage types, task coordination, hooks, and orchestration patterns.
Share bugs, ideas, or general feedback.
Coordinate multiple Claude Code sessions working on the same codebase simultaneously.
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
claude # starts as team lead
The first session becomes the team lead. Subsequent sessions in the same repo join as teammates.
Team Lead (coordinates, delegates, reviews)
├── Teammate 1 (owns task A, messages lead + peers)
├── Teammate 2 (owns task B, messages lead + peers)
└── Teammate 3 (owns task C, messages lead + peers)
│
└── Shared: task list + mailbox + file locks
Key difference from subagents: Teammates are full Claude Code sessions. They have their own context window, can use all tools, and message each other directly — not just report back to a parent.
| Team Size | Best For |
|---|---|
| 2 | One builds, one reviews |
| 3-5 | Parallel features across layers (API, UI, tests) |
| > 5 | Coordination overhead outweighs parallelism |
3-5 teammates is the productive range. Beyond that, the lead spends more time coordinating than the team saves.
Task granularity: Aim for 5-6 tasks per teammate. Fewer means underutilization; more means excessive context switching.
In-process navigation:
Shift+Down — cycle through teammates (wraps around)Split-pane (recommended for >2 teammates):
tmux split-window -h per teammateclaude sessionTasks flow through states:
pending → in-progress → completed
│
└── blocked (waiting on dependency)
Break work into units that:
Good decomposition:
Task 1: Add rate limiting middleware (src/middleware/rate-limit.ts)
Task 2: Add rate limit tests (tests/rate-limit.test.ts)
Task 3: Update API docs for rate limit headers (docs/api.md)
Task 4: Add Redis config for rate limit store (src/config/redis.ts)
Bad decomposition:
Task 1: Implement rate limiting
Task 2: Fix rate limiting bugs
Task 3: Improve rate limiting
Tasks can declare dependencies:
Task 3 (API docs) → depends on Task 1 (middleware)
Task 2 (tests) → depends on Task 1 (middleware)
Task 4 (Redis config) → no dependencies
Teammates pick up unblocked tasks automatically.
Teammates claim files before editing to prevent conflicts:
If two teammates need the same file, one waits or the lead reassigns.
Teammates plan before implementing:
This prevents wasted work from misunderstood requirements.
Shift+Tab toggles delegate mode for the lead:
| Hook | Fires When |
|---|---|
| TeammateIdle | A teammate finishes its task and has no pending work |
| TaskCreated | New task added to the shared list |
| TaskCompleted | A teammate marks a task done |
Use these to trigger notifications, auto-assign next tasks, or run integration tests when all tasks complete.
| Scenario | Use |
|---|---|
| Parallel work on non-overlapping files | Agent teams |
| Quick background exploration | Subagent |
| Isolated feature branch work | Worktree (claude -w) |
| Competing approaches to same problem | Worktrees (compare results) |
| Cross-layer changes (API + UI + tests) | Agent teams |
| One-off delegation | Subagent with isolation: worktree |
| Large-scale migration (20+ files) | /batch command |
Lead: "We need rate limiting. Breaking into 4 tasks."
Task 1: middleware implementation → Teammate 1
Task 2: Redis config → Teammate 2 (no deps)
Task 3: tests → Teammate 1 (after Task 1)
Task 4: API docs → Teammate 2 (after Task 1)
Teammate 1 plans → Lead approves → implements Task 1
Teammate 2 plans → Lead approves → implements Task 2
Task 1 completes → unblocks Tasks 3 and 4
Teammate 1 picks up Task 3, Teammate 2 picks up Task 4
All complete → Lead runs integration tests → commits