自动化与运维 release-automationsemverchangeloggit-taggingmacos-notarizationgithub-releasesconventional-commits

Chops 发布流水线技能

从 git 历史推断下一版本号、更新 CHANGELOG 与官网版本,并一条命令跑完打包、公证和 GitHub Release 的发布自动化技能。

FollowSkills 评估 · FSRS-1.0
谨慎使用
53/ 100 五分制 2.7 / 5
本条评估按 FSRS 1.0 标准完成,维度分不做换算,已进入按 FSRS 2.0 重新评估的复核队列。
1 2 3 4 5 6
1价值适配9 / 20 · 2.3/5

项目自身的发布流程自动化(含 macOS 签名公证、git tag、发布脚本),服务于该项目维护者,涉及代码签名凭据和实际发布操作,不是通用技能。

2可靠性12 / 20 · 3.0/5
3安全性16 / 25 · 3.2/5

涉及 Apple 签名公证凭据和实际软件发布,但有前置检查(干净工作区、分支确认)作为防护。

4证据4 / 15 · 1.3/5
5易用性7 / 10 · 3.5/5
6维护性5 / 10 · 2.5/5
证据充分度: 评估于 2026年7月17日
评估证据 [1]
查看完整评分方法 →

这个 Skill 能做什么,适合哪些场景?

这是 Chops(一个 macOS AI 技能管理应用)仓库内置的 Claude Code 技能,用于自动执行该项目自身的发布流程。它会检查发布前提(.env、Apple 公证凭证、干净的 git 工作区),根据 conventional commit 消息推断 semver 版本号,与用户确认后改写 CHANGELOG、更新营销网站的版本号,最后运行项目自带的 release.sh 完成归档、DMG、公证、打标签和 GitHub Release。它高度绑定 Chops 仓库的脚本和文件结构,更适合作为仓库内工作流而非通用发布工具。

读取 git 标签和提交历史来推断下一个 semver 版本(feat 提交触发 minor,fix/chore/docs 触发 patch,BREAKING CHANGE 询问用户);通过 xcrun notarytool 验证 Apple 公证的 keychain 配置;改写 CHANGELOG.md 中的 Unreleased 段落为用户视角的条目;编辑 site/src/pages/index.astro 更新官网显示的版本号;提交并推送后执行 ./scripts/release.sh <版本>,由脚本完成 xcodegen、归档、导出、DMG、公证、盖章、git 标签、appcast 更新和 GitHub Release。

  1. Chops 仓库的维护者在合并一批 feat 提交后需要发布新的 minor 版本时,可以让技能自动推断版本并跑完整个发布流水线
  2. 维护者想确保发布前公证凭证和 .env 配置就绪,避免发布脚本在最后一步失败
  3. 团队希望 CHANGELOG 条目从提交消息改写为面向用户的功能描述,而不是机械复制 commit 前缀
  4. 发布后需要同步更新 chops.md 营销网站上展示的最低版本号
  5. 想学习如何为 Claude Code 编写带人工确认节点和多步骤流水线的仓库内技能的开发者

这个 Skill 有哪些优点和局限?

优点
  • 完整覆盖从版本推断到公证、打标签、GitHub Release 的全流程,减少手工操作
  • 内置安全护栏:缺 .env、工作区不干净、不在 main 分支时都会直接停止
  • 每个关键决策(版本号、CHANGELOG 条目)都要求用户确认,不会静默发布
  • 发布脚本失败时不自动重试,避免重复公证或重复打标签造成混乱
  • CHANGELOG 条目会改写为用户视角的描述,而非照抄提交消息
局限
  • 仅适用于 Chops 这个仓库,依赖其特有的 release.sh、site/ 目录结构,不具备通用性
  • 依赖 mcp__conductor__AskUserQuestion 这一特定 MCP 工具,换环境需要改造
  • 需要 macOS 和有效的 Apple 开发者公证配置,成本和门槛不低
  • 仓库无自动化测试,README 明确说明只能手动验证
  • 许可证为 FSL-1.1-MIT(非 OSI 标准开源),商用复用前需确认条款

如何安装这个 Skill?

该技能随 Chops 仓库一起分发,位于 .claude/skills/release/SKILL.md。克隆仓库后 Claude Code 会自动发现它:git clone https://github.com/Shpigford/chops.git && cd chops。无需单独安装;但要实际运行发布,还需按项目根目录的 .env.example 配置 APPLE_TEAM_ID、APPLE_ID、SIGNING_IDENTITY_NAME,并在 macOS 上配置好公证凭证。

如何使用这个 Skill?

在 Chops 仓库内、main 分支且工作区干净的状态下,对 Claude Code 说类似"帮我把这些改动发布一个新版本"或"cut a new release"即可触发。技能会先验证前提条件,再逐步与你确认版本号和 CHANGELOG 条目,最后运行 release.sh。注意:该技能深度依赖 Chops 仓库的 scripts/release.sh、site/ 目录和 mcp__conductor__AskUserQuestion 工具,脱离此仓库无法直接使用。

这个 Skill 与同类方案有什么区别?

它本质上是一个仓库专属的发布工作流,与通用的 semantic-release 或 changesets 等发布工具解决的是同一类问题(从提交推断版本、生成变更日志、自动发布),但那些工具是语言生态内的通用方案,而这个技能是为 Chops 的 macOS 公证发布流水线定制的 Claude Code 编排层。

常见问题

我能在自己的项目里用这个技能吗?
不能直接用。它硬编码了 Chops 的 release.sh 脚本、site/src/pages/index.astro 路径和 conductor MCP 工具。想借鉴的话,需要把文件路径和脚本替换为你自己项目的发布流程。
运行它需要什么前置条件和费用?
需要 macOS 15+、Apple 开发者账号(公证需要 app-specific password)、git、以及仓库根目录配置好的 .env。公证本身随 Apple Developer Program 订阅提供,无额外按次费用。
发布脚本失败了会怎样?
技能会明确规则:不自动重试,直接把错误输出报告给用户并停止。这是有意设计,防止重复打标签或重复公证。你需要排查后手动重新触发。
版本号是自动决定的吗?
部分自动:提交消息遵循 conventional commits 时会按规则推断(feat→minor,fix/chore→patch),但遇到 BREAKING CHANGE 或消息含糊时,会通过交互式提问让你决定,且最终版本总是需要你确认后才会发布。

同仓库的其他 Skills

均来自 Shpigford/chops

相关 Skills