核心用法
wip-release 是一个本地化的全自动化发布流水线工具，专为 @wipcomputer 生态设计。核心工作流围绕 wip-release <level> 单条命令展开，其中 level 支持 patch/minor/major 三种语义化版本级别。执行后自动完成：语义化版本号递增、CHANGELOG.md 更新、SKILL.md 版本同步、git 标签创建与推送、NPM 包发布、GitHub Release 生成六大环节。
CLI 提供丰富的运行模式：--dry-run 用于预演发布流程而不产生实际副作用；--no-publish 仅完成本地版本管理与标签，跳过注册表发布；--skip-product-check 绕过产品文档更新检查。工具内置"产品文档门控"机制——patch 级别仅警告，minor/major 则强制要求 ai/dev-updates/、roadmap.md、readme-first-product.md 等文件在上一版本后有更新记录，确保版本迭代与文档同步。
模块级 API 暴露 release()、detectCurrentVersion()、bumpSemver()、syncSkillVersion() 等函数，支持在自定义脚本中集成。MCP 接口提供 release、release_status 两个工具，可通过 .mcp.json 配置接入 AI 助手工作流。
显著优点
1. 端到端自动化：将分散在多个工具中的发布操作聚合为原子化流程，显著降低人为遗漏风险
2. 语义化版本原生支持：严格遵循 SemVer 规范，自动处理版本号计算与标签命名
3. 产品文档联动：强制或提醒开发者同步更新产品文档，解决"代码发布、文档滞后"的常见问题
4. 网站发布扩展：可选的 .publish-skill.json 配置支持自动将 SKILL.md 部署至网站，形成"发布即文档上线"的闭环
5. 多接口兼容：CLI、模块、MCP 三层接口满足不同场景——人工操作、脚本集成、AI 代理调用
潜在缺点与局限性
1. 生态锁定：名称中的 @wipcomputer 前缀及产品文档门控逻辑表明工具为特定组织 workflow 定制，通用性受限
2. 前置依赖繁重：需要同时配置 git、npm、gh (GitHub CLI)、op (1Password CLI)、clawhub 五个二进制工具，以及 1Password 服务账户令牌、NPM 发布令牌两套密钥，新环境初始化成本较高
3. 功能边界明确：不支持预发布版本 (alpha/beta/rc)，不支持无 package.json 的仓库，非 Node.js 项目无法使用
4. 网络与权限单点：GitHub Release 创建依赖 gh CLI 的认证状态，NPM 发布依赖 1Password 令牌可用性，任一环节故障导致全 pipeline 失败
适合人群
- 维护 @wipcomputer 命名空间下 NPM 包的内部开发者
- 采用"产品文档驱动开发"流程的小型技术团队
- 需要为 AI 助手暴露标准化发布能力的 MCP 用户
- 追求"单命令发布"体验、愿意接受特定工具链约束的 Node.js 项目维护者
常规风险
1. 凭证泄露风险：1Password 服务账户令牌与 NPM 发布令牌以文件路径和环境变量形式配置，需确保 ~/.openclaw/secrets/ 目录权限严格限制 (建议 0700)，避免 CI 日志或终端历史意外捕获
2. 破坏性发布：--skip-product-check 标志允许绕过文档更新检查，在 minor/major 升级时可能导致重大版本与过时文档搭配，损害用户信任
3. 分支保护冲突：工具尝试直接推送标签与 commit，若仓库启用分支保护强制要求 PR 审查，需确保执行者在 main 分支有推送权限或使用 personal access token 绕过
4. 部署副作用：网站发布功能执行 {websiteRepo}/deploy.sh，该脚本权限与内容不受本工具管控，存在执行任意代码风险，建议审查脚本内容或隔离运行环境