Auto-configure quality gates, hooks, and settings for a new project. Detects project type and sets up appropriate tooling. Use when onboarding a new codebase.
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。
安装前可以查看交给 AI 代理的指令内容。
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
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Auto-configure quality gates, hooks, and settings for a new project. Detects project type and sets up appropriate tooling. Use when onboarding a new codebase.
中文简介正在准备中。当前显示原文说明。
Decompose large-scale changes into independent units and spawn parallel agents in isolated worktrees. Use for migrations, refactors, codemods, and any change touching 10+ files with the same pattern.
中文简介正在准备中。当前显示原文说明。
Capture a user-reported defect as a durable GitHub issue written in the project's own domain language. Explores the codebase in parallel for context but never leaks file paths or line numbers into the issue. Use when the user reports a bug conversationally, runs a QA pass, or says "file an issue", "log this as a bug", "capture this".
中文简介正在准备中。当前显示原文说明。
Smart context compaction with state preservation. Saves critical files, task progress, and working state before compaction, restores after. Use before manual compact or when auto-compact triggers.
中文简介正在准备中。当前显示原文说明。
Master the four operations of context engineering — Write, Select, Compress, Isolate. Manage token budgets, compaction strategies, and context partitioning to keep AI sessions sharp and efficient.
中文简介正在准备中。当前显示原文说明。
Optimize token usage and context management. Use when sessions feel slow, context is degraded, or you're running out of budget.
中文简介正在准备中。当前显示原文说明。