agent-teams
- Repo stars 2,212
- Author updated Live
- Author repo pro-workflow
- Domain
- AI
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @rohitg00 · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: agent-teams
description: Coordinate multiple Claude Code sessions as a team — lead + teammates with shared task lists, ma…
category: ai
runtime: no special runtime
---
# agent-teams output preview
## PART A: Task fit
- Use case: Coordinate multiple Claude Code sessions as a team — lead + teammates with shared task lists, mailbox messaging, and file-lock claiming. Patterns for team sizing, task decomposition, and when to use teams vs sub-agents vs worktrees..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Enable / Architecture / Team Sizing” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Coordinate multiple Claude Code sessions as a team — lead + teammates with shared task lists, mailbox messaging, and file-lock claiming. Patterns for team sizing, task decomposition, and when to use teams vs sub-agents vs worktrees.”.
- **02** When the source has headings, the agent prioritizes “Enable / Architecture / Team Sizing” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source mentions slash commands such as `/batch`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “Enable / Architecture / Team Sizing”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: agent-teams
description: Coordinate multiple Claude Code sessions as a team — lead + teammates with shared task lists, ma…
category: ai
source: rohitg00/pro-workflow
---
# agent-teams
## When to use
- Coordinate multiple Claude Code sessions as a team — lead + teammates with shared task lists, mailbox messaging, and f…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Enable / Architecture / Team Sizing” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "agent-teams" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Enable / Architecture / Team Sizing
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Agent Teams
Coordinate multiple Claude Code sessions working on the same codebase simultaneously.
Enable
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.
Architecture
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 Sizing
| 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.
Display Modes
In-process navigation:
Shift+Down— cycle through teammates (wraps around)- See each teammate's current task and output
Split-pane (recommended for >2 teammates):
- tmux:
tmux split-window -hper teammate - iTerm2: Cmd+D for vertical split
- Each pane runs its own
claudesession
Task Management
Tasks flow through states:
pending → in-progress → completed
│
└── blocked (waiting on dependency)
Task Decomposition
Break work into units that:
- Touch non-overlapping files
- Can be verified independently
- Have clear done criteria
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
Dependencies
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.
File-Lock Claiming
Teammates claim files before editing to prevent conflicts:
- Teammate checks if file is locked
- If free, claims it (file-lock-based)
- Edits the file
- Releases lock on task completion
If two teammates need the same file, one waits or the lead reassigns.
Plan Approval
Teammates plan before implementing:
- Teammate receives task
- Writes a brief plan (files to change, approach)
- Lead reviews plan
- Lead approves or redirects
- Teammate implements
This prevents wasted work from misunderstood requirements.
Delegate Mode
Shift+Tab toggles delegate mode for the lead:
- Lead coordinates only — no direct code edits
- All implementation delegated to teammates
- Lead reviews, approves plans, manages task flow
Hook Events
| 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.
When to Use Teams vs Alternatives
| 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 |
Anti-Patterns
- More than 5 teammates — coordination overhead dominates
- Tasks that share mutable state or the same files
- Skipping plan approval — leads to rework
- Lead doing implementation instead of coordinating (use delegate mode)
- Not setting dependencies — teammates race on coupled tasks
Example Session
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
Decide Fit First
Design Intent
How To Use It
Boundaries And Review