Team Builder
Overview
Design and bootstrap a multi-agent team with clear roles, dependency-aware workflow, and reliable collaboration rules. Start with role discovery, confirm scope with the user, then produce an implementation-ready team plan.
Workflow
1) Mirror language and capture mission
- - Detect and mirror the user's language.
- Follow minimal-question strategy from
references/dialog-flow.md. - Ask only missing items: team objective, expected outputs, constraints (timeline, tools, compliance), preferred channels.
- If user intent is broad, propose a default operating model first, then refine.
- Reuse language prompts from
references/language-templates.md.
2) Propose a complete role set (then let user prune)
- - Generate a comprehensive but practical role catalog for the mission.
- Always include
team-leader as mandatory core role. - Apply auto-completion and anti-overdesign rules from
references/dialog-flow.md. - Apply split/merge criteria from
references/splitting-principles.md. - Mark roles as:
-
Core (required)
-
Optional (context-dependent)
-
Not needed now (defer)
- - During role confirmation, use user language and show role names/functions only (no agent IDs at this stage).
- Ask user to confirm additions/removals before any build steps.
- For role suggestions, use
references/role-catalog.md as baseline patterns. - Only in the final creation report show: role name + agent ID + responsibilities.
3) Define each agent contract
For each confirmed role, define:
- - Agent ID (stable, short, lowercase-hyphen)
- team-leader id must be team-prefixed (e.g.,
<team>-team-leader) - Role mission
- Inputs consumed
- Outputs produced
- Decision authority
- Upstream/downstream dependencies
- Escalation target
Use the table format in references/output-templates.md.
4) Define collaboration protocol (must be explicit)
Do not rely on vague "work together" instructions. Specify:
- - Task delegation envelope (goal, context, deliverable, deadline)
- Status states (
accepted, blocked, done) - Completion callback requirement (explicit return to delegator)
- Long-task update cadence
- Timeout/retry/escalation policy
- No-raw-bulk-output rule (summary + artifact path only)
- Mid-process visibility: show who is working on what at each stage
Use references/collaboration-protocol.md.
5) Produce implementation + provisioning bundle
Return a concrete package for execution:
- 1. Team roster and responsibilities
- Agent interaction flow (ordered steps)
- Collaboration protocol summary
- Files to create/update (SOUL/AGENTS/IDENTITY guidance snippets)
- Provisioning plan (tools/skills/permissions per role)
- Team creation report (mandatory; includes stage deliverables+paths and security-check summary)
- Channel binding blueprints (provided automatically after the report)
- Smoke-test script (simple end-to-end validation prompt)
Mandatory execution path (programmatic, not prompt-only):
- - run single entrypoint: INLINECODE12
- this entrypoint must internally execute materialize -> validate -> emitreport
- if validate != ready, must return partiallyready/blocked and stop
Mandatory: run post-creation materialization checks via references/materialization-checklist.md.
Do not mark team as ready if role files are still placeholders.
Use:
- - INLINECODE14
- INLINECODE15
- INLINECODE16
- INLINECODE17
- INLINECODE18
- INLINECODE19
6) Safe execution guardrails
Before any external-effect action, apply this confirmation policy:
- - No confirmation needed for internal deterministic setup:
- creating/updating agents in openclaw.json
- setting A2A/subagents permissions
- - Confirmation required for channel/bot credential binding and other irreversible external effects.
For skill installation, run security pre-check first and block high-risk items.
Never auto-restart gateway during creation flow. If restart is required, ask user first or provide manual restart instruction.
If anything is ambiguous, pause and ask.
7) Failure handling and recovery
When setup/collaboration fails, apply
references/failure-modes.md.
Prioritize fast recovery with minimal blast radius:
- - preserve completed work
- recover from last checkpoint
- keep user status accurate (ready vs partially ready)
- never auto-install skills that fail security checks
Quality bar
- - Prefer fewer roles with crisp boundaries over many overlapping roles.
- Every role must have a measurable output.
- Every dependency must have a return path.
- Deliverables must be immediately actionable by an operator.
- Role docs must be rich enough to represent domain-expert behavior (not one-line placeholders).
- INLINECODE21 must orchestrate only and must not produce specialist implementation deliverables.
- All specialist outputs must be saved under team shared directory.
- Reuse patterns from
references/examples.md when user goals match known team archetypes.
Creation phase details
After role confirmation, follow
references/create-playbook.md exactly.
Use
references/snippet-templates.md to produce reusable SOUL/AGENTS append snippets.
Format final user handoff using
references/final-deliverable-sample.md.
Resources
- -
references/role-catalog.md: cross-domain role starter sets. - INLINECODE27 : locale-based role display names for confirmation stage.
- INLINECODE28 : minimal-question discovery flow and auto-completion rules.
- INLINECODE29 : bilingual/locale-aware prompt templates.
- INLINECODE30 : when to split/merge roles during discovery.
- INLINECODE31 : end-to-end examples for common team archetypes.
- INLINECODE32 : Single-Bot vs Multi-Bot Group binding plans and group config guidance.
- INLINECODE33 : role-to-tools/skills mapping baselines.
- INLINECODE34 : least-privilege profiles.
- INLINECODE35 : auto install + permission setup flow (with skill-vetter-first security scanning).
- INLINECODE36 : machine-readable security report and install decision schema.
- INLINECODE37 : explicit multi-agent coordination protocol.
- INLINECODE38 : final output templates and checklists.
- INLINECODE39 : execution-ready creation sequence.
- INLINECODE40 : reusable injection/confirmation snippets.
- INLINECODE41 : expert-level SOUL depth blueprint per role.
- INLINECODE42 : fixed team-leader SOUL template (copied at creation).
- INLINECODE43 : fixed team-leader AGENTS template (copied at creation).
- INLINECODE44 : standardized user handoff format.
- INLINECODE45 : failure scenarios and recovery actions.
- INLINECODE46 : post-creation role-file completion gate.
- INLINECODE47 : mandatory openclaw.json agent/binding/A2A completion gate.
团队构建器
概述
设计并启动一个多智能体团队,具备清晰的职责划分、依赖感知的工作流程以及可靠的协作规则。从角色发现开始,与用户确认范围,然后生成一份可直接实施的团队方案。
工作流程
1) 镜像语言并捕获任务
- - 检测并镜像用户的语言。
- 遵循references/dialog-flow.md中的最小提问策略。
- 仅询问缺失项:团队目标、预期产出、约束条件(时间线、工具、合规要求)、首选渠道。
- 如果用户意图宽泛,先提出默认运营模型,再进行细化。
- 复用references/language-templates.md中的语言提示模板。
2) 提出完整的角色集(然后让用户精简)
- - 为任务生成全面且实用的角色目录。
- 始终包含team-leader作为强制性核心角色。
- 应用references/dialog-flow.md中的自动补全和防过度设计规则。
- 应用references/splitting-principles.md中的拆分/合并标准。
- 将角色标记为:
-
核心(必需)
-
可选(视上下文而定)
-
当前不需要(推迟)
- - 在角色确认阶段,使用用户语言,仅展示角色名称和功能(此阶段不显示智能体ID)。
- 在进行任何构建步骤之前,要求用户确认添加/删除。
- 对于角色建议,使用references/role-catalog.md作为基准模式。
- 仅在最终创建报告中展示:角色名称 + 智能体ID + 职责。
3) 定义每个智能体合约
为每个确认的角色定义:
- - 智能体ID(稳定、简短、小写连字符)
- team-leader的ID必须以团队为前缀(例如 <团队>-team-leader)
- 角色使命
- 消耗的输入
- 产生的输出
- 决策权限
- 上游/下游依赖关系
- 升级目标
使用references/output-templates.md中的表格格式。
4) 定义协作协议(必须明确)
不要依赖模糊的协同工作指令。需明确:
- - 任务委派信封(目标、上下文、可交付成果、截止日期)
- 状态状态(已接受、受阻、已完成)
- 完成回调要求(明确返回给委派者)
- 长任务更新节奏
- 超时/重试/升级策略
- 无原始批量输出规则(仅摘要 + 工件路径)
- 流程中可见性:展示每个阶段谁在做什么
使用references/collaboration-protocol.md。
5) 生成实施 + 配置包
返回一个具体的可执行包:
- 1. 团队名册和职责
- 智能体交互流程(有序步骤)
- 协作协议摘要
- 需要创建/更新的文件(SOUL/AGENTS/IDENTITY指导片段)
- 配置计划(每个角色的工具/技能/权限)
- 团队创建报告(强制性;包含阶段交付物+路径以及安全检查摘要)
- 渠道绑定蓝图(报告后自动提供)
- 冒烟测试脚本(简单的端到端验证提示)
强制性执行路径(程序化,非仅提示):
- - 运行单一入口点:scripts/create_team.mjs
- 此入口点必须在内部执行:物化 -> 验证 -> 生成报告
- 如果验证 != 就绪,必须返回部分就绪/受阻状态并停止
强制性:通过references/materialization-checklist.md运行创建后物化检查。
如果角色文件仍为占位符,不得将团队标记为就绪。
使用:
- - references/capability-matrix.md
- references/permission-profiles.md
- references/provisioning-playbook.md
- references/final-deliverable-sample.md
- references/channel-binding-blueprints.md
- references/materialization-checklist.md
6) 安全执行护栏
在任何产生外部影响的操作之前,应用此确认策略:
- 在openclaw.json中创建/更新智能体
- 设置A2A/子智能体权限
- - 渠道/机器人凭证绑定及其他不可逆的外部影响需要确认。
对于技能安装,先运行安全预检,并阻止高风险项。
在创建流程中切勿自动重启网关。如需重启,先询问用户或提供手动重启说明。
如有任何歧义,暂停并询问。
7) 故障处理与恢复
当设置/协作失败时,应用references/failure-modes.md。
优先快速恢复,最小化影响范围:
- - 保留已完成的工作
- 从上一个检查点恢复
- 保持用户状态准确(就绪 vs 部分就绪)
- 切勿自动安装未通过安全检查的技能
质量标准
- - 宁可选边界清晰的少量角色,也不要大量重叠的角色。
- 每个角色必须有可衡量的产出。
- 每个依赖关系必须有返回路径。
- 交付物必须可由操作员立即执行。
- 角色文档必须足够丰富以代表领域专家行为(非一行占位符)。
- team-leader必须仅负责编排,不得产生专家实施交付物。
- 所有专家产出必须保存在团队共享目录下。
- 当用户目标与已知团队原型匹配时,复用references/examples.md中的模式。
创建阶段详情
角色确认后,严格遵循references/create-playbook.md。
使用references/snippet-templates.md生成可复用的SOUL/AGENTS附加片段。
使用references/final-deliverable-sample.md格式化最终用户交接。
资源
- - references/role-catalog.md:跨领域角色起始集。
- references/role-display-mapping.json:基于区域设置的角色显示名称(用于确认阶段)。
- references/dialog-flow.md:最小提问发现流程和自动补全规则。
- references/language-templates.md:双语/区域设置感知的提示模板。
- references/splitting-principles.md:发现阶段何时拆分/合并角色。
- references/examples.md:常见团队原型的端到端示例。
- references/channel-binding-blueprints.md:单机器人 vs 多机器人组绑定方案和群组配置指南。
- references/capability-matrix.md:角色到工具/技能的映射基准。
- references/permission-profiles.md:最小权限配置文件。
- references/provisioning-playbook.md:自动安装 + 权限设置流程(含技能审查优先的安全扫描)。
- references/security-report-schema.md:机器可读的安全报告和安装决策模式。
- references/collaboration-protocol.md:明确的多智能体协调协议。
- references/output-templates.md:最终输出模板和检查清单。
- references/create-playbook.md:可执行的创建序列。
- references/snippet-templates.md:可复用的注入/确认片段。
- references/role-soul-blueprints.md:每个角色的专家级SOUL深度蓝图。
- references/team-leader-template.md:固定的team-leader SOUL模板(创建时复制)。
- references/team-leader-agents-template.md:固定的team-leader AGENTS模板(创建时复制)。
- references/final-deliverable-sample.md:标准化的用户交接格式。
- references/failure-modes.md:故障场景和恢复操作。
- references/materialization-checklist.md:创建后角色文件完成度检查门。
- references/config-materialization-checklist.md:强制性的openclaw.json智能体/绑定/A2A完成度检查门。