openclaw-migration

核心用法

OpenClaw Migration Skill 是一个项目重命名迁移的规范化指南，适用于开发团队将原有 Clawd 项目全面迁移至 OpenClaw 品牌。该 skill 提供从目录结构重组、代码引用更新到 CI/CD 配置调整的完整迁移路径，确保人人和 AI 助手都能遵循统一标准执行操作。

显著优点

1. 标准化流程：将复杂的重命名操作拆解为 7 个明确的可执行步骤，降低迁移混乱风险
2. 全覆盖检查清单：涵盖源码目录、文档、配置文件、CLI 脚本、CI 工作流等关键触点
3. 保留关键元数据：明确指导 AGENTS.md、SOUL.md 等人格化文件的处理方式，维护项目身份连续性
4. 验证机制完善：提供从 package.json 脚本到 pnpm 工作区、skills.json 的多层校验点

潜在缺点与局限性

• 无自动化脚本：目前仅为文档级指导，未提供自动化重命名工具，人工执行仍存在遗漏风险
• 平台假设较强：基于 pnpm 工作区和特定目录结构（clawdbot/ → openclaw/），对其他包管理器或目录风格需手动适配
• CI 配置依赖外部知识：仅提及更新名称，未详述各平台（Fly、Render、GitHub Actions）的具体修改方式
• 回滚策略缺失：未提供迁移失败时的回退方案，一旦清理旧目录出现问题恢复成本较高

适合人群

• 项目负责人/维护者：需要统筹大规模重命名迁移的技术决策者
• DevOps/自动化工程师：负责更新 CI/CD 配置和部署脚本的实施者
• 新贡献者：需要理解项目历史结构和命名变更背景的团队成员

常规风险

• 路径硬编码遗漏：深层嵌套的 import 语句、环境变量、Dockerfile 中的路径可能未被检索覆盖
• 技能注册失效：skills.json 目录指向错误可能导致 AI 助手功能异常
• 品牌人格断裂：SOUL.md 等身份文件中名称替换不当可能影响产品人格一致性
• 并行开发冲突：迁移期间若主干持续更新，分支合并可能产生大量冲突

核心用法

OpenClaw Migration 是一款纯文档型 Skill，专为项目从 "Clawd" 重命名为 "OpenClaw" 的迁移场景设计。其核心功能是为开发者、贡献者和自动化助手提供统一的操作 playbook，涵盖目录重命名、配置文件更新、文档同步、CI 验证等全流程步骤。使用时直接查阅 SKILL.md 即可获取详细迁移清单，包括：盘点现有 clawdbot/ 目录结构、创建新的 openclaw/ 根目录、全局替换 "Clawd" 文本引用、更新 package.json 与 pnpm-workspace 配置、验证测试脚本可用性、清理旧目录等 7 大步骤。

显著优点

零执行风险：纯 Markdown 文档，无可执行代码、无外部依赖、无网络请求，从根本上消除恶意代码注入或运行时攻击可能。流程标准化：将易出错的口头沟通转化为可复现的 check-list，特别适合多人协作场景，避免因个人疏忽导致构建中断。覆盖全面：不仅包含文件系统操作，还细化了隐藏配置文件（.github, .agent, .ox）、品牌资产（README-header.png）、人格文档（SOUL.md, MEMORY.md）及 CI/CD 工作流的同步更新策略。验证机制完善：提供 4 项明确的迁移后验证点，包括脚本路径、workspace 引用、skill 清单及部署配置的正确性检查。

潜在缺点与局限性

无自动化能力：需人工逐条执行，无法一键完成迁移，在大型 monorepo 场景下效率受限。版本敏感：若项目结构后续演进（如改用 npm workspace 替代 pnpm），文档内容可能滞后。品牌特定：硬编码 "Clawd → OpenClaw" 场景，复用至其他重命名需求时需手动改写。无回滚指南：仅提供正向迁移步骤，未详述出现严重问题时的恢复策略。

适合人群

• 正在执行品牌重塑的技术负责人与核心开发者
• 需要理解迁移背景的新进贡献者
• 负责代码审查的 reviewer（验证迁移完整性）
• 使用 AI 助手辅助项目管理的场景（如向 "Ivan" 汇报进度）

常规风险

该 Skill 本身无任何技术风险。使用时的主要风险在于人为执行疏漏，例如遗漏隐藏文件迁移、未更新 SOUL.md 中的角色名称导致 AI 助手人格不一致、或 CI 配置中的旧路径未同步修改引发部署失败。建议执行前对关键配置进行版本控制备份，并在 staging 环境完成全流程验证后再合并至主分支。