mcpField
V
version-release

version-release

github.com/lobehub开发83.6k2.4k 次安装今天更新
代码仓库

关于 version-release

version-release 是供 Agent 处理此仓库发布分支、CI 发布触发条件和 GitHub Release 说明的 Skill。它将任务引导至详细参考文档，并说明分支检查与自动化规则。

主要功能

  1. 01发布工作流路由
  2. 02次版本与补丁版本发布指引
  3. 03CI 发布触发规则
  4. 04自动版本更新和打标签说明
  5. 05发布说明写作指引

适用场景

  1. 01准备次版本功能发布
  2. 02处理每周发布或热修复
  3. 03检查合并后的 PR 是否触发发布

安装

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

$npx skills add https://github.com/lobehub/lobehub --skill version-release

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

包含的文件

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

agents/
openai.yaml
references/
minor-release.md
patch-release-scenarios.md
release-notes-style.md
references/changelog-example/
db-migration.md
hotfix.md
weekly-release.md

详细介绍

版本发布工作流

此技能是一个路由器。详细步骤位于 references/ 中。

适用范围（重要）

此技能仅适用于：

  1. 发布分支 / PR 工作流
  2. CI 触发条件（auto-tag-release.yml）
  3. 编写 GitHub Release 说明

此技能不适用于编写 docs/changelog/*.mdx。
如果用户要求编写网站更新日志页面，请加载 ../docs-changelog/SKILL.md。

必须配合使用的技能

每次执行 /version-release 时，都必须加载并应用：

  • ../../../DESIGN.md（语气与内容）

概览

主要开发分支是 canary。所有日常开发都在 canary 上进行。发布时，将 canary 合并到 main。常规发布 PR（🚀 release: …、release/*、hotfix/*）在 PR 开启期间，会由 release-pr-version.yml 提交 package.json 版本更新。合并后，auto-tag-release.yml 会为合并提交打标签并创建 GitHub Release。sync-main-to-canary 会在推送到 main 时运行。

实际使用的发布类型只有两种（主要版本发布极为少见，可忽略）：

类型使用场景频率源分支PR 标题格式版本参考
Minor功能迭代发布~每 4 周canary🚀 release: v{x.y.0}手动设置references/minor-release.md
Patch每周发布 / 热修复 / 模型 / DB 迁移~每周或按需canary 或 main自定义（例如 🚀 release: 20260222）自动补丁 +1references/patch-release-scenarios.md

关于编写 Release 说明正文（适用于任何发布类型），请参阅 references/release-notes-style.md。

自动发布触发规则（auto-tag-release.yml）

PR 合并到 main 后，CI 会按以下优先级判断是否发布：

1. Minor 发布（指定版本）

PR 标题匹配 🚀 release: v{x.y.z} -> 使用标题中的版本号。

2. Patch 发布（补丁版本自动 +1）

按以下优先级触发：

  • 分支名称匹配：hotfix/* 或 release/* -> 直接触发（跳过标题检测）
  • 标题前缀匹配：以下标题前缀的 PR 将触发：
    • style / 💄 style
    • feat / ✨ feat
    • fix / 🐛 fix
    • refactor / ♻️ refactor
    • hotfix / 🐛 hotfix / 🩹 hotfix
    • build / 👷 build
3. 不触发

不符合上述任何条件的 PR（例如 docs、chore、ci、test）合并到 main 时不会触发发布。

自动化操作

  1. 在发布 PR 上（release-pr-version.yml）——如果 package.json 版本落后，则向 PR 头提交 🔖 chore(release): release version v{x.y.z}。Minor 标题 🚀 release: v{x.y.z} 使用该版本；每周发布 / release/* / hotfix/* 使用最新稳定标签 + 补丁版本。
  2. 合并后（auto-tag-release.yml）——在合并提交上打上 v{x.y.z} 标签并创建 GitHub Release。Patch 版本为最新稳定标签 +1，而不是 package.json 版本 +1。
  3. sync-main-to-canary——在推送到 main 时运行。

Agent 操作指南

用户请求发布时：

预检查（适用于所有发布类型）

创建发布分支前，验证源分支：

  • 每周发布（release/weekly-*）：必须从 canary 分支创建
  • 所有其他发布 / 热修复分支：必须从 main 分支创建；运行 git merge-base --is-ancestor main <branch> && echo OK
  • 如果分支基于错误的源分支，请从正确的基准重新创建
路由

选择正确的参考文档，并从头到尾遵循：

  • 次要版本发布 → references/minor-release.md
  • 补丁版本发布（每周发布／热修复／模型发布／数据库迁移）→ references/patch-release-scenarios.md
  • 撰写 PR 正文／发布说明（适用于任何发布类型）→ references/release-notes-style.md
硬性规则（适用于所有发布类型）
  • 不要手动修改 package.json 版本号——由 CI 处理。
  • 不要手动创建标签——由 CI 处理。
  • 次要版本 PR 的标题格式必须严格遵循（🚀 release: v{x.y.z}）。
  • 补丁版本 PR 无需明确的版本号。
  • 确保发布事实准确；不要编造指标或可用性声明。发布说明所需输入（比较基准、PR 引用、贡献者列表）必须依照 references/release-notes-style.md § Computing Inputs 中的说明从 git 获取——绝不能凭记忆或描述填写。

评论

支持 Markdown