安装方式
手动下载安装
下载 ZIP 后解压到技能目录即可安装。若在桌面客户端 WebView中直接下载出现异常,本站会改为提示页 + 原始链接,请按页内说明操作。
下载 ZIP (shub-claude-agent-team-workflows-0-1-0-v1.0.0.zip)触发指令
/agent-team-workflows
跨平台安装指引
该技能声明兼容以下 1 个平台,将 ZIP 解压到对应目录即可被识别。
unzip shub-claude-agent-team-workflows-0-1-0-v1.0.0.zip -d ~/.claude/skills/
mkdir -p 创建;启用 Skill 后请重启对应 Agent 让配置生效。
使用指南
多智能体团队工作流
围绕 多智能体团队工作流:基于 Claude Code Agent Teams 的多智能体编排:适合需要并行角色协作、跨领域任务(开发、内容、数据、研究等)时使用。 无需在每次任务前把零散英文说明手工拼进上下文,也 减少 与客户端默认行为脱节的试错;具体命令、钩子与 JSON 参数仍以 ZIP 包内 SKILL.md 为权威。下文结构与站内 MCP CLI 类专题稿相同:何时用、前置、流程、速查与故障。
何时使用
- 基于 Claude Code Agent Teams 的多智能体编排:适合需要并行角色协作、跨领域任务(开发、内容、数据、研究等)时使用
- 已获取本技能 ZIP,并准备在 Claude Code / OpenClaw 中按 SKILL.md 挂载。
- 希望用中文专题稿快速判断「该不该启用」,再深入英文 SKILL 查参数与边界。
- 需要与团队对齐同一套触发方式、目录约定或回调格式时。
前置条件
- 通用:可运行 Claude Code 或文档要求的客户端;有可读写的项目工作区(或 SKILL.md 指定的沙箱目录)。
- 权威细节:API Key / OAuth、钩子路径、环境变量以 ZIP 内 SKILL.md 为准。
- Agent Teams:Claude Code 版本支持原生多智能体编排;角色分工见 SKILL.md。
典型流程
- 从 ClawHub / 站内分发获取技能 ZIP,校验版本与校验和(若提供)。
- 阅读 SKILL.md 的安装段落:目录落点、客户端类型(Claude Code / OpenClaw / 脚本)。
- 用文档中的最小示例完成第一次调用(单文件修改、单次查询或单次委派)。
- 确认工作目录、权限边界与输出路径后,再处理多文件或长耗时任务。
- 需要回调 / Webhook / 通知时,按 SKILL.md 配置端点并在测试环境先验通。
与 ZIP / SKILL.md 的关系
站内专题稿与 MCP CLI 类 oss 稿同样:概括何时用、怎么接、怎么排错;命令模板、钩子名、JSON 字段、版本矩阵一律以 ZIP 内 SKILL.md 与 ClawHub 上游为准。
命令示例(摘自包内 SKILL.md)
以下为从上游 SKILL.md(或入库正文)自动抽取的终端/脚本片段;路径、环境变量与参数以当前 ZIP 与官方说明为准。
ClawHub slug:claude-agent-team-workflows-0-1-0(安装命令以 SKILL.md / claw CLI 为准)。
站内入库时的触发命令(完整语义见 ZIP):
# 使用本技能时可在对话中引用或执行上述指令;完整参数与示例见下载包内 SKILL.md。
/agent-team-workflows
最佳实践
- 先 SKILL.md 再猜参数;站内专题稿不替代 schema 与必填字段说明。
- 委派任务时写清验收标准(命令、文件路径、测试命令),减少来回追问。
- 长任务用文档推荐的回调 / 日志落盘代替高频轮询,省 Token 也省机器负载。
- 多技能同时启用时,注意钩子加载顺序与重复工具调用(以 SKILL.md 冲突说明为准)。
调试与排错
- 打开 stderr 与客户端日志;PTY/tmux 场景同时看面板最后几十行输出。
- 参数错误时对照 SKILL.md 中的 JSON/CLI 示例(引号、转义、工作目录)。
- 网络类失败:查代理、防火墙、MCP 传输方式(stdio / HTTP / SSE)。
速查
| 动作 | 说明 |
|------|------|
| 获取技能包 | ClawHub / 站内 ZIP,核对版本 |
| 权威步骤 | 优先阅读 ZIP 内 SKILL.md |
| 首次试跑 | 使用 SKILL.md 最小示例 |
| 验收 | 对照路径、测试命令或回调负载 |
常见故障
- 无输出或立即退出 → 工作目录错误、依赖未装、或 Claude Code 未登录;按 SKILL.md 自检清单执行。
- 权限被拒绝 → 检查沙箱路径、
--permission-mode与工具白名单。 - 与简介不符 → 以英文 SKILL 与上游仓库为准,站内稿仅作结构化导读。
# Agent Team Workflows
Universal orchestration framework for 5-agent teams (1 Lead + 4 Teammates) across any domain.
## Prerequisites
Agent Teams must be enabled. Add to `~/.claude/settings.json`:
```json
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
```
## Generic Roles
Teammate IDs are fixed. Their **function** is remapped per domain via **Role Cards**.
| Slot | ID | Generic Function | Core Responsibility |
|------|----|------------------|---------------------|
| **Lead** | (session) | Orchestrator | Assign tasks, relay context, quality gate, synthesize final output |
| **Slot A** | `architect` | **Planner** | Frame problem, decompose tasks, produce plan/spec/blueprint |
| **Slot B** | `developer` | **Builder** | Produce primary artifact (code, draft, dataset, model, proposal) |
| **Slot C** | `tester` | **Validator** | Check against acceptance criteria, test, evaluate correctness |
| **Slot D** | `reviewer` | **Critic** | Assess quality, risk, consistency, compliance, suggest improvements |
### Role Cards (Domain Remapping)
Each domain preset provides **Role Cards** that specialize the generic functions:
| Domain | Planner | Builder | Validator | Critic |
|--------|---------|---------|-----------|--------|
| Software Dev | Architect | Developer | Tester | Code Reviewer |
| Content Creation | Producer | Writer | Fact-Checker | Editor |
| Data Analysis | Analyst Lead | Data Engineer | Statistician | Peer Reviewer |
| Business Strategy | Strategist | Business Analyst | Financial Modeler | Risk Advisor |
| Research | Research Lead | Researcher | Methodology Auditor | Peer Reviewer |
> Full role cards with artifact contracts → `reference/domain-presets.md`
## Pipeline Patterns
4 canonical control-flow patterns. Domain meaning comes from Role Cards, not the pattern itself.
### 1. sequential — Step-by-Step Pipeline
```
Planner → Builder → Validator → Critic → Lead Synthesis
```
**Use when:** Work is linear and each step depends on the previous output.
**Examples:** Feature dev, content creation, report writing.
### 2. parallel-merge — Parallel Exploration + Merge
```
Planner → (Builder ∥ Validator ∥ Critic) → Lead Merge → Validator Gate → Lead Synthesis
```
**Use when:** Multiple perspectives can work independently, then combine.
**Examples:** Research, strategy analysis, multi-angle evaluation.
### 3. iterative-review — Build-Critique Loop
```
Planner → Builder ↔ Critic (max N rounds) → Validator → Lead Synthesis
```
**Use when:** Quality requires iteration between creator and reviewer.
**Examples:** Content editing, design refinement, proposal drafting.
**Guard:** Default max 2 rounds. More requires user approval.
### 4. fan-out-fan-in — Map-Reduce
```
Planner → fan-out tasks to all 4 teammates → Lead fan-in merge → Critic Gate → Lead Synthesis
```
**Use when:** Large work can be split into independent chunks processed in parallel.
**Examples:** Multi-module features, large dataset processing, codebase audit.
> Pattern deep dives with sample task graphs → `reference/patterns.md`
## Coordination Protocol
Strict 6-step protocol, domain-agnostic.
### Step 1: Confirm Scope
Before spawning any team, confirm with user:
1. **Objective** — specific deliverable
2. **Domain** — select preset or define custom Role Cards
3. **Pattern** — which pipeline pattern fits
4. **Constraints** — tools, tech stack, tone, compliance, budget
5. **Inputs** — source material, existing assets, context files
6. **Definition of Done** — checkbox acceptance criteria the user agrees to
### Step 2: Build Workflow Instance Spec
Fill in the universal template:
```
WORKFLOW INSTANCE SPEC
─────────────────────
Objective: [deliverable]
Pattern: [sequential | parallel-merge | iterative-review | fan-out-fan-in]
Domain: [preset name or "custom"]
ROLE CARDS
Planner (architect): [domain title] — [specific responsibility]
Builder (developer): [domain title] — [specific responsibility]
Validator (tester): [domain title] — [specific responsibility]
Critic (reviewer): [domain title] — [specific responsibility]
ARTIFACTS (per step)
Step 1 → [artifact name]: [format/content description]
Step 2 → [artifact name]: [format/content description]
Step 3 → [artifact name]: [format/content description]
Step 4 → [artifact name]: [format/content description]
CONSTRAINTS: [tools, rules, limits]
INPUTS: [files, data, references]
DEFINITION OF DONE:
□ [criterion 1]
□ [criterion 2]
□ [criterion 3]
```
### Step 3: Create Team
```
Create a team of 4 teammates:
- architect: [Planner role card — context and responsibility]
- developer: [Builder role card — context and responsibility]
- tester: [Validator role card — context and responsibility]
- reviewer: [Critic role card — context and responsibility]
```
### Step 4: Create Tasks with Dependencies
Create tasks following the selected pattern's pipeline order. Each task MUST have:
- Clear description referencing role card
- Required input artifact (from previous step or original inputs)
- Required output artifact (format + content)
- Acceptance criteria
- Dependency on predecessor task
### Step 5: Spawn Teammates with Rich Context
Each teammate MUST receive in their spawn prompt:
1. **Role Card** — their domain title + specific responsibilities
2. **Assigned task** — what to produce
3. **Input artifact** — output from previous step (Lead must relay this)
4. **Output artifact contract** — exact format and content expected
5. **Constraints** — domain rules, style guides, compliance
6. **Handoff instruction** — "Message the lead with [artifact] when done"
**Universal spawn template:**
```
Spawn a [ID] teammate with the prompt:
"You are the [Domain Title] ([Generic Function]).
YOUR TASK: [task description]
INPUT: [paste or reference previous step's output]
PRODUCE: [artifact name]
Format: [expected format]
Must include: [required sections/elements]
CONSTRAINTS:
- [rule 1]
- [rule 2]
When done, message the lead with your complete [artifact name].
If you encounter blockers, message the lead immediately."
```
### Step 6: Coordinate Handoffs
When a teammate completes their step:
1. Lead receives output via message
2. Lead validates output against acceptance criteria
3. Lead passes artifact + relevant context to next teammate via message
4. If output is insufficient → send specific feedback, ask to revise
### Step 7: Synthesize & Deliver
After all steps complete:
1. Collect all artifacts
2. Verify all Definition of Done criteria are met
3. Summarize what was done (traceability: each criterion → which step satisfied it)
4. List remaining TODOs or known issues
5. Present final deliverable to user
## Lead Discipline Rules
1. **Delegate only** — Lead does NOT produce primary artifacts. Use delegate mode (`Shift+Tab`).
2. **Relay all context** — Teammates have no shared history. Lead MUST forward relevant artifacts between steps.
3. **Direct messages** — Use direct messages, not broadcast (saves 4× tokens). Broadcast only for parallel-merge sync points.
4. **Right-size tasks** — 5-6 tasks per teammate max. Split large work.
5. **Gate high-risk actions** — Require user approval for: irreversible changes, external publication, legal/compliance, high-cost operations, production deployments.
6. **Wait for teammates** — Never proceed or implement yourself. Wait for teammate completion before next step.
## Handling Failures
| Situation | Action |
|-----------|--------|
| Teammate stuck | Message with additional context, hints, or simplified sub-task |
| Bad output | Send specific feedback citing acceptance criteria, ask to revise |
| Teammate stops | Spawn replacement with same context + summary of work already done |
| Conflict between teammates | Lead mediates, makes final decision, messages both with resolution |
| Task too large | Lead splits into subtasks, reassigns across teammates |
| Iterative loop exceeds max | Ask user whether to approve more rounds or finalize current state |
## Cost Guidelines
| Pattern | Est. Cost | Worth It When |
|---------|-----------|---------------|
| sequential | ~4-5× single | Work spans 3+ artifacts/files with clear pipeline |
| parallel-merge | ~4× single | 3+ independent perspectives needed |
| iterative-review | ~3-4× single | Quality requires creator-critic dialogue |
| fan-out-fan-in | ~5× single | Large work divisible into independent chunks |
**Rule of thumb:** If one agent can finish in one session, don't use a team. Teams shine when work is parallelizable or benefits from multiple specialized perspectives.
## Domain Presets (Quick Reference)
| Preset | Recommended Pattern | Key Artifacts |
|--------|-------------------|---------------|
| `software-dev` | sequential / fan-out-fan-in | Design doc, source code, test suite, review report |
| `content-creation` | iterative-review | Content brief, draft, fact-check report, final edit |
| `data-analysis` | fan-out-fan-in | Analysis plan, datasets/transforms, statistical evaluation, findings report |
| `business-strategy` | parallel-merge | Strategy framework, market analysis, financial model, risk assessment |
| `research` | parallel-merge | Research plan, literature review, methodology audit, synthesis paper |
> Full presets with role cards, artifacts, and worked examples → `reference/domain-presets.md`
> Ready-to-use prompt templates → `reference/prompt-templates.md`
> Pattern deep dives → `reference/patterns.md`