Council Builder

---

name: council-builder description: "Build a personalized team of AI agent personas for OpenClaw. Interviews the user, analyzes their workflow, then creates specialized agents with distinct personalities, adaptive model routing (Fast/Think/Deep/Strategic), weekly learning metrics, visual architecture docs, and inter-agent coordination. USE WHEN: user wants to create an agent team/council, build specialized AI personas, set up multi-agent workflows, 'build me a team of agents', 'create agents for my workflow', 'set up an agent council', 'I want specialized AI assistants', 'build me a crew'. DON'T USE WHEN: user wants a single skill (use skill-creator), wants to install existing skills (use clawhub), or wants to chat with existing agents (just route to them)."

---

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. 2. Define each agent: Name, role, specialties, personality angle 3. Map coordination: Which agents feed data to which 4. Present the plan to the user in a clear table:

| Agent | Role | Specialties | Personality |
|-------|------|-------------|-------------|
| [Name] | [One-line role] | [Key areas] | [Personality angle] |

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:

./scripts/init-council.sh    ...

Then, for each approved agent, populate the files. Read references/soul-philosophy.md before writing any SOUL.md.

Directory structure per agent:

agents/[agent-name]/
├── SOUL.md           # Personality, role, rules (see soul-philosophy.md)
├── AGENTS.md         # Agent-specific coordination rules
├── memory/           # Agent's memory directory
├── .learnings/       # Self-improvement logs
│   ├── LEARNINGS.md
│   ├── ERRORS.md
│   └── FEATURE_REQUESTS.md
└── [workspace dirs]  # Role-specific output directories

For each agent's SOUL.md: 1. Read references/soul-philosophy.md for the writing guide 2. Read assets/SOUL-TEMPLATE.md for the structure 3. Customize deeply for this agent's role and personality 4. 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 2. Define what this agent reads from and writes to 3. Define handoff rules with other agents

For gotchas.md: 1. Use assets/GOTCHAS-TEMPLATE.md as base 2. Populate with 1-2 known pitfalls specific to this agent's domain 3. See references/gotchas-patterns.md for examples

For config.json: 1. Use assets/CONFIG-TEMPLATE.json as base 2. Set agent_name, leave setup_complete as false 3. See references/config-patterns.md for role-specific examples

For scripts/: 1. Create role-specific starter scripts (see references/agent-scripts-patterns.md) 2. At minimum, create a verification script for the agent's output type 3. Include a README.md listing what each script does

For references/: 1. Create verification-checklist.md using assets/VERIFICATION-CHECKLIST-TEMPLATE.md 2. 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 2. Create hooks relevant to the agent's risk profile 3. Not every agent needs hooks; focus on agents with destructive capabilities

For .learnings/ files: 1. Copy structure from assets/LEARNINGS-TEMPLATE.md 2. Initialize empty log files

For the root AGENTS.md: 1. Use assets/ROOT-AGENTS-TEMPLATE.md as base 2. Create the routing table for all agents 3. Define file coordination map 4. Set up enforcement rules 5. 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 assets/ADAPTIVE-ROUTING-LEARNING-TEMPLATE.md

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 shared/learnings/CROSS-AGENT.md

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 2. Show the routing table 3. Show the coordination map 4. 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? 2. Create full agent structure (same as Phase 3) 3. Update root AGENTS.md routing table 4. Update coordination map

Modifying an agent: 1. Read the current SOUL.md 2. Apply changes while preserving personality consistency 3. Update related coordination rules if needed

Removing an agent: 1. Ask for confirmation 2. Reassign the agent's responsibilities to other agents 3. Update routing table and coordination map 4. 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.