发布技能
一个轻量、感知仓库的发布助手。首次运行时，它检查项目与 CI 来推导发布规则，将规则存储于 .omc/RELEASE_RULE.md 供后续使用，然后根据这些规则引导你完成发布。
用法
/oh-my-claudecode:release [version]
version可选。省略时技能会询问。接受patch、minor、major或显式 semver，如2.4.0。- 添加
--refresh可以强制重新分析仓库，即使缓存规则文件已存在。
执行流程
步骤 0 — 加载或构建发布规则
检查 .omc/RELEASE_RULE.md 是否存在。
如果不存在（或传入了 --refresh）： 执行下面的完整仓库分析并写入文件。
如果存在： 读取文件。然后执行快速增量检查——扫描 .github/workflows/（或等效的 CI 目录：.circleci/、.travis.yml、Jenkinsfile、bitbucket-pipelines.yml、gitlab-ci.yml），查找是否有任何修改晚于规则文件中的 last-analyzed 时间戳。如果相关的工作流文件发生了变化，则重新分析这些部分并更新文件。报告哪些内容发生了变化。
步骤 1 — 仓库分析（首次运行或 --refresh）
检查仓库并回答以下问题。将答案写入 .omc/RELEASE_RULE.md。
1a. 版本来源
- 定位所有包含与
package.json/pyproject.toml/Cargo.toml/build.gradle/VERSION文件等中当前版本匹配的版本字符串的文件。 - 列出每个文件及其用于查找版本的字段或正则表达式模式。
- 检测是否存在发布自动化脚本（例如
scripts/release.*、Makefile release目标、bump2version、release-it、semantic-release、changesets、goreleaser）。
1b. 注册表 / 分发
- npm（带有
publishConfig或在 CI 中使用npm publish的package.json）、PyPI（pyproject.toml+twine/flit）、Cargo（Cargo.toml）、Docker（Dockerfile+ 推送步骤）、GitHub Packages、其他。 - CI 中是否有在标签推送时自动发布的步骤？是哪个工作流文件和哪个 job？
1c. 发布触发器
- 确定启动发布的原因：标签推送（
v*）、手动调度（workflow_dispatch）、合并到主分支/main、发布分支合并、提交消息模式。
1d. 测试关卡
- 确定测试命令及其在 CI 中的运行位置。
- 发布前是否要求测试通过？记录任何绕过标志。
1e. 发布说明 / 变更日志
- 是否存在
CHANGELOG.md或CHANGELOG.rst？ - 使用什么约定：Keep a Changelog、Conventional Commits、GitHub 自动生成、无？
- 是否在打标签前提交了发布体文件（例如
.github/release-body.md）？
1f. 首次用户检查
- 在
.github/workflows/（或等效目录）中是否存在发布工作流？如果不存在，则标记并提供搭建一个的建议。 - 是否有
.gitignore条目阻止构建工件被提交？如果没有，则标记。 - 是否使用了 Git 标签？运行
git tag --list检查。如果没有标签，则标记并解释最佳实践。
步骤 2 — 写入 .omc/RELEASE_RULE.md
创建或覆盖文件，使用以下结构：
# 发布规则
<!-- last-analyzed: YYYY-MM-DDTHH:MM:SSZ -->
## 版本来源
<!-- 文件列表 + 模式 -->
## 发布触发器
<!-- 什么触发发布 -->
## 测试关卡
<!-- 命令 + CI job 名称 -->
## 注册表 / 分发
<!-- npm, PyPI, Docker 等 + 负责发布的 CI job -->
## 发布说明策略
<!-- 约定 + 文件 -->
## CI 工作流文件
<!-- 相关工作流文件的路径 -->
## 首次设置差距
<!-- 分析过程中发现的任何缺失部分，或“无” -->
步骤 3 — 确定版本
如果用户提供了版本参数，则使用它。否则：
- 显示当前版本（来自主版本文件）。
- 显示
patch、minor和major会生成的版本。 - 询问用户使用哪个。
验证所选版本是有效的 semver 字符串。
步骤 4 — 预发布检查清单
呈现一个从发布规则派生的检查清单。至少包含：
- 此版本的所有预期更改已提交并推送
- CI 在目标分支上为绿色
- 测试在本地通过（运行测试关卡命令）
- 版本提升已应用到所有版本源文件
- 发布说明 / 变更日志已准备好（见步骤 5）
在继续之前要求用户确认，或者如果用户说“开始”则运行每个步骤。
步骤 5 — 发布说明指导
帮助用户编写好的发布说明。应用仓库使用的任何约定。当未检测到约定时的默认指导：
好的发布说明应具备：
- 以对用户来说改变了什么开头，而不是内部实现细节。
- 按类型分组：
新功能、Bug 修复、破坏性变更、弃用、内部 / 杂项。 - 每个条目：一句话，链接到 PR 或 issue，如果是外部贡献者则注明作者。
- 破坏性变更放在最前面，且必须包含迁移路径。
- 省略用户看不到的变更（重构、CI 调整、仅测试的变更），除非它们影响构建可重复性。
示例条目格式：
### Bug 修复
- 修复令牌过期时会话丢失的问题 (#123) — @贡献者
如果仓库使用 Conventional Commits，则从 git log <上一个标签>..HEAD --no-merges --format="%s" 按提交类型分组生成草稿变更日志。将其展示给用户，让其编辑。
步骤 6 — 执行发布
使用发现的规则，逐步完成：
- 提升版本 — 应用到每个版本源文件。
- 运行测试 — 执行测试关卡命令。
- 提交 —
git add <版本文件> CHANGELOG.md并提交，消息为chore(release): bump version to vX.Y.Z。 - 打标签 —
git tag -a vX.Y.Z -m "vX.Y.Z"（优先使用注释标签而非轻量标签）。 - 推送 —
git push origin <分支> && git push origin vX.Y.Z。 - CI 接管 — 如果发布触发器是标签推送，提醒用户 CI 将处理剩下的部分（发布、GitHub Release 创建）。显示预期的 CI 工作流文件。
- 手动发布 — 如果没有 CI 自动化，则列出手动发布命令（例如
npm publish --access public、twine upload dist/*）。
步骤 7 — 首次设置建议
如果在步骤 1f 中发现了差距，提供具体帮助：
没有发布工作流：
你的仓库没有 CI 发布工作流。最常用的最佳实践是使用一个由
v*标签推送触发的 GitHub Actions 工作流。它可以：
- 运行测试
- 发布到 npm/PyPI 等
- 使用你的发布说明创建 GitHub Release
要我为你搭建一个
.github/workflows/release.yml吗？
没有 Git 标签：
这似乎是首次发布。Git 标签让 GitHub、npm 和其他工具能够理解你的版本历史。我们将在步骤 6 中创建你的第一个标签。
构建工件未加入 .gitignore：
构建工件存在于 Git 历史中或未被 .gitignore 忽略。这会增加仓库大小并导致合并冲突。要我将它们添加到
.gitignore吗？
步骤 8 — 验证
推送后：
- 检查 CI 状态：
gh run list --workflow=<发布工作流> --limit=3（如果gh可用）。 - 几分钟后在注册表（npm, PyPI）中检查新版本。
- 确认已创建 GitHub Release：
gh release view vX.Y.Z。
报告成功或标记任何失败。
注意
- 此技能不会硬编码任何项目特定的版本文件或命令。所有内容均通过仓库检查推导得出。
.omc/RELEASE_RULE.md是一个本地缓存。如果你想与团队共享推导出的规则，请将其提交到你的仓库；如果希望它保持本地，请将其添加到.gitignore中。- 对于复杂的 monorepo 或多包工作空间，技能将检测工作空间模式（npm workspaces、pnpm workspaces、Cargo workspace）并相应调整。