Project Provisioning

这个 skill 用来把“新软件项目接入 OpenClaw”这件事标准化。

如果目标环境还没完成前置检查、dispatch 初始化确认或本地配置生成，先使用 project-provisioning-setup。

它的目标不是做业务开发，而是完成项目开通闭环：

• 创建项目级 dev agent
• 创建对应 workspace
• 创建或克隆 repo 目录
• 写入项目 registry
• 自动把新 agent 加入 dispatch agent 的 allowAgents
• 执行验证
• 失败时回滚

适用场景

在以下情况下使用：

• 当前请求是“新增项目接入”
• dispatch agent 检查 registry 后确认项目还不存在
• 需要为该项目创建独立上下文，而不是复用已有 dev agent

不要在以下场景使用：

• 已有项目的正常功能开发
• 已有项目的 bug 修复
• 测试、部署、分析类任务
• 仅仅想查询项目是否存在

输入项

开通前应收集或确认这些信息：

• project_name
• customer_name
• repo_git_url（如果要直接克隆仓库）
• tech_stack（可选，用于后续项目说明）
• environment_mode（可选，用于后续环境规划）

使用前提

默认前置依赖：project-provisioning-setup 已经跑过，并且返回 ready_for_project_provisioning=yes。

要让别人可用，这个 skill 依赖的前提必须先满足：

• 目标环境已经安装 OpenClaw，且 openclaw CLI 可执行
• 当前用户对 ${HOME}/.openclaw 和项目仓库根目录有写权限
• 目标环境已经存在一个 dispatch / orchestration agent
• 该 dispatch agent 已存在于 ~/.openclaw/openclaw.json
• 允许脚本自动更新该 dispatch agent 的 subagents.allowAgents
• 目标环境至少具备 bash、python3、jq，若要克隆仓库还需要 git

重要边界：

• 这个 skill 只负责“项目开通”
• 不负责创建 dispatch agent 本身
• 不适合在没有宿主机写权限的受限环境直接运行

安装与初始化

给别人复用时，至少完成这些步骤：

1. 把整个 project-provisioning 目录放到目标 dispatch workspace 的 skills/ 下
2. 复制 config.env.example 为 config.env
3. 至少确认这 3 个变量：
   • DISPATCH_AGENT_ID
   • PROJECTS_ROOT
   • PROJECT_ID_PREFIX
4. 如需在本机保留私有运行配置，可写入 state/config.local.env
5. 执行：

chmod +x scripts/*.sh
./scripts/init.sh

6. 用一个测试项目跑通：开通 -> 验证 -> 回滚

详细安装步骤和复用说明见 references/reuse-install.md。

可移植配置

这个 skill 现在是可移植版，不再写死 pm-dispatch。

复用到别人的 OpenClaw 时：

1. 复制 config.env.example 为 config.env
2. 只修改需要的变量

通常只改这 3 项就够了：

• DISPATCH_AGENT_ID
• PROJECTS_ROOT
• PROJECT_ID_PREFIX

可选变量：

• ESCALATION_AGENT_ID
• PROJECT_AGENT_SUFFIX

如果没有 config.env，脚本会使用默认值。

标准路径

• Skill 根目录：<dispatch workspace>/skills/project-provisioning
• 发布默认 Registry：<skill-root>/state/projects.json
• 本机运行态 Registry：建议通过 config.env 的 REGISTRY 覆盖到本地文件，例如 state/projects.local.json
• 模板目录：<skill-root>/assets/project-dev-template/
• 脚本目录：<skill-root>/scripts/
• OpenClaw 主目录：${HOME}/.openclaw
• 项目仓库根目录：由 PROJECTS_ROOT 控制
• 调度 agent：由 DISPATCH_AGENT_ID 控制

工作流

1. 读取 registry，确认项目尚未存在
2. 生成：
   • 先把 customer_name 和 project_name 规范化为稳定 ASCII slug
   • 英文名直接 slugify
   • 中文名优先按英文映射文件翻译；未命中时再走内置常用词翻译和稳定 ASCII 回退
   • project_id = <PROJECT_ID_PREFIX>-<customer-slug>-<project-slug>
   • agent_id = <project_id>-<PROJECT_AGENT_SUFFIX>
   • workspace_path = ${HOME}/.openclaw/workspace-<agent_id>
   • repo_path = <PROJECTS_ROOT>/<project_id>
3. 执行 scripts/provision_project.sh
4. 执行 scripts/verify_project.sh
5. 确认新的 agent_id 已加入 dispatch agent 的 allowAgents
6. 如果中途失败或验证失败，执行 scripts/rollback_project.sh

补充约束：

• scripts/provision_project.sh 必须以事务方式执行
• 只要在写 registry 前失败，也必须清理已创建的 agent / workspace / repo
• scripts/rollback_project.sh 除了支持基于 registry 回滚，也应支持对“尚未写入 registry 的半开通项目”按显式路径回滚

安全规则

• 不覆盖已有 repo 目录
• 不覆盖已有 workspace 目录
• 不允许重复的 project_id
• 不允许重复的 agent_id
• 不把一个新项目指向另一个项目的 repo
• 没有验证通过前，不报告“开通成功”
• 只要出现半开通状态，就优先回滚
• 自动回滚必须覆盖“registry 尚未写入”的失败阶段

风险与副作用

这是一个高副作用 skill。执行时可能直接修改：

• ~/.openclaw/openclaw.json
• dispatch agent 的 subagents.allowAgents
• ${HOME}/.openclaw/workspace-*
• PROJECTS_ROOT 下的项目目录
• skill 自己的 registry 文件

因此：

• 必须先确认目标环境允许做宿主机写入
• 首次复用时应先用测试项目验证，不要直接对生产项目下手
• 发布到 ClawHub 时，应明确标注它是“host-mutating / provisioning”类 skill，而不是普通只读辅助 skill

最小验证步骤

别人第一次安装后，至少应完成一次最小闭环验证：

1. 执行 ./scripts/init.sh
2. 开通一个临时测试项目
3. 验证 registry、agent、workspace、allowAgents 是否都正确写入
4. 执行回滚，确认失败清理或测试清理是可用的

如果这一步没跑通，不应宣称该 skill 已在目标环境可用。

依赖资源

• 使用 assets/project-dev-template/ 中的模板
• 使用 scripts/ 中的脚本
• 部署与复用说明参考：
  • references/server-deploy.md
  • references/reuse-install.md

返回结果

执行完成后，应该明确返回：

• project_id
• agent_id
• workspace_path
• repo_path
• 是“创建空 repo 目录”还是“克隆远程仓库”
• 验证结果
• dispatch agent 的 allowAgents 是否更新成功 spatch agent 的 allowAgents 是否更新成功