这个 Skill 能做什么，适合哪些场景？
cmux-release 是 cmux 仓库内置的发布工作流技能，位于 skills/cmux-release/SKILL.md。它优先通过 /release 命令驱动：自动确定新版本号（默认 minor）、从各 PR 描述的 Changelog 小节汇总用户可见变更、更新 CHANGELOG.md、运行版本递增脚本与预发布守卫脚本，最后打 tag 并推送。该技能面向 cmux 项目自身的维护者，而非 cmux 终端的普通用户。
- 运行 /release 流程：确定新版本（默认 minor）、抓取自上个稳定 tag 以来所有已合并 PR 的 Changelog 行、更新 CHANGELOG.md、提交、运行守卫脚本后打 tag 推送
- 执行 ./scripts/bump-version.sh 递增 MARKETING_VERSION 与 CURRENT_PROJECT_VERSION（支持 minor/patch/major/显式版本号）
- 用 GraphQL 一次性抓取已合并 PR，并用 changelog-lines.jq 分类：有效行收录、none 跳过、区间内的 revert 跳过、缺 Changelog 小节的 PR 列出待人工确认
- 执行 ./scripts/release-pretag-guard.sh，失败时重新递增构建号并重试
- 校验发布产物（cmux-macos.dmg 挂到 tag 上）与签名/公证所需的 GitHub secrets
- cmux 维护者准备一次新版本发布，想按项目既定流程自动汇总变更日志并打 tag
- 发布时 pretag 守卫失败，需要弄清构建号递增的正确补救步骤
- 评审某次发布该包含哪些 PR：确认 revert、缺失 Changelog 小节的 PR 如何归类
- 排查发布产物未附加、签名或公证 CI 失败等资产层面的问题
- 仅适用于 cmux 仓库本身——其他项目的发版流程不适用，除非照搬其脚本与约定
- 不涉及应用功能开发；cmux 终端用户寻找使用帮助时应看 README 与官方文档
- 依赖项目内的私有脚本（bump-version.sh、release-pretag-guard.sh）和内部等待工具 glaeda-gh，脱离该仓库无法独立运行
如何安装这个 Skill？
- 本评审为纯静态源码评审，未执行任何脚本或发布流程，结论置信度低。
- 引用的关键脚本（bump-version.sh、release-pretag-guard.sh、notary-auth.sh）未包含在证据中，使用前应自行核对其行为。
- 该技能仅适用于 cmux 仓库维护者，普通用户触发它没有意义；发布流程完全依赖 GitHub 与 Apple 服务。
- 仓库 license 元数据为 NOASSERTION，实际为 GPL-3.0-or-later 与 BUSL-1.1 双许可，分发或复用相关脚本前需确认许可边界。
- 发布涉及签名与公证 secrets，操作时应确认 secret 范围与临时密钥文件的清理符合预期。
- Shell / 命令行
- 网络访问
- 本地文件系统
cmux repository checkoutscripts/bump-version.shscripts/release-pretag-guard.shGitHub GraphQL access for changelog gathering
该技能随 cmux 仓库分发，位于 skills/cmux-release/，克隆仓库后即可供兼容 Agent Skills 的客户端读取。源材料未给出独立的安装命令，请勿假设存在 npm/pip 等安装方式。
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/manaflow-ai/cmux.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/cmux-release" ~/.claude/skills/
rm -rf "$tmp"根据源仓库地址和 Skill 路径自动生成，只复制这个 Skill 的文件夹。如果上文有作者提供的安装方式，请优先按作者说明操作；想只在当前项目中使用，把 ~/.claude/skills 换成项目里的 .claude/skills。
如何使用这个 Skill？
安装后，把下面任意一句发给 Agent 即可触发：
- 帮我准备下一次 cmux 发布，用默认 minor 版本号走 /release 流程
- pretag 守卫失败了，按流程递增构建号并重试打 tag
- 上个 v tag 到现在合并的 PR 里哪些没有 Changelog 小节需要人工补一下？
- 确认这次发布的 cmux-macos.dmg 签名和公证 secrets 是否齐全
优先使用项目文档化的 /release 命令触发完整发版流程；技能本身在准备或排查 cmux 发布时被调用。核心流程：确认版本号后运行 bump 脚本，提交构建号变更，运行守卫脚本，再打 tag 推送：
./scripts/bump-version.sh # 默认 minor
./scripts/release-pretag-guard.sh
git tag vX.Y.Z
git push origin vX.Y.Z可选参数：bump-version.sh 支持 patch、major 或显式版本号（如 1.0.0）。tag 推送会创建 CI run，用运行 ID 观察而非轮询 GitHub。签名需要 APPLE_CERTIFICATE_BASE64 等 secrets，公证需要 ASC_API_* 密钥。
这个 Skill 有哪些优点和局限？
- 把 cmux 发版约定（Changelog 由 PR 描述聚合、构建号必须递增、守卫脚本前置）固化为可执行流程，减少人工遗漏
- 对 revert、无 Changelog 小节的 PR 等边界情况有明确分类与人工确认机制
- 文档详实，含发布检查清单引用与失败排查指引
- 高度绑定 cmux 仓库的脚本、secrets 与内部工具（glaeda-gh），无法直接迁移到其他项目
- GPL-3.0-or-later 许可（服务端为 BSL 1.1），纳入他处工作流需注意合规
- 签名/公证环节依赖未在本技能内验证的 GitHub secrets 配置，出问题时需按引用文档排查
这个 Skill 与同类方案有什么区别？
与相关 Skills 并排比较；分数均按同一 FSRS 标准得出。
| Skill | FS 评分 | Star 数 | 最近更新 | License |
|---|---|---|---|---|
| cmux 发布助手 本页 | 53 · 谨慎使用 | ★ 28k | 1 天前 | NOASSERTION |
| 通用发布工作流 | 51 · 谨慎使用 | ★ 4.3k | 18 天前 | MIT |
| DeepChat 版本发布助手 | 46 · 谨慎使用 | ★ 6.4k | 3 天前 | Apache-2.0 |
| ORCH — AI 智能体编排器 | 49 · 谨慎使用 | ★ 170 | 2 个月前 | MIT |
| Bump Version — AionUi 版本发布自动化技能 | 38 · 不推荐 | ★ 33k | 1 个月前 | Apache-2.0 |
源材料未列出替代方案。与通用的语义化版本/发布 Action（如手动打 tag 流程）相比，本技能的特点是 Changelog 直接从 PR 描述聚合而非要求改动 CHANGELOG.md，但仅覆盖 cmux 自身的发版路径。
FollowSkills 如何评估这个 Skill？
该技能面向 cmux 仓库维护者的发布流程，文档明确披露了签名与公证所需的 GitHub secrets（APPLE_CERTIFICATE_*、ASC_API_*）及密钥临时文件的 mode-600 处理和删除方式，数据流透明度较好；但 bump-version.sh、release-pretag-guard.sh 等关键脚本未在证据中提供，回滚路径仅部分描述，发布者身份未经注册库验证，仓库 license 元数据为 NOASSERTION，故未达满分。无恶意行为或隐藏数据外传迹象。
指令自洽，命令序列明确，release-checklist.md 提供了详细的失败分类处理（pretag guard 失败、签名/公证失败、夜间公证恢复流程），失败反馈质量较高；但静态评审无法执行，bump-version.sh 与 pretag guard 脚本本体缺失，无法确认可复现性，按静态校准上限计 10。
触发条件在 description 中清晰（准备或排查 cmux 发布时使用），受众明确为 cmux 维护者，边界隐含清晰（不适用于非本仓库）；但主要面向内部工作流，对 FollowSkills 中国用户而言核心依赖 GitHub Actions、Apple 公证与 glaeda-gh 工具，可及性与适用面有限，扣分计 9。
文档分层良好（SKILL.md 主流程 + references/checklist + openai.yaml 元数据），安装依赖与失败处理有说明，仓库实际含 GPL-3.0-or-later 与 BUSL-1.1 双许可且 LICENSE 全文可查；但技能自身的版本号、变更日志与明确维护责任声明缺失，license 元数据 NOASSERTION 与实际许可不符，扣分计 9。
核心任务（版本提升、changelog 聚合、pretag 守卫、打标签、资产预期）描述完整且附带判断标准与失败恢复，边际价值高于人工记忆操作；但静态评审无法验证产出的直接可用性，脚本未随证据提供，按静态校准低于上限计 6。
存在可追溯的引用（release.md、changelog-lines.jq、release-checklist.md、CI workflow 文件、scripts 路径），仓库含真实 CI 工作流佐证执行环境；但静态评审无法独立复现发布流程，引用的脚本与命令文件不在证据范围内，覆盖率薄，计 4。
点击维度查看打分理由
证据充分度：低 — 主要依赖静态检查、作者材料或有限演示；适合发现线索，不适合做高风险决策。
查看完整评分方法 →