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") — 可带 INLINECODE7
• 结果通过 auto-announce 推送；不要轮询 sessions_list 或 INLINECODE9
• 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):

CODEBLOCK0

Multi-Team Support

One OpenClaw instance can run multiple teams:

CODEBLOCK1

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

CODEBLOCK2

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 INLINECODE16
• Reuse one context file per active code chain when possible
• Naming pattern: INLINECODE17
• 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 INLINECODE18

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 个）
• INLINECODE25：自定义角色名称（如中文起名）
• INLINECODE26：多团队并存时用于隔离角色 ID
• Telegram bot tokens（可选，配置后自动写入 openclaw.json）

核心命令

CODEBLOCK3

INLINECODE27 检查生成物是否包含双开发模型、角色归属、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

CODEBLOCK4

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. 1. Add a dated entry at the top: INLINECODE29
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:

CODEBLOCK5

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. 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 INLINECODE34
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. 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:

CODEBLOCK6

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. 1. 确认角色
2. 读 INLINECODE50
3. 读 shared/onboarding.md（项目背景，CEO 填写）
4. 读 shared/status/team-dashboard.md（当前状态）
5. 读 shared/decisions/active.md（仅涉及策略时）
6. 读 INLINECODE54
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.