ClawTeam Multi-Agent Swarm Skill (Hermes Edition)
Spin up a team of 5–7 parallel specialist agents from Hermes in one command, with kanban boards and inboxes handling coordination instead of single sub-agent delegation.
The skill transparently documents how the spawn adapter builds commands, MCP inheritance, known upstream defects and fixes; data flow (~/.clawteam state, tmux, git worktrees) is clear, with MIT license and upstream attribution to HKUDS/ClawTeam. Deducted because: workers run with --yolo/skip_permissions by default, bypassing interactive permission confirmation; cleanup uses --force and template launch requires --force to suppress warnings; the README install flow also switches OpenClaw exec approvals to allowlist. Parallel multi-agent execution amplifies external side effects with no rollback/recovery mechanism described. This sits at the 'main risks visible but confirmation/isolation incomplete' anchor.
High self-consistency: flag distinctions (--team-name vs --team, positional hermes), timing expectations (sleep 60, polling), diagnostic commands (tmux capture, team status) are all given, and three known failure modes (risk-manager crash, empty inbox, non-persistent output) are honestly documented. Deducted because the core read path (inbox peek) itself 'often returns EMPTY' and actual output survives only in tmux scrollback lost on cleanup — a real reliability defect, not merely a documentation issue; static review cannot verify key-path reproduction, so the score is capped at 10.
Trigger conditions are precise (explicit trigger words, when NOT to use delegate_task, four template scenarios), environment dependencies (Python 3.10+, tmux, Hermes ≤0.8.0 --source limitation) are disclosed, and Chinese users are served (Chinese README exists, though SKILL.md is English-only). Deducted because: the skill targets Hermes users yet sits in an OpenClaw-focused fork, an awkward fit; multi-agent launches are costly (7 analysts, 2-5 minutes, heavy token use) with no cost boundary stated; evidence of fit beyond stock/research/review scenarios is limited.
Good layered information architecture: triggers → critical flags → recommended path → manual path → command reference → known failure modes → anti-patterns, with progressive disclosure; has version (0.3.0), MIT license, upstream attribution, known-limitation disclosure and an upstream patch guide. Deducted: no CHANGELOG or maintenance-ownership statement (fork update path depends on upstream sync without commitment); pyproject version 0.3.0+openclaw2 mildly inconsistent with the skill file version; publisher identity is unverified in the registry.
The core task (template-based multi-agent team launch producing a synthesized report) is fully described, with concrete use cases in the README. Deducted: Hermes workers often skip the inbox-send, output lives in tmux scrollback and is lost on cleanup, and risk-manager is prone to crashing leaving synthesis incomplete — the user must do substantial manual capture and assembly to obtain usable results; output correctness has no executed evidence; comparative benefit over a single agent is only asserted ('dramatically better'), not verified. Static cap limits the score below 7.
A real CI workflow (multi-OS/Python pytest matrix) and a committed test suite exist, and tests/test_adapters.py thoroughly covers the Hermes adapter behavior claimed in SKILL.md (chat insertion, --source tool, --yolo, -q prompt), mutually corroborating the documentation. Deducted: tests cover the CLI adapter layer, not the end-to-end multi-agent orchestration the skill promises; CI results are not visible as third-party execution evidence in static review; key value claims (7 analysts producing better results) are unverifiable. Static cap limits the score below 5.
- The skill launches Hermes workers with --yolo/skip_permissions by default, bypassing permission prompts, and template launch requires --force to suppress warnings. Parallel multi-agent execution amplifies side effects; use only in acceptable code/environment sandboxes.
- Known serious reliability defects: inbox peek often returns empty, actual output exists only in tmux scrollback and is permanently lost after team cleanup --force; the risk-manager agent is prone to crashing, leaving synthesis incomplete. Always capture all tmux panes before cleanup.
- Hermes ≤0.8.0 does not propagate --source tool; a one-line upstream patch is required for session isolation, otherwise spawned sessions mix with interactive sessions.
- The skill targets Hermes users while the repository promotes OpenClaw; templates default to openclaw, and omitting --command hermes fails outright. SKILL.md is English-only; Chinese users must rely on the README translations.
- Seven-agent parallel launches incur high token/time cost (~2-5 minutes per team); publisher identity is unverified by FollowSkills; this is a static review with no execution performed.
What does this skill do, and when should you use it?
This is the Hermes-facing skill file (skills/hermes/SKILL.md) from the win4r/ClawTeam-OpenClaw repository. It teaches Hermes when to route team/swarm/multi-agent requests to the clawteam CLI rather than a single delegate_task call. It ships four built-in templates — hedge-fund (7 analyst roles), research-paper, code-review, and strategy-room — all running in isolated tmux windows with git worktrees. It prescribes exact launch flags (--team-name, --command hermes), a mandatory ~60-second boot wait with 30-second board polling, and documents known pitfalls: Hermes ≤ 0.8.0 ignoring --source tool, and unreliable inbox peek requiring tmux capture instead. It suits users already running Hermes who want multi-perspective parallel analysis.
The skill is an instruction file that, once installed, drives Hermes to: call clawteam launch to instantiate template-based teams (e.g., hedge-fund spawns portfolio-manager, buffett, growth, technical, fundamentals, sentiment, and risk-manager agents); use clawteam spawn for custom teams, where each worker runs hermes chat --yolo --source tool -q "<task>" in its own tmux window and git worktree; track tasks from pending to COMPLETED via the kanban board (board show/live); read agent output via clawteam inbox peek or tmux capture-pane; and tear down with team cleanup. Workers automatically inherit MCP servers configured in ~/.hermes/config.yaml.
- A developer who uses Hermes Agent daily and wants stock, research, or review questions answered by 5–7 parallel specialist agents instead of one response
- An individual investor wanting multi-perspective analysis of a stock (e.g., TSLA) across value, growth, technical, fundamentals, sentiment, and risk lenses
- A researcher surveying arXiv papers or multiple sources in parallel and synthesizing a report
- A developer reviewing a pull request from multiple angles (architecture, security, testing)
- Anyone needing an ad-hoc custom team (e.g., a researcher plus a writer) for a multi-step task
What are this skill's strengths and limitations?
- Four ready-made templates; one command spins up a 7-role hedge-fund-style analysis team
- The skill file exhaustively documents flag pitfalls, polling cadence, and failure modes, reducing trial and error
- Each worker gets an isolated git worktree and dedicated tmux window, making output traceable
- Workers automatically inherit Hermes-configured MCP servers, so knowledge bases and memory stores work out of the box
- Clearly delineates when to use clawteam versus delegate_task
- Upstream Hermes ≤ 0.8.0 bug: --source tool is accepted but not propagated, so spawned sessions interleave with personal sessions until a one-line patch is applied
- inbox peek often returns empty — Hermes workers write to tmux scrollback, not the inbox system; reading results requires tmux capture
- Worker output is not persistent: findings are lost on cleanup unless captured or written to an MCP-backed store
- The risk-manager agent is known to crash mid-run, potentially leaving the final synthesis incomplete
- Each run takes 2–5+ minutes, and no token/cost estimates are documented
- Templates were designed around OpenClaw's inbox-send coordination pattern; Hermes workers sometimes finish without sending inbox messages
How do you install this skill?
Prerequisites: Python 3.10+, tmux (Linux/macOS/WSL), and Hermes Agent. Install the host (do NOT pip install clawteam — the PyPI version defaults to claude and lacks this fork's adaptations): git clone https://github.com/win4r/ClawTeam-OpenClaw.git && cd ClawTeam-OpenClaw && pip install -e . Optionally ensure PATH in fresh shells: mkdir -p ~/bin && ln -sf "$(which clawteam)" ~/bin/clawteam. Install the skill (Hermes users): mkdir -p ~/.hermes/skills/openclaw-imports/clawteam && cp skills/hermes/SKILL.md ~/.hermes/skills/openclaw-imports/clawteam/SKILL.md, then verify with hermes skills list | grep clawteam. The source does not document any Hermes-specific differences under native Windows.
How do you use this skill?
Trigger it by phrasing requests with team/swarm/multi-agent keywords. One-command template launch: clawteam launch hedge-fund --team-name tesla --goal "Analyze TSLA" --command hermes --force (Hermes users MUST pass --command hermes; templates default to openclaw and will fail with gateway token errors otherwise). Manual mode: clawteam spawn -t my-team -n researcher --task "..." --no-workspace hermes (hermes is a trailing positional arg, not --command). After launching, sleep 60 for boot (each worker takes 20–40 s), then poll board show every 30 seconds; total runtime is typically 2–5 minutes. Read results via tmux capture-pane per window (inbox peek is unreliable), and only run clawteam team cleanup <name> --force after capturing reports.
How does this skill compare with similar options?
The upstream project is HKUDS/ClawTeam; this repo is a fork with deep OpenClaw integration (openclaw as default agent) that syncs all upstream fixes. The skill file itself contrasts clawteam against the single sub-agent delegate_task: the latter is one agent, while clawteam is 5–7 parallel specialists with a kanban board and shared inboxes. The README also contrasts ClawTeam with other multi-agent frameworks, which require humans to write orchestration code and depend on Redis/message queues, whereas ClawTeam needs only a filesystem plus tmux.