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.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
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.
日本語の概要は準備中です。原文の説明を表示しています。