What does this skill do, and when should you use it?
ClawTeam, open-sourced by HKUDS, is a framework-agnostic CLI tool that orchestrates multiple AI agents (Claude Code, Codex, etc.) as a team with one leader and multiple workers. Through the `clawteam` command it provides team/task management, inter-agent inbox messaging, git worktree isolation, provider-aware runtime profiles, git context injection, snapshots, and terminal dashboards. All state lives as JSON files in `~/.clawteam/` — no database, server, or cloud required. This skill is a SKILL.md guide that teaches agents when and how to invoke these CLI commands for multi-agent collaboration.
- Creates teams and spawns worker agents, each automatically getting its own git worktree, tmux window, and identity
- Maintains a shared task board (pending/in_progress/completed/blocked) with dependency chains and priorities; completing a task auto-unblocks dependents
- Handles point-to-point inbox messaging, broadcast, and non-destructive peek reads between agents
- Configures non-default model providers via preset/profile, with
profile testandprofile doctorpreflight checks - Provides
board show/live/attach/servedashboards, git conflict checks (context conflicts), and snapshot/restore (team snapshot/restore) - Supports
--machine-readable output on all commands, with atomic tmp+rename writes to prevent corruption
- A developer using Claude Code receives a large full-stack task and wants the agent to self-organize, splitting it into subtasks executed in parallel by spawned workers
- A researcher on a multi-GPU box wants a leader agent to assign a research direction per GPU and cross-pollinate best results (as in the README's 8×H100 autoresearch demo)
- An engineer refactoring an entire codebase wants each agent working in its own worktree, using `context conflicts` to check overlap before the leader merges
- Users running workers with non-default providers (Moonshot Kimi, MiniMax) who generate a profile from a preset and spawn with `--profile`
- Users wanting one-command launch of a prebuilt team archetype (e.g., the 7-agent hedge fund template) via a TOML template with `clawteam launch`
- Environments lacking tmux, a git repository, or any supported CLI agent — these are hard prerequisites
- Users with small single-agent tasks — multi-agent orchestration is overkill for work one agent handles efficiently
- Native Windows users — the default spawn backend depends on tmux, and the source documents no native Windows support
How do you install this skill?
- spawn enables skip-permissions by default, meaning spawned agents bypass permission confirmations; always use --no-skip-permissions or set skip_permissions=false and run only in trusted environments.
- inbox receive is destructive; prefer inbox peek in scripts to avoid losing messages.
- Skill doc version (0.3.1) mismatches package metadata (0.3.0); verify the actual released version before installing.
- This is a static review with no execution; reliability/effectiveness conclusions are inferred from docs and test code — validate on a small scale before production use.
- Depends on external CLI agents (claude/codex etc.) and tmux; the skill will not work if any prerequisite is missing.
- Shell / CLI
- Local filesystem
clawteam CLI (pip install, Python 3.10+)tmuxa CLI coding agent such as claude/codex/gemini/kimi/nanobot/openclawa git repository
Check whether the CLI is already available, then install via pip if missing:
clawteam --version
pip install clawteamFor P2P (ZeroMQ) transport support:
pip install "clawteam[p2p]"Claude Code: install this skill to ~/.claude/skills/clawteam (the repo's install scripts auto-install the bundled skill for detected clients).
Codex: install the skill to $CODEX_HOME/skills/clawteam (typically ~/.codex/skills/clawteam).
How do you use this skill?
Once installed, send your agent any of these to trigger it:
- Build a full-stack todo app with auth, database, and a React frontend — use clawteam to split the work across multiple agents in parallel
- Use clawteam to refactor the entire codebase, assigning one worker per module in its own worktree
- Create a team, spawn three agents to implement a feature, write tests, and run lint, and show the live kanban board
- Check my-team's task status and inbox, and reassign blocked tasks to idle agents
The skill activates on trigger phrases: requests to "create a team", "spawn agents", "assign tasks", "coordinate multiple agents", "view kanban board", or when a task is complex enough to split across agents (e.g., "build a full-stack app", "refactor the entire codebase"). Typical flow: set identity env vars → create team and tasks → spawn workers → monitor board → task wait. Example:
export CLAWTEAM_AGENT_ID="leader-001"
export CLAWTEAM_AGENT_NAME="leader"
export CLAWTEAM_AGENT_TYPE="leader"
clawteam team spawn-team my-team -d "Project team" -n leader
clawteam task create my-team "Implement feature" -o worker1
clawteam spawn --team my-team --agent-name worker1 --task "Implement the auth module"
clawteam board live my-team --interval 3
clawteam task wait my-team --timeout 300For non-default providers, configure a profile first:
clawteam preset generate-profile moonshot-cn claude --name claude-kimi
clawteam spawn tmux --profile claude-kimi --team my-team --agent-name worker5 --task "Build API endpoints"Workers follow a polling loop: check tasks → do work → check inbox → report lifecycle idle when idle, repeating until the leader explicitly shuts them down.
What are this skill's strengths and limitations?
- Framework-agnostic: any CLI agent that can run shell commands can join — no SDK, no framework lock-in
- Zero infrastructure: state is JSON files in ~/.clawteam/; needs only a filesystem and tmux, no database/server/cloud
- Solid engineering details: auto-unblocking dependency chains, git worktree isolation, atomic writes, snapshot/restore
- Agent self-organization: a coordination prompt is auto-injected on spawn, so workers report status and results autonomously
- Heavy prerequisites: Python 3.10+, tmux, a git repo, and at least one independently working CLI agent
- Spawn defaults to skipping permissions (skip-permissions on) — exercise caution in trust-sensitive environments and disable via --no-skip-permissions
- Cursor integration is experimental; the skill itself is only a CLI usage guide, so orchestration quality depends on the clawteam CLI's maturity
- `inbox receive` is destructive — messages are consumed on read, so misuse can lose messages; use peek for non-destructive reads
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| ClawTeam Multi-Agent Coordination Skill this page | 54 · Use with care | ★ 5.5k | 5mo ago | MIT |
| ClawTeam Multi-Agent Coordination | 51 · Use with care | ★ 1.5k | 3mo ago | MIT |
| ClawTeam Multi-Agent Swarm Coordination | 49 · Use with care | ★ 1.5k | 3mo ago | MIT |
| ClawTeam Multi-Agent Swarm Skill (Hermes Edition) | 48 · Use with care | ★ 1.5k | 3mo ago | MIT |
| do — Feature Development Orchestrator | 47 · Use with care | ★ 2.8k | 5mo ago | AGPL-3.0 |
The README contrasts ClawTeam with other multi-agent frameworks: those are typically driven by humans writing orchestration code, need Docker/Redis/message queues, and support only framework-specific agents, whereas in ClawTeam the AI agents themselves orchestrate via CLI commands, the infrastructure is just a filesystem and tmux, isolation uses real git worktrees, and any CLI agent works. The repo also mentions the sister project CLI-Anything, but this skill covers only ClawTeam's coordination capability.
How did FollowSkills review this skill?
Docs disclose data dir, snapshot/restore, atomic writes, and a --no-skip-permissions override, so risks are visible; but spawn defaults to skip-permissions on, inbox receive is destructive by default, and worktrees/context injection happen automatically — least privilege and user confirmation are incomplete, hence deduction.
SKILL.md, CLI reference and workflows are mutually consistent with aligned commands, options and data models; the repo has CI and tests covering spawn adapters. However, static review cannot reproduce key paths, and error-handling/failure-feedback evidence is thin, so the static cap of 10 applies.
Trigger conditions are concrete (spawn agents, task board, multi-agent coordination); inputs, prerequisites (tmux, git, a CLI agent) and non-fit boundaries are clear; China-reachable presets (moonshot-cn, minimax-cn) and Chinese docs exist. Near full marks, but no executed verification.
Layered docs (SKILL.md → references), MIT license, version field, known limitations and notes are present; maintainer HKUDS is identifiable. But SKILL.md says 0.3.1 while pyproject says 0.3.0 — version inconsistency — and no changelog/update path ships with the skill, hence deduction.
README shows multi-scenario use cases and a clear orchestration value claim; however no statically verifiable actual outputs exist (results appear only as narrative logs and video links), so below the static cap of 7.
The repo contains GitHub Actions CI (multi-OS, multi-Python) and committed tests covering spawn adapters and skip-permissions mapping — auditable primary material; but tests do not cover the full key paths the skill advertises (task board, inbox, profiles), so the static cap of 5 applies.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →