SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场release

release

部署与运维

查看项目

更新于 10-15 15:23

技能介绍

用途

Release 是一个轻量、感知仓库的发布助手技能，属于 oh-my-claudecode 技能集。它的目标是在不硬编码任何项目特定配置的前提下，通过分析仓库本身来推导发布规则，并据此引导用户完成一次完整的软件发布。

主要能力

  • 仓库分析：首次运行或使用 --refresh 时，检查项目与 CI 配置，推导发布规则。
  • 规则缓存：将分析结果写入 .omc/RELEASE_RULE.md，供后续发布复用。
  • 增量检查：若规则文件已存在，会扫描 CI 目录（如 .github/workflows/、.circleci/、.travis.yml、Jenkinsfile、bitbucket-pipelines.yml、gitlab-ci.yml）中是否有比上次分析时间更新的修改，若有则重新分析相关部分并更新文件。
  • 版本确定：支持 patch、minor、major 或显式语义化版本号（如 2.4.0），并校验版本号有效性。
  • 发布前检查清单：基于推导出的规则生成检查项，包括变更提交与推送、CI 状态、本地测试、版本号更新、发布说明准备等。
  • 发布说明指导：根据仓库使用的约定（Keep a Changelog、Conventional Commits、GitHub 自动生成或无约定）提供撰写建议，并可基于 git log 生成草稿。
  • 执行发布：按规则逐步完成版本号更新、运行测试、提交、打标签、推送，并提示 CI 接管或列出手动发布命令。
  • 首次设置建议：若发现缺少发布工作流、缺少 git 标签或构建产物未被 gitignore 等问题，提供具体帮助建议。
  • 发布后验证：检查 CI 状态、注册表新版本以及 GitHub Release 是否创建成功。

使用方式

命令格式：

/oh-my-claudecode:release [version]
  • version 为可选参数。若省略，技能会询问用户。
  • 接受 patch、minor、major 或显式语义化版本号（如 2.4.0）。
  • 添加 --refresh 可强制重新分析仓库，即使已存在缓存的规则文件。

执行流程

Step 0 — 加载或构建发布规则 检查 .omc/RELEASE_RULE.md 是否存在。若不存在（或传入了 --refresh），执行完整的仓库分析并写入文件。若已存在，读取文件并进行快速增量检查，扫描 CI 目录中是否有比规则文件最后分析时间更新的修改；若相关文件有变更，重新分析对应部分并更新文件，同时报告变更内容。

Step 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、PyPI、Cargo、Docker、GitHub Packages 或其他分发方式；是否存在标签推送时自动发布的 CI 步骤，以及对应的 workflow 文件和 job。
  • 1c. 发布触发条件：识别发布由什么触发，如标签推送（v*）、手动触发（workflow_dispatch）、合并到 main/master、发布分支合并或提交信息模式。
  • 1d. 测试门禁：识别测试命令及其在 CI 中的运行位置；测试是否必须在发布前通过；记录任何绕过标志。
  • 1e. 发布说明/变更日志：是否存在 CHANGELOG.md 或 CHANGELOG.rst；使用何种约定（Keep a Changelog、Conventional Commits、GitHub 自动生成或无）；是否存在预提交的发布正文文件（如 .github/release-body.md）。
  • 1f. 首次使用检查：是否存在发布工作流；是否有 .gitignore 条目防止构建产物被提交；是否使用了 git 标签（运行 git tag --list 检查）。若缺失则标记并提供建议。

Step 2 — 写入 .omc/RELEASE_RULE.md 按指定结构创建或覆盖文件，包含：版本来源、发布触发条件、测试门禁、注册表/分发、发布说明策略、CI 工作流文件、首次设置缺口等章节，并带有最后分析时间戳。

Step 3 — 确定版本 若用户提供了版本参数则直接使用；否则显示当前版本以及 patch、minor、major 分别对应的版本号，询问用户选择，并校验所选版本为有效的语义化版本字符串。

Step 4 — 发布前检查清单 基于发布规则生成检查清单，至少包括：所有预期变更已提交并推送、目标分支 CI 通过、本地测试通过（运行测试门禁命令）、版本号已应用到所有版本来源文件、发布说明/变更日志已准备。请用户确认后再继续，或按用户指示逐步执行。

Step 5 — 发布说明指导 帮助用户撰写良好的发布说明，应用仓库使用的约定。若无检测到约定，默认指导包括：以用户可见的变更开头而非内部实现细节；按类型分组（新功能、缺陷修复、破坏性变更、弃用、内部/杂项）；每项一句话并链接 PR 或 issue，外部贡献者需署名；破坏性变更放在最前并包含迁移路径；省略用户不可见的变更（重构、CI 调整、仅测试变更），除非影响构建可复现性。示例条目格式：

### Bug Fixes
- Fix session drop on token expiry (#123) — @contributor

若仓库使用 Conventional Commits，则基于 git log <prev-tag>..HEAD --no-merges --format="%s" 按提交类型分组生成草稿变更日志，展示给用户编辑。

Step 6 — 执行发布 按发现的规则逐步执行：更新版本号（应用到每个版本来源文件）、运行测试（执行测试门禁命令）、提交（git add <version files> CHANGELOG.md 并使用 chore(release): bump version to vX.Y.Z 提交）、打标签（git tag -a vX.Y.Z -m "vX.Y.Z"，推荐附注标签）、推送（git push origin <branch> && git push origin vX.Y.Z）。若发布触发条件为标签推送，提醒用户 CI 将处理后续（发布、创建 GitHub Release），并展示预期的 CI 工作流文件。若无 CI 自动化，列出手动发布命令（如 npm publish --access public、twine upload dist/*）。

Step 7 — 首次设置建议 若在 Step 1f 中发现缺口，提供具体帮助：无发布工作流时，建议创建基于 v* 标签推送触发的 GitHub Actions 工作流，可运行测试、发布到 npm/PyPI 等、创建带发布说明的 GitHub Release，并询问是否为其技术栈搭建 .github/workflows/release.yml；无 git 标签时，说明这可能是首次发布，将在 Step 6 创建第一个标签；构建产物未被 gitignore 时，说明会增大仓库体积并造成合并冲突，询问是否添加到 .gitignore。

Step 8 — 验证 推送后：检查 CI 状态（若可用，运行 gh run list --workflow=<release workflow> --limit=3）、几分钟后检查注册表（npm、PyPI）中的新版本、确认 GitHub Release 已创建（gh release view vX.Y.Z），报告成功或标记失败。

适用场景

适用于需要规范化发布流程的各类代码仓库，包括使用 npm、PyPI、Cargo、Docker 等分发方式的项目，以及 monorepo 和多包工作区（技能会检测 npm workspaces、pnpm workspaces、Cargo workspace 等模式并相应适配）。

限制

  • 该技能不硬编码任何项目特定的版本文件或命令，所有内容均从仓库检查中推导。
  • .omc/RELEASE_RULE.md 是本地缓存，可选择提交到仓库与团队共享，或加入 .gitignore 保持本地。
  • 具体支持的注册表、CI 平台和发布自动化工具取决于仓库实际配置，技能本身不预设。
  • 关于收费、价格、平台支持范围等具体信息，资料中暂未提供。