Council Builder
Build a team of specialized AI agent personas tailored to the user's actual needs. Each agent gets a distinct personality, self-improvement capability, and clear coordination rules.
Workflow
Phase 1: Discovery
Interview the user to understand their world. Ask in batches of 2-3 questions max.
Round 1 - Identity:
- - What do you do? (profession, main activities, industry)
- What tools and platforms do you use daily?
Round 2 - Pain Points:
- - What tasks eat most of your time?
- Where do you feel you need the most help?
Round 3 - Preferences:
- - What language(s) do you work in? (for agent communication style)
- Any specific domains you want covered? (coding, content, finance, research, scheduling, etc.)
Optional - History Analysis:
If the user has existing OpenClaw history, scan it for patterns:
- - Check
memory/ files for recurring tasks - Check existing workspace structure for active projects
- Check installed skills for current capabilities
Do NOT proceed to Phase 2 until confident you understand the user's needs. Ask follow-up questions if anything is unclear.
Phase 2: Planning
Based on discovery, design the council:
- 1. Determine agent count: 3-7 agents. Fewer is better. Each agent must earn its existence.
- Define each agent: Name, role, specialties, personality angle
- Map coordination: Which agents feed data to which
- Present the plan to the user in a clear table:
CODEBLOCK0
- 5. Get explicit approval before building. Allow adjustments.
Naming agents:
- - Give them memorable, short names (not generic like "Agent 1")
- Names should hint at their role but feel like characters
- Can be inspired by any theme the user likes, or choose strong standalone names
- See
references/example-councils.md for naming patterns and complete council examples across different industries
Phase 3: Building
Run the initialization script first to create the directory skeleton:
CODEBLOCK1
Then, for each approved agent, populate the files. Read references/soul-philosophy.md before writing any SOUL.md.
Directory structure per agent:
CODEBLOCK2
For each agent's SOUL.md:
- 1. Read
references/soul-philosophy.md for the writing guide - Read
assets/SOUL-TEMPLATE.md for the structure - Customize deeply for this agent's role and personality
- Every SOUL must be unique. No copy-paste between agents.
For each agent's AGENTS.md:
- 1. Use
assets/AGENT-AGENTS-TEMPLATE.md as base - Define what this agent reads from and writes to
- Define handoff rules with other agents
For gotchas.md:
- 1. Use
assets/GOTCHAS-TEMPLATE.md as base - Populate with 1-2 known pitfalls specific to this agent's domain
- See
references/gotchas-patterns.md for examples
For config.json:
- 1. Use
assets/CONFIG-TEMPLATE.json as base - Set agentname, leave setupcomplete as false
- See
references/config-patterns.md for role-specific examples
For scripts/:
- 1. Create role-specific starter scripts (see
references/agent-scripts-patterns.md) - At minimum, create a verification script for the agent's output type
- Include a README.md listing what each script does
For references/:
- 1. Create
verification-checklist.md using INLINECODE12 - Optionally create
domain-guide.md and common-patterns.md with role-specific content
For hooks/ (optional):
- 1. See
references/hooks-patterns.md for the pattern - Create hooks relevant to the agent's risk profile
- Not every agent needs hooks; focus on agents with destructive capabilities
For .learnings/ files:
- 1. Copy structure from INLINECODE16
- Initialize empty log files
For the root AGENTS.md:
- 1. Use
assets/ROOT-AGENTS-TEMPLATE.md as base - Create the routing table for all agents
- Define file coordination map
- Set up enforcement rules
- Add adaptive model routing thresholds (Fast, Think, Deep, Strategic)
Phase 4: Adaptive Routing Setup
Read references/adaptive-routing.md.
Set up an adaptive routing section in root AGENTS.md:
- - Default to Fast
- Escalation thresholds for Think, Deep, Strategic
- De-escalation rule back to Fast after heavy reasoning
- High-tier model rate-limit fallback behavior
Also create visual architecture doc:
- -
docs/architecture/ADAPTIVE-ROUTING-LEARNING.md using INLINECODE20
Phase 5: Self-Improvement Setup
Read references/self-improvement.md for the complete system.
Each agent gets built-in self-improvement:
- -
.learnings/ directory with proper templates - Detection triggers in SOUL.md (corrections, errors, gaps)
- Promotion rules (learning → SOUL.md / AGENTS.md / TOOLS.md)
- Cross-agent learning sharing via INLINECODE23
- Periodic review instructions
- Weekly learning metrics file at
memory/learning-metrics.json (use assets/LEARNING-METRICS-TEMPLATE.json)
Phase 6: Verification
After building everything:
- 1. List all created files for the user
- Show the routing table
- Show the coordination map
- Confirm everything is in place
Phase 7: Expansion (On-Demand)
When the user asks to add, modify, or remove agents:
Adding an agent:
- 1. Mini-discovery: What does this agent need to do?
- Create full agent structure (same as Phase 3)
- Update root AGENTS.md routing table
- Update coordination map
Modifying an agent:
- 1. Read the current SOUL.md
- Apply changes while preserving personality consistency
- Update related coordination rules if needed
Removing an agent:
- 1. Ask for confirmation
- Reassign the agent's responsibilities to other agents
- Update routing table and coordination map
- Move agent files to trash (never delete)
Key Principles
- 1. Each agent is a character, not a template. Different personality, different voice, different strengths. If two agents sound the same, one shouldn't exist.
- 2. No corporate language in any SOUL. See
references/soul-philosophy.md. This is non-negotiable.
- 3. Self-improvement is mandatory. Every agent logs mistakes and learns. See
references/self-improvement.md.
- 4. Coordination through files. Agents communicate via shared directories, not direct messaging. Each agent has clear read/write boundaries.
- 5. Brevity in everything. SOULs, AGENTS files, templates. Respect the context window.
- 6. The user's main assistant is the coordinator. It routes tasks, not the agents themselves.
- 7. Language-adaptive. Write SOULs in whatever language the user works in. Arabic, English, bilingual, whatever fits their world.
- 8. Adaptive routing by default. Every generated council should include Fast/Think/Deep/Strategic model routing thresholds.
- 9. Metrics over vibes. Weekly learning review must be measured in
memory/learning-metrics.json.
- 10. Architecture must be visual. Generate a concise architecture doc at
docs/architecture/ADAPTIVE-ROUTING-LEARNING.md for training and onboarding.
议会构建器
根据用户的实际需求,组建一支由专业AI代理角色构成的团队。每个代理都拥有独特的个性、自我改进能力以及清晰的协调规则。
工作流程
第一阶段:探索
通过访谈了解用户的世界。每次最多分批提出2-3个问题。
第一轮:身份识别
- - 你从事什么工作?(职业、主要活动、行业)
- 你日常使用哪些工具和平台?
第二轮:痛点分析
- - 哪些任务占用了你大部分时间?
- 你觉得在哪些方面最需要帮助?
第三轮:偏好设定
- - 你使用什么语言工作?(用于代理沟通风格)
- 你希望涵盖哪些特定领域?(编程、内容创作、金融、研究、日程安排等)
可选:历史分析
如果用户有现有的OpenClaw历史记录,扫描其中的模式:
- - 检查memory/文件中的重复任务
- 检查现有工作区结构中的活跃项目
- 检查已安装技能中的当前能力
在确信理解用户需求之前,不要进入第二阶段。如有任何不清楚的地方,请提出后续问题。
第二阶段:规划
基于探索结果,设计议会:
- 1. 确定代理数量:3-7个代理。越少越好。每个代理必须证明其存在的价值。
- 定义每个代理:名称、角色、专长、个性角度
- 映射协调关系:哪些代理向哪些代理提供数据
- 以清晰的表格向用户呈现计划:
| 代理 | 角色 | 专长 | 个性 |
|---|
| [名称] | [一句话角色] | [关键领域] | [个性角度] |
- 5. 在构建前获得明确批准。允许调整。
代理命名:
- - 赋予它们易记、简短的名字(不要像代理1这样通用)
- 名字应暗示其角色,但感觉像角色人物
- 可以受用户喜欢的任何主题启发,或选择有力的独立名称
- 参见references/example-councils.md了解不同行业的命名模式和完整议会示例
第三阶段:构建
首先运行初始化脚本以创建目录骨架:
bash
./scripts/init-council.sh <工作区路径> <代理名称-1> <代理名称-2> ...
然后,为每个已批准的代理填充文件。在编写任何SOUL.md之前,先阅读references/soul-philosophy.md。
每个代理的目录结构:
agents/[代理名称]/
├── SOUL.md # 个性、角色、规则(参见soul-philosophy.md)
├── AGENTS.md # 代理特定的协调规则
├── memory/ # 代理的记忆目录
├── .learnings/ # 自我改进日志
│ ├── LEARNINGS.md
│ ├── ERRORS.md
│ └── FEATURE_REQUESTS.md
└── [工作区目录] # 角色特定的输出目录
每个代理的SOUL.md:
- 1. 阅读references/soul-philosophy.md了解编写指南
- 阅读assets/SOUL-TEMPLATE.md了解结构
- 为该代理的角色和个性进行深度定制
- 每个SOUL必须独一无二。代理之间不得复制粘贴。
每个代理的AGENTS.md:
- 1. 使用assets/AGENT-AGENTS-TEMPLATE.md作为基础
- 定义该代理读取和写入的内容
- 定义与其他代理的交接规则
gotchas.md:
- 1. 使用assets/GOTCHAS-TEMPLATE.md作为基础
- 填充1-2个该代理领域特有的已知陷阱
- 参见references/gotchas-patterns.md获取示例
config.json:
- 1. 使用assets/CONFIG-TEMPLATE.json作为基础
- 设置agentname,将setupcomplete保留为false
- 参见references/config-patterns.md获取角色特定示例
scripts/:
- 1. 创建角色特定的启动脚本(参见references/agent-scripts-patterns.md)
- 至少为该代理的输出类型创建一个验证脚本
- 包含一个README.md,列出每个脚本的功能
references/:
- 1. 使用assets/VERIFICATION-CHECKLIST-TEMPLATE.md创建verification-checklist.md
- 可选地创建包含角色特定内容的domain-guide.md和common-patterns.md
hooks/(可选):
- 1. 参见references/hooks-patterns.md了解模式
- 创建与该代理风险概况相关的钩子
- 并非每个代理都需要钩子;重点关注具有破坏性能力的代理
.learnings/文件:
- 1. 从assets/LEARNINGS-TEMPLATE.md复制结构
- 初始化空的日志文件
根目录AGENTS.md:
- 1. 使用assets/ROOT-AGENTS-TEMPLATE.md作为基础
- 创建所有代理的路由表
- 定义文件协调映射
- 设置执行规则
- 添加自适应模型路由阈值(快速、思考、深度、战略)
第四阶段:自适应路由设置
阅读references/adaptive-routing.md。
在根目录AGENTS.md中设置自适应路由部分:
- - 默认使用快速模式
- 升级到思考、深度、战略模式的阈值
- 深度推理后降级回快速模式的规则
- 高级模型速率限制的降级行为
同时创建可视化架构文档:
- - 使用assets/ADAPTIVE-ROUTING-LEARNING-TEMPLATE.md创建docs/architecture/ADAPTIVE-ROUTING-LEARNING.md
第五阶段:自我改进设置
阅读references/self-improvement.md了解完整系统。
每个代理都内置自我改进功能:
- - 带有适当模板的.learnings/目录
- SOUL.md中的检测触发器(修正、错误、差距)
- 升级规则(学习 → SOUL.md / AGENTS.md / TOOLS.md)
- 通过shared/learnings/CROSS-AGENT.md进行跨代理学习共享
- 定期审查说明
- 位于memory/learning-metrics.json的每周学习指标文件(使用assets/LEARNING-METRICS-TEMPLATE.json)
第六阶段:验证
构建完所有内容后:
- 1. 向用户列出所有创建的文件
- 显示路由表
- 显示协调映射
- 确认一切就绪
第七阶段:扩展(按需)
当用户要求添加、修改或移除代理时:
添加代理:
- 1. 小型探索:这个代理需要做什么?
- 创建完整的代理结构(与第三阶段相同)
- 更新根目录AGENTS.md路由表
- 更新协调映射
修改代理:
- 1. 读取当前的SOUL.md
- 应用更改,同时保持个性一致性
- 如有需要,更新相关协调规则
移除代理:
- 1. 请求确认
- 将该代理的职责重新分配给其他代理
- 更新路由表和协调映射
- 将代理文件移至回收站(切勿删除)
关键原则
- 1. 每个代理都是一个角色,而不是模板。 不同的个性、不同的声音、不同的优势。如果两个代理听起来一样,其中一个就不应该存在。
- 2. 任何SOUL中不得使用企业语言。 参见references/soul-philosophy.md。这是不可协商的。
- 3. 自我改进是强制性的。 每个代理都要记录错误并学习。参见references/self-improvement.md。
- 4. 通过文件进行协调。 代理通过共享目录进行通信,而非直接消息。每个代理都有清晰的读/写边界。
- 5. 一切从简。 SOUL、AGENTS文件、模板。尊重上下文窗口。
- 6. 用户的主要助手是协调者。 它负责路由任务,而非代理本身。
- 7. 语言自适应。 用用户使用的任何语言编写SOUL。阿拉伯语、英语、双语,任何适合他们世界的语言。
- 8. 默认使用自适应路由。 每个生成的议会都应包含快速/思考/深度/战略模型路由阈值。
- 9. 指标胜于感觉。 每周学习审查必须通过memory/learning-metrics.json进行衡量。
- 10. 架构必须可视化。 在docs/architecture/ADAPTIVE-ROUTING-LEARNING.md中生成简洁的架构文档,用于培训和入职。