Team Builder

Deploy a multi-agent SaaS growth team on OpenClaw with shared workspace, async inbox communication, cron-scheduled tasks, deep project code scanning (Deep Di...

Security Scan

The skill's files and instructions match a multi-agent deployment purpose, but its Deep Dive scanning and config-modifying scripts aggregate potentially sensitive configuration and env data and can write those findings into shared workspace files and agent configs — review carefully before running.

Purpose & Capability

Name/description (deploy a multi-agent team + project deep scans) align with the included artifacts: SKILL.md, agent templates, and a deploy.js that generates a workspace and agent SOULs. The scripts and templates are consistent with creating agent configs, cron scripts, a workspace and wiring agents into openclaw.json.

Instruction Scope

The Deep Dive protocol and fullstack-dev agent instructions explicitly tell agents to enter project directories, run stack-specific commands (git, tree, artisan, grep, etc.), and generate knowledge files including config-env.md and dependencies.md. Those scans can collect environment variable inventories and config details (and may surface secrets in shared/products/*). The skill also produces an apply-config.js that will modify ~/.openclaw/openclaw.json (even if the user is asked to run it manually). Optional Telegram integration means the system may be configured to send messages to external endpoints. All of these behaviors are coherent with the stated purpose but materially expand the agent's read/write footprint and create plausible exfiltration/exposure paths for sensitive data.

Install Mechanism

No install spec or remote downloads; this is instruction-plus-local-script (deploy.js). There are no external URLs or archive extracts. Risk from install mechanism is low because nothing is fetched or executed from external hosts by default.

Credentials

The skill declares no required environment variables; optional Telegram bot tokens may be provided and, if supplied, are stored in openclaw.json. It relies on existing model API keys already configured in OpenClaw. Asking to store Telegram tokens in openclaw.json is plausible for Telegram integration but deserves scrutiny because those tokens grant outbound messaging. The Deep Dive process also inventories env/config files (config-env.md), which can surface secrets if code paths containing them are scanned.

Persistence & Privilege

always:false and agent-autonomy are defaults. The workspace and scripts the skill writes are persistent on disk; apply-config.js, when run by the user, will modify the user's ~/.openclaw/openclaw.json (the SKILL.md says it will back up first). That level of privilege is reasonable for a team-deployer but is sensitive: it changes agent registration and can add bindings (including Telegram) to the global agent config. Because the skill does not force automatic changes but provides tooling to do so, user review is possible — nevertheless, modifying a global config is a nontrivial privilege.

What to consider before installing

This skill is coherent with its stated purpose but exercises broad read/write capabilities — caution is warranted. Before installing or running anything: - Inspect the generated files: open the generated workspace and read apply-config.js before executing it. Confirm the backup behavior and exactly what it will write to ~/.openclaw/openclaw.json. - Test in a safe environment: run the deploy script and apply-config.js inside a throwaway OpenClaw config or VM, not your production environment. Try with 2-3 agents first as the documentation recommends. - Limit scan targets: when triggering Deep Dive scans, point agents only at non-production, scrubbed, or dedicated code copies. Avoid scanning directories that contain .env, secrets, private keys, or credentials. The scan will produce config-env.md and other files that may capture sensitive values. - Review knowledge outputs: knowledge files (shared/products/{product}/...) are readable by all agents. Inspect these outputs for leaked credentials or secrets before allowing agents with external-network privileges to run or before storing them in long-term shared locations. - Telegram tokens and external bindings: if you provide Telegram bot tokens, be aware they will be stored in openclaw.json and enable outbound communication. Only supply tokens you trust and consider rotating them after testing. - Audit openclaw.json backups: the apply-config.js auto-backups are helpful — verify the backup location and contents before and after applying changes. - Consider access controls: if your OpenClaw instance can restrict which agents can send messages externally or access particular files, apply those restrictions prior to enabling the full team. Why suspicious (not outright malicious): the skill's behaviors are consistent with its purpose, but the Deep Dive scanning and config-write steps increase the chance of accidental secret exposure or undesired external communication. If you want to proceed, validate scripts in isolation and limit scan scope and external tokens.

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:

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.

Deployment Flow

Step 1: Collect Configuration

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

Parameter	Default	Description
Team name	Alpha Team	Used in all docs and configs
Workspace dir	~/.openclaw/workspace-team	Shared workspace root
Timezone	Asia/Shanghai	For cron schedules
Morning brief hour	8	Chief's morning report
Evening brief hour	18	Chief's evening report
Thinking model	zai/glm-5	For strategic roles
Execution model	zai/glm-4.7	For execution roles
CEO title	Boss	How agents address the CEO

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

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+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/<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.

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] <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

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	Governance: trigger scans, review quality, track freshness, ensure completeness
Fullstack Dev	Execution: enter code directory, scan, generate/update knowledge files
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 (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)

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 + knowledge governance + task delegation
10:00	content-chief	daily M-F (was weekly)	Content creation + collaboration
10:00	fullstack-dev	daily (enhanced)	Inbox + Deep Dive + dev tasks + patrol
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 = blind drop	Inbox with status tracking	Messages are acknowledged and trackable
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
• 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.