Team Builder

Team Builder

Deploy a reusable multi-agent SaaS/growth team template on OpenClaw in one shot.

System Impact & Prerequisites

Read before running. This skill creates files and modifies system config.

What it creates

• A new workspace directory with ~40 files (agent configs, shared knowledge, inboxes, kanban)
• apply-config.js -- script that modifies ~/.openclaw/openclaw.json (adds agents, bindings, agentToAgent config). Auto-backs up before writing.
• create-crons.ps1 / create-crons.sh -- scripts that create cron jobs via openclaw cron add
• After running these scripts you must restart the gateway (openclaw gateway restart)

What it does NOT do automatically

• Does not modify openclaw.json directly -- you run apply-config.js yourself
• Does not create cron jobs directly -- you run the cron script yourself
• Does not restart the gateway -- you do that manually

Optional: Telegram

• If you provide bot tokens during setup, apply-config.js will also add Telegram account configs and bindings
• Requires: Telegram bot tokens from @BotFather, your Telegram user ID
• Requires: network access to Telegram API (proxy configurable)

Optional: ACP / Claude Code

• The fullstack-dev agent is configured as the implementation-focused Claude coding role
• Current production path is claude only
• Preferred execution modes: simple direct, medium Claude ACP run or direct acpx, complex work via existing fullstack-dev continuity + context files
• Do not assume IM-bound ACP session persistence is available

Credentials involved

• Telegram bot tokens (optional) -- stored in openclaw.json, used for agent-to-Telegram binding
• Model API keys -- must already be configured in your OpenClaw model providers (not handled by this skill)

Recommended

• Review generated apply-config.js before running
• Check the backup of openclaw.json after running
• Test with 2-3 agents before enabling all cron jobs

Team Architecture

Default reference architecture for a SaaS/growth multi-agent team (customizable to 2-10 agents):

CEO
 |-- Chief of Staff (dispatch + strategy + efficiency)
 |-- Data Analyst (data + user research)
 |-- Growth Lead (GEO + SEO + community + social media)
 |-- Content Chief (strategy + writing + copywriting + i18n)
 |-- Intel Analyst (competitor monitoring + market trends)
 |-- Product Lead (product management + tech architecture)
 |-- DevOps (delivery / deploy / environment / acceptance)
 |-- Fullstack Dev (implementation / module deep dive / ACP coding session)

Multi-Team Support

One OpenClaw instance can run multiple teams:

node <skill-dir>/scripts/deploy.js                  # default team
node <skill-dir>/scripts/deploy.js --team alpha      # named team "alpha"
node <skill-dir>/scripts/deploy.js --team beta       # named team "beta"

Named teams use prefixed agent IDs (alpha-chief-of-staff, beta-growth-lead) to avoid conflicts. Each team gets its own workspace subdirectory.

Flexible Team Size

The wizard lets you select 2-10 agents from the available roles. Skip roles you don't need. The 8-agent default covers most SaaS scenarios with dual-dev routing, but you can run leaner (3-4 agents) or expand with custom roles.

Model Auto-Detection

The wizard scans your openclaw.json for registered model providers and auto-suggests models by role type:

You can always override with manual model IDs.

Setup / Config / Scripts

Required Inputs

• Team name
• Workspace dir
• Timezone
• Morning brief hour
• Evening brief hour
• Thinking model
• Execution model
• CEO title

Optional Inputs

• Telegram user ID
• Telegram bot tokens
• Proxy
• ACP coding agent（给 fullstack-dev 使用）

Core Scripts

node <skill-dir>/scripts/deploy.js
node <workspace-dir>/apply-config.js
powershell <workspace-dir>/create-crons.ps1
bash <workspace-dir>/create-crons.sh
openclaw gateway restart

Execution Priority

• First: matched execution skill (for coding work, coding-lead if loaded)
• Second: agent-role fallback when no matching skill is loaded
• Third: templates/README explain boundaries and ownership only; they should not override matched skills

Context File Hygiene

• Active context files live under <project>/.openclaw/
• Reuse one context file per active code chain when possible
• Naming pattern: context-<task-slug>.md
• Active context file cap per project: 60
• Context-file lifecycle window per project: 100 total files across active + archive
• Completed or stale files should be deleted or moved to .openclaw/archive/

Current Dual-Dev Standard

• fullstack-dev：实现、模块深挖、开发文档、接口文档、Claude coding 执行；默认 coding skill 可采用 coding-lead，其中 simple 任务直做，medium 倾向 Claude ACP run 或 direct acpx，complex 通过现有会话连续协作 + 上下文文件推进，不把 ACP session 持久线程作为正式主路径；context 活跃上限 60、生命周期总窗口 100；并行允许但必须先定义边界，总上限 5 个工作单元
• devops：交付、部署、环境、回归、冒烟、自动QA、发布门禁
• product-lead：澄清、PRD、验收标准，不完整不得派工
• chief-of-staff：路由、裁决、控制 token 浪费

Deployment Flow

Step 1: Collect Configuration

Ask the user for these inputs (use defaults if not provided):

Optional: Telegram user ID, proxy, and 7 bot tokens.

Step 2: Run Deploy Script

node <skill-dir>/scripts/deploy.js

Interactive -- asks all questions from Step 1, generates the full workspace.

Step 2b: Non-interactive / Verify Mode

Prepare a JSON config file:

{
  "teamName": "Alpha Team",
  "workspaceDir": "~/.openclaw/workspace-team",
  "timezone": "Asia/Shanghai",
  "morningHour": 8,
  "eveningHour": 18,
  "thinkingModel": "zai/glm-5",
  "executionModel": "zai/glm-4.7",
  "ceoTitle": "Boss",
  "roles": ["chief-of-staff","data-analyst","growth-lead","content-chief","intel-analyst","product-lead","devops","fullstack-dev"]
}

Run:

node <skill-dir>/scripts/deploy.js --config team-builder.json
node <skill-dir>/scripts/deploy.js --verify --config team-builder.json

--verify checks that generated files contain the expected dual-dev model, role ownership, and cron entries.

Step 3: Apply Config

node <workspace-dir>/apply-config.js

Adds agents to openclaw.json, preserving existing config.

Step 4: Create Cron Jobs

# Windows
powershell <workspace-dir>/create-crons.ps1

# Linux/Mac
bash <workspace-dir>/create-crons.sh

Step 5: Restart Gateway

openclaw gateway restart

Step 6: Fill Business Info

User must edit:

• shared/decisions/active.md -- strategy, priorities
• shared/products/_index.md -- products overview (≤5 lines per product: URL, code path, positioning, tech, status). Detailed info goes in each product's overview.md.
• shared/knowledge/competitor-map.md -- competitor analysis
• shared/knowledge/tech-standards.md -- coding standards

Step 7: Trigger Deep Dive Scans

After filling in products with code directories, tell product-lead to trigger Deep Dive scans:

1. Product-lead sends delivery-oriented scan requests to devops via inbox
2. Devops enters each project directory and generates shared knowledge / deployment-oriented scan outputs
3. Fullstack-dev picks up module-level deep dive or implementation follow-up when needed
4. Product-lead reviews the generated files for completeness and acceptance impact
5. All agents now have deep project understanding for informed decisions

Cron Schedule

(H = morning brief hour)

Generated File Structure

<workspace>/
├── AGENTS.md, SOUL.md, USER.md  (auto-injected)
├── apply-config.js, create-crons.ps1/.sh, README.md
├── agents/<8 agent dirs>/       (SOUL.md + MEMORY.md + memory/)
└── shared/
    ├── briefings/, decisions/, inbox/ (v2: with status tracking)
    ├── status/team-dashboard.md     (chief-of-staff maintains, all agents read first)
    ├── data/                        (public data pool, data-analyst writes, all read)
    ├── kanban/, knowledge/
    └── products/
        ├── _index.md                (product matrix overview)
        ├── _template/               (knowledge directory template)
        └── {product}/               (per-product knowledge, up to 20 files)
            ├── overview.md, architecture.md, database.md, api.md, routes.md
            ├── models.md, services.md, frontend.md, auth.md, integrations.md
            ├── jobs-events.md, config-env.md, dependencies.md, devops.md
            ├── test-coverage.md, tech-debt.md, domain-flows.md, data-flow.md
            ├── i18n.md, changelog.md, notes.md

Knowledge Governance

Each shared knowledge file has a designated owner. Only the owner agent updates it; others read only.

Update Protocol

When updating a knowledge file, the owner must:

1. Add a dated entry at the top: ## [YYYY-MM-DD] <what changed>
2. Include the reason and data evidence
3. Never delete existing entries without CEO approval (append, don't replace)

Chief of Staff Governance

The chief-of-staff monitors knowledge file health during weekly reviews:

• Are files being updated regularly?
• Any conflicting information between files?
• Any stale entries that should be archived?

Self-Evolution Pattern

Agents improve their own strategies over time through a feedback loop:

1. Execute task (cron or inbox triggered)
2. Collect results (data, metrics, outcomes)
3. Analyze: what worked vs what didn't
4. Update knowledge files with proven strategies (with evidence)
5. Next execution reads updated knowledge → better performance

This is NOT the agent randomly changing rules. Updates must be:

• Data-driven: backed by metrics or concrete outcomes
• Incremental: append new findings, don't rewrite everything
• Traceable: dated with evidence so others can verify

What Agents Can Self-Update

• Their own knowledge files (per ownership table above)
• Their own MEMORY.md (lessons learned, decisions)
• shared/data/ outputs (data-analyst only)

What Requires CEO Approval

• shared/decisions/active.md (strategy changes)
• Adding/removing agents or changing team architecture
• External publishing or spending decisions

Public Data Layer

The shared/data/ directory serves as a read-only data pool for all agents:

• data-analyst writes: daily metrics, user feedback summaries, anomaly alerts
• All agents read: to inform their own decisions
• Format: structured markdown or JSON, dated filenames (e.g., metrics-2026-03-01.md)
• Retention: keep 30 days, archive older files

Project Deep Dive — Code Scanning

Agents can deeply understand each SaaS product through automated code scanning. This is critical — without deep project knowledge, all team decisions are surface-level.

How It Works

1. CEO adds a product to shared/products/_index.md (name, URL, code directory, tech stack)
2. Product Lead triggers a delivery-oriented Deep Dive scan by messaging DevOps via inbox
3. DevOps enters the project directory (read-only) and generates shared knowledge / delivery-oriented scan outputs
4. Fullstack Dev picks up module-level deep dive or implementation follow-up when needed
5. Knowledge files are generated in shared/products/{product}/
6. All agents consume these files via manifest-based lazy loading (never read all at once)