Team Builder

一条命令部署完整多 Agent 团队骨架，包含角色、信箱、看板、产品知识目录、cron 巡检、双开发轨模板。

详细安装步骤和首次配置引导见 README.md（中文完整版）。

前置条件

• OpenClaw 已安装并运行
• Node.js 16+
• 已配置至少一个模型 provider

此技能会修改系统配置：apply-config.js 会写入 openclaw.json，create-crons.* 会创建 cron 任务。均需手动执行，不自动运行。

Internal Dispatch Protocol (MANDATORY)

• Standard agents (product-lead, growth-lead, intel-analyst, devops, etc.): sessions_spawn(runtime="subagent", mode="run") — 禁止带 streamTo
• ACP agents (fullstack-dev): sessions_spawn(runtime="acp") — 可带 streamTo="parent"
• 结果通过 auto-announce 推送；不要轮询 sessions_list 或 subagents list
• chief-of-staff 是群内唯一入口；其他 agent 内部 spawn，不直接监听群聊
• 详见 shared/knowledge/team-workflow.md 零章

参谋长执行边界（MANDATORY）

• 参谋长不下地干活：任何多步骤任务（编码、调研、分析、内容、部署）→ 全部派给对应 agent
• 参谋长不亲自开子代理干活：spawn 子代理执行具体业务 = 等价于自己干活
• 参谋长做且只做：任务拆解（L1-L4 复杂度判断）、编排、派活、监控、结果汇总
• 先执行后汇报；默认输出只保留：已做什么 / 拿到什么结果 / 卡在哪里

子代理使用规则（MANDATORY，全团队适用）

• 优先主 agent 自己干：干得过来时不开子代理
• 分析透再派：开子代理前必须先分析清楚边界/依赖/输入输出
• 子代理只做原子任务：一句话说清、执行完就结束，不做判断或策略决策
• 主 agent 全权负责：判断、策略、经验积累——子代理不做这三件
• 子代理结果由主 agent 汇总后再上报参谋长

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 浪费

部署流程

完整步骤见 README.md。以下是关键参数选取对照表。

必填参数

可选参数

• roles：自定义角色列表（默认全郥 8 个）
• roleNames：自定义角色名称（如中文起名）
• --team <prefix>：多团队并存时用于隔离角色 ID
• Telegram bot tokens（可选，配置后自动写入 openclaw.json）

核心命令

# 交互式生成
node <skill-dir>/scripts/deploy.js

# 非交互生成
node <skill-dir>/scripts/deploy.js --config team-builder.json

# 验证生成结果
node <skill-dir>/scripts/deploy.js --verify --config team-builder.json

# 应用配置（写入 openclaw.json）
node <workspace-dir>/apply-config.js

# 创建 cron
powershell <workspace-dir>/create-crons.ps1  # Windows
bash <workspace-dir>/create-crons.sh          # macOS/Linux

# 重启
openclaw gateway restart

--verify 检查生成物是否包含双开发模型、角色归属、cron 条目。

完整安装步骤见 README.md。

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 dispatching to DevOps (via sessions_spawn if online, inbox as fallback)
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)

Manifest-Based Lazy Loading (MANDATORY)

Each product directory includes a manifest.json (~200 tokens) that lists all files with one-line summaries and a taskFileMap mapping task types to relevant files.

Agent workflow:

1. Read _index.md → identify which product
2. Read {product}/manifest.json → see all files + summaries (~200 tokens)
3. Based on taskFileMap or summaries, read only 1-3 relevant files
4. Never read more than 5 product files per session

Why: With 15+ products × 20 files each, full loading = 40K+ tokens per product. Manifest loading = 200 tokens + only what's needed.

DevOps MUST regenerate manifest.json after every delivery-oriented scan (L0-L4). Fullstack Dev updates it when doing module-level follow-up that changes knowledge scope. Template in _template/manifest.json.

Manifest Quality Standards

摘要不能为了省 token 丢掉关键信息。每条摘要须满足:

• 核心文件(database/models/services/routes/integrations):50-130字,列出关键实体名/数量/域名
• 中等文件(auth/frontend/commands/config):30-80字,点明方案和范围
• 轻量文件(changelog/notes/metrics):可以短(<20字)
• taskFileMap:必须覆盖该产品的所有核心业务场景(不少于8个映射)
• codeStats:必须包含文件数、行数、模型数、表数等量化指标

Product Knowledge Directory

Each product gets a knowledge directory with up to 20 files + manifest:

shared/products/{product}/
├── manifest.json        ← **INDEX** (~200 tokens): file list, summaries, taskFileMap
├── overview.md          ← Product positioning (from _index.md)
├── architecture.md      ← System architecture, tech stack, design patterns, layering
├── database.md          ← Full table schema, relationships, indexes, migrations
├── api.md               ← API endpoints, params, auth, versioning
├── routes.md            ← Complete route table (Web + API + Console)
├── models.md            ← ORM relationships, scopes, accessors, observers
├── services.md          ← Business logic, state machines, workflows, validation
├── frontend.md          ← Component tree, page routing, state management
├── auth.md              ← Auth scheme, roles/permissions matrix, OAuth
├── integrations.md      ← Third-party: payment/email/SMS/storage/CDN/analytics
├── jobs-events.md       ← Queue jobs, event listeners, scheduled tasks, notifications
├── config-env.md        ← Environment variables, feature flags, cache strategy
├── dependencies.md      ← Key dependencies, custom packages, vulnerabilities
├── devops.md            ← Deployment, CI/CD, Docker, monitoring, logging
├── test-coverage.md     ← Test strategy, coverage, weak spots
├── tech-debt.md         ← TODO/FIXME/HACK inventory, dead code, complexity hotspots
├── domain-flows.md      ← Core user journeys, domain boundaries, module coupling
├── data-flow.md         ← Data lifecycle: external → import → process → store → output
├── i18n.md              ← Internationalization, language coverage
├── changelog.md         ← Scan diff log (what changed between scans)
└── notes.md             ← Agent discoveries, gotchas, implicit rules

Scan Levels

Content Standards

Knowledge files capture not just WHAT exists but WHY:

• Design decisions: Why this approach was chosen
• Implicit business rules: Logic buried in code (e.g., "orders auto-cancel after 72h")
• Gotchas: What breaks if you touch this module carelessly
• Cross-module coupling: Where changing A silently breaks B
• Performance hotspots: N+1 queries, missing indexes, bottleneck endpoints

Role Responsibilities

Per-Stack Auto-Detection

Fullstack Dev auto-detects tech stack and applies stack-specific scan strategies:

• Laravel/PHP: migrations, route:list, Models, Services, Middleware, Policies, Jobs, Console/Kernel
• React/Vue: components, router, stores, API client, i18n
• Python/Django/FastAPI: models.py, urls.py, views.py, middleware, celery
• General: tree, git log, grep TODO/FIXME, .env.example, Docker, CI, tests

Team Coordination v2

Inbox Protocol v2 (backup channel, status tracking)

Primary dispatch: sessions_spawn (real-time). Inbox is for archival, cross-session handoff, and fallback when spawn is unavailable.

Every inbox message now has a status field:

• pending → received → in-progress → done (or blocked)
• Chief-of-staff monitors timeouts: high>4h, normal>24h pending = intervention
• Blocked >8h = escalation to CEO
• Recipients MUST update status immediately upon reading

Team Dashboard (shared/status/team-dashboard.md)

Chief-of-staff maintains a "live scoreboard" updated every session:

• 🔴 Urgent/Blocked items
• 📊 Per-agent status table (last active, current task, status icon)
• 📬 Unprocessed inbox summary (pending/blocked messages across all inboxes)
• 🔗 Cross-agent task chain tracking (A→B→C with per-step status)
• 📅 Today/Tomorrow focus

Agent 启动顺序（内置于 AGENTS.md）：

1. 确认角色
2. 读 agents/[role]/SOUL.md
3. 读 shared/onboarding.md（项目背景，CEO 填写）
4. 读 shared/status/team-dashboard.md（当前状态）
5. 读 shared/decisions/active.md（仅涉及策略时）
6. 读 shared/inbox/to-[role].md
7. 读 agents/[role]/MEMORY.md（仅需历史上下文时）

Chief-of-Staff as Router

The chief is upgraded from "briefing writer" to "active team router":

• Real-time dispatch: uses sessions_spawn(runtime="subagent") to directly wake agents and assign tasks - this is the primary dispatch method
• Blocker detection: scans all inboxes for overdue messages
• Inbox as backup: writes to inbox only for archival, cross-session handoff, or when agent is unreachable
• Task chain tracking: identifies multi-agent workflows and tracks each step
• Escalation: persistent blockers get flagged to CEO
• Runs 4x/day (morning brief, midday patrol, afternoon patrol, evening brief)

Cron Schedule (10 jobs, up from 7)

Why These Changes Matter

Key Design Decisions

• Shared workspace so qmd indexes everything for all agents
• Real-time spawn dispatch as primary inter-agent communication; inbox as backup for archival and cross-session handoff
• Chief as Router - active coordinator who dispatches via sessions_spawn, detects blockers, and resolves them
• Team Dashboard - single source of truth for team-wide status, maintained by chief every session
• GEO as #1 priority (AI search = blue ocean)
• Fullstack Dev spawns Claude Code via ACP for complex implementation tasks
• DevOps owns delivery and QA gate so implementation and release responsibilities stay separated
• Project Deep Dive gives all agents deep codebase understanding, not just surface-level product overviews

Customization

Edit ROLES array in scripts/deploy.js to add/remove agents. Edit references/soul-templates.md for SOUL.md templates. Edit references/shared-templates.md for shared file templates.