Team Builder

Deploy a 7-agent SaaS growth team 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 to spawn Claude Code via ACP for complex coding tasks
• Requires: ACP-compatible coding agent configured in your OpenClaw environment
• No extra setup needed if you don't use this feature

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 7-agent SaaS growth 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)
 |-- Fullstack Dev (full-stack dev + ops, spawns Claude Code with role-based prompts)

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 7-agent default covers most SaaS scenarios, 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.

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 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 scan requests to fullstack-dev via inbox
2. Fullstack-dev enters each project directory and generates knowledge files
3. Product-lead reviews the generated files for completeness
4. 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/<7 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 Deep Dive scan by messaging Fullstack Dev via inbox
3. Fullstack Dev enters the project directory (read-only) and scans the codebase
4. Knowledge files are generated in shared/products/{product}/
5. 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.

Fullstack Dev MUST regenerate manifest.json after every scan (L0-L4). 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 (status tracking)

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

All agents read this file first when waking up. 5-second situational awareness.

Chief-of-Staff as Router

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

• Blocker detection: scans all inboxes for overdue messages
• Active dispatch: writes reminders directly to lagging agents' inboxes
• 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
• Inbox Protocol v2 with status tracking and timeout rules for reliable async communication
• Chief as Router — not just a briefing writer but active coordinator who detects and resolves blockers
• 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 tasks
• 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.