mcpField
B
bump-release

bump-release

github.com/paulrberg开发1022.4k 次安装今天更新
代码仓库

关于 bump-release

Bump Release 是用于单包仓库和 workspace monorepo 的版本发布技能，支持稳定版与 beta 版规划，并处理变更日志、依赖顺序、提交和标签。

主要功能

  1. 01单包与 monorepo 发布
  2. 02稳定版和 beta 版规划
  3. 03变更日志生成与校验
  4. 04依赖范围和顺序检查
  5. 05只读发布预览
  6. 06逐包提交和注释标签

适用场景

  1. 01在不改文件的情况下预览发布计划
  2. 02发布 workspace 中选定的包
  3. 03将预发布版本提升为稳定版

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/paulrberg/agent-skills --skill bump-release

安装后在 Claude Code 中输入/bump-release确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

agents/
openai.yaml
references/
common-changelog.md
scripts/
finalize-release-plan.py
plan-release.mjs
test_release_helpers.py
validate-changelog.py

详细介绍

提升版本

如果这些说明已通过斜杠或美元符号调用出现在对话中，请直接遵循； 不要再次通过技能工具调用此技能。

为一个或多个软件包发布新版本，包括版本升级、变更日志条目、提交和标签。支持 单软件包仓库、工作区多包仓库、稳定版、Beta 版和试运行。

参数

  • packages：可选的软件包名称或目录。在单软件包仓库中可省略。
  • version：可选的显式 semver。仅对用户选择的一个软件包有效。
  • --beta：创建或推进 -beta.X 预发布版本。
  • --dry-run：预览，不修改文件、不提交、不打标签。

辅助工具接口

从此 SKILL.md 解析 <skill-dir>。辅助工具的标准输出保持为 JSON，诊断信息输出到标准错误。

node "<skill-dir>/scripts/plan-release.mjs" \
  [--cwd <repo>] [--beta] [--dry-run] [--version <semver>] \
  [--package <name-or-dir>]...

只读发现输出的 schemaVersion: 2。它会报告软件包标识、每个软件包的完整 changedFiles、工作区边、声明的范围、先前标签的事实、选定目标以及工作区状态。changeHints 是基于文件名的导航提示，不具有权威性。切勿用它们判断发布相关性或决定是否纳入变更日志。

Agent 决定每个稳定版的补丁／次要／主要版本后，将发现 JSON 写入临时文件并运行：

uv run "<skill-dir>/scripts/finalize-release-plan.py" \
  --discovery <discovery.json> \
  [--version <package>=<semver>]...

最终处理器会执行 Beta 版和显式版本转换、稳定版预发布版本升级、npm 范围满足性检查、简单依赖范围建议以及依赖排序。它会将复杂范围、对等依赖范围、依赖循环，以及未由 Agent 提供稳定版本的软件包报告为未解决的决策。如果未满足的依赖边新增了依赖方，请选择该软件包的发布版本，并使用另一个 --version 赋值重新运行。最终处理器不会决定常规发布的版本幅度或依赖策略。

对于每个写入的稳定版变更日志，请验证其确定性结构：

uv run "<skill-dir>/scripts/validate-changelog.py" \
  --file <CHANGELOG.md> --version <semver> --date <YYYY-MM-DD> [--tag <tag>]

此检查会验证预期版本和日期、标题／类别顺序、允许的类别、列表结构以及发布链接标签。它不会评判重要性、措辞或语义类别。

工作流

  1. 直接将用户参数映射到发现操作并运行。退出码 2 表示目标不是可发布的 Git/软件包仓库；退出码 64 表示输入无效。出现任一情况时停止。

  2. 要求 workingTree.clean。不要纳入无关工作。

  3. 解决未知或有歧义的软件包选择。用户明确指定版本时，仍只处理单个软件包。

  4. 检查每个目标的完整 changedFiles，以及与上一个标签之间的净差异。判断保留下来的更改是否值得发布。根据具体情况，运行环境、重构、文档、测试和工具都可能相关；不能仅凭文件名作出判断。

  5. 对于每个未明确指定版本的相关稳定版目标，根据面向使用者的更改选择补丁、次要或主要版本。对于 beta 版，让最终处理程序计算机械式版本转换。

  6. 运行最终处理程序。检查尚未满足的工作区依赖边。只有在策略适用时，才接受它对简单依赖范围的建议；对 peer 和复杂范围策略要明确选择。添加依赖方及其 Agent 选择的发布版本，然后重新运行，直到软件包集合和依赖顺序都已确定。

  7. 对于试运行，报告有序的软件包/版本计划、范围修改、变更日志/标签/提交操作，以及由 Agent 决定的跳过项。停止，不写入任何更改。

  8. 对于稳定版发布，阅读 references/common-changelog.md，并根据限定范围内的净差异撰写面向使用者的条目。条目的选择、措辞、重要性和类别由 Agent 决定。Beta 版发布不更新变更日志。

  9. 更新清单和已接受的依赖范围。使用辅助程序验证每个稳定版变更日志。

  10. 使用仓库中最窄范围的既定命令格式化一次。

  11. 按依赖方先于被依赖方的顺序提交并打标签。每个软件包使用一个提交和一个附注标签：

    • 单软件包提交：docs: release <version>；
    • 单体仓库提交：docs: release <package> <version>；
    • 单软件包标签：遵循已观察到的 v<version> 或纯语义版本事实；
    • 单体仓库标签：遵循已观察到的软件包标签事实，默认使用 <package-dir>@<version>。

  12. 不要推送。成功后，建议使用准确的 git push origin <tag>... 命令，其中仅包含本次执行创建的标签；不要使用 --tags。

  13. 在最终报告前，检查 .github/workflows/，确认是否有会从已推送标签创建或发布 GitHub 版本的活动工作流。像 release.yml 这样的文件名只是线索，并非证据。使用 $cli-gh 只读检查仓库是否有持续维护 GitHub 版本的既有记录。如果有，则根据以下规则，提出为每个新标签创建 GitHub 版本，并等待用户批准：

    • 一个标签且存在发布 CI：不要提出手动创建版本；推送标签应触发 CI。
    • 一个标签且不存在发布 CI：提出使用 $cli-gh 创建版本。
    • 将同时推送多个标签：即使存在发布 CI，也提出使用 $cli-gh 为每个标签创建一个版本，因为预计多标签推送无法可靠地触发该自动化。

    未经用户批准，绝不要创建 GitHub 版本。如果无法核实版本发布记录，请说明情况未知，并且不要提出写入操作。

安全与完成条件

辅助函数失败表示输入格式错误、违反不变量或验证失败；Agent 决策仍未解决是 JSON 中的数据，不属于辅助函数失败。发现和试运行均为只读。在最终稳定的软件包集合确定之前，不要编写变更日志；如果发现阶段报告的是已观察到的事实，也不要据此推断标签约定。

试运行完成需要有基于发现结果、经 Agent 审核的操作预览，且写入次数为零。发布完成需要验证清单和稳定的变更日志、完成格式整理、按依赖顺序为每个软件包各创建一个提交和附注标签，并报告已创建的提交和标签、由 Agent 决定跳过的项目、准确的标签推送命令，以及任何适用的 GitHub 发布提案。

根据情况使用 ### ⛔ Release stopped — working tree is not clean、### ⚠️ Confirm release plan、### 🔎 Release preview — no files, commits, or tags written 或 ### 🏁 Release complete。保持辅助函数 JSON、版本、哈希、标签、命令和变更日志文本原样不变，不添加装饰。

评论

支持 Markdown