ClawNetClawNet

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
  1. 用一个测试项目跑通：开通 -> 验证 -> 回滚

详细安装步骤和复用说明见 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 是否更新成功