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:

| Role Type | Best For | Auto-detect Pattern |

|-----------|----------|-------------------|

| Thinking | Strategic roles (chief, growth, content, product) | /glm-5\|opus\|o1\|deepthink/i |

| Execution | Operational roles (data, intel, fullstack) | /glm-4\|sonnet\|gpt-4/i |

| Fast | Lightweight tasks | /flash\|haiku\|mini/i |

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 /.openclaw/
• Reuse one context file per active code chain when possible
• Naming pattern: context-.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。以下是关键参数选取对照表。

必填参数

| 参数 | 默认值 | 说明 |

|--------|--------|------|

| teamName | Alpha Team | 团队名 |

| workspaceDir | ~/.openclaw/workspace-team | 工作区路径 |

| timezone | Asia/Shanghai | cron 时区 |

| morningHour | 8 | 晨报时间 |

| eveningHour | 18 | 晚报时间 |

| thinkingModel | 自动检测 | 策略型角色（chief/product/growth/content）|

| executionModel | 自动检测 | 执行型角色（devops/fullstack/intel/data）|

| ceoTitle | Boss | CEO 称呼 |

可选参数

• roles：自定义角色列表（默认全郥 8 个）
• roleNames：自定义角色名称（如中文起名）
• --team ：多团队并存时用于隔离角色 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

| Offset | Agent | Task | Frequency |

|--------|-------|------|-----------|

| H-1 | Data Analyst | Data + user feedback | Daily |

| H-1 | Intel Analyst | Competitor scan | Mon/Wed/Fri |

| H | Chief of Staff | Morning brief (announced) | Daily |

| H+1 | Growth Lead | GEO + SEO + community | Daily |

| H+1 | Content Chief | Weekly content plan | Monday |

| H+2 | DevOps | Delivery / environment / Deep Dive / acceptance | Daily |

| H+10 | Chief of Staff | Evening brief (announced) | Daily |

(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.

| File | Owner | Update Trigger |

|------|-------|---------------|

| geo-playbook.md | growth-lead | After GEO experiments/discoveries |

| seo-playbook.md | growth-lead | After SEO experiments |

| competitor-map.md | intel-analyst | After each competitor scan |

| content-guidelines.md | content-chief | After proven writing patterns |

| user-personas.md | data-analyst | After new user insights |

| tech-standards.md | product-lead | After architecture decisions |

Update Protocol

When updating a knowledge file, the owner must:

1. Add a dated entry at the top: ## [YYYY-MM-DD]
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

| Level | Scope | When | Output |

|-------|-------|------|--------|

| L0 Snapshot | Surface: directory tree, packages, env | First onboard | architecture, dependencies, config-env |

| L1 Skeleton | Structure: DB, routes, models, components | First onboard | database, routes, api, models, frontend |

| L2 Deep Dive | Logic: services, auth, jobs, integrations | On-demand per module | services, auth, jobs-events, integrations, domain-flows, data-flow |

| L3 Health Check | Quality: tech debt, tests, security | Periodic / pre-release | tech-debt, test-coverage, devops |

| L4 Incremental | Delta: git diff → update affected files | After code changes | changelog + targeted updates |

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

| Role | Responsibility |

|------|---------------|

| Product Lead | Clarification / PRD / acceptance: complete clarification, PRD, user stories, acceptance criteria, and review knowledge freshness before delegating |

| DevOps | Delivery / QA gate / Deep Dive: enter code directory for deployment-oriented scans, maintain release checklist, smoke/regression testing, auto-QA access, and generate/update shared product knowledge files |

| Fullstack Dev | Implementation / docs / Deep Dive follow-up: continue module-level deep dive, code analysis, implementation, dev docs, interface docs, and ACP session work |

| Chief of Staff | Routing / escalation: split implementation vs delivery tasks, prevent duplicate labor, escalate blockers |

| All Agents | Consumption: read product knowledge before any product-related decision |

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)

| Time | Agent | Type | Purpose |

|------|-------|------|---------|

| 07:00 | data-analyst | daily | Data pull + feedback scan |

| 08:00 | chief-of-staff | announce | Morning: router scan + brief + quality |

| 09:00 | growth-lead | daily | GEO/SEO/community |

| 09:00 | product-lead | daily (NEW) | Inbox + clarification/PRD + task delegation |

| 10:00 | content-chief | daily M-F (was weekly) | Content creation + collaboration |

| 10:00 | devops | daily (delivery track) | Inbox + Deep Dive + delivery + QA gate |

| 12:00 | chief-of-staff | patrol (NEW) | Router scan only, no brief |

| 15:00 | chief-of-staff | patrol (NEW) | Router scan only, no brief |

| 18:00 | chief-of-staff | announce | Evening: router scan + summary + next day plan |

| 07:00 M/W/F | intel-analyst | 3x/week | Competitor scan |

Why These Changes Matter

| Before | After | Impact |

|--------|-------|--------|

| Inbox = primary dispatch | Inbox = backup + spawn = primary | Real-time dispatch via spawn; inbox for archival only |

| Chief 2x/day | Chief 4x/day with router role | Blockers caught within hours, not days |

| Content-chief 1x/week | Daily M-F | Actually produces content |

| Product-lead no cron | Daily | Knowledge governance happens |

| No team dashboard | Dashboard every session | All agents know the full picture |

| No timeout detection | Automatic timeout rules | Nothing falls through cracks |

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.