release 技能旨在将软件发布流程标准化和自动化。它按照固定顺序执行：版本号提升、发布提交、附注标签、推送、GitHub 发布。其中步骤 1-4 为本地操作且可撤销；步骤 5-6 涉及发布，每一步都需要用户明确确认。
用途
该技能用于在仓库中执行一次完整的发布操作。它要求用户指定版本提升类型（patch、minor、major 或显式版本号），若未指定则询问。如果仓库的 AGENTS.md、CLAUDE.md、RELEASING.md 或 CONTRIBUTING.md 中描述了发布流程，应优先遵循该流程，仅用本技能的步骤填补缺失部分。
主要能力
- 预检：检查工作区是否干净、当前分支是否为默认分支（或仓库文档指定的发布分支）、是否与上游同步、gh 是否已认证。任何不满足条件的情况都会停止并报告。
- 查找所有版本文件：检查 package.json、pyproject.toml、Cargo.toml、.claude-plugin/plugin.json（及 marketplace.json 中的对应条目）、manifest.json、version.txt、VERSION、src/**/init.py 中的 version 等文件中是否存在当前版本号，并通过 grep 搜索当前版本字符串以发现手动维护的副本（如 VERSION 常量、README 徽章、文档元数据）。要求所有文件中的版本号一致，不一致则停止并询问。
- 提升版本并更新变更日志：按照 SemVer 规则计算新版本号（修复用 patch、向后兼容的功能用 minor、破坏性变更用 major，并将低位部分归零）。对于 1.0 之前的项目，minor 可视为破坏性变更，需说明选择理由。编辑步骤 2 中找到的每个位置为新版本号。在 CHANGELOG.md 中，将 ## [Unreleased] 重命名为 ## [X.Y.Z] - YYYY-MM-DD（当天日期，ISO 格式），并在上方添加新的空 ## [Unreleased]；若文件底部有比较链接也需更新。没有变更日志时可提议创建，用户拒绝则跳过。运行仓库的构建和测试命令（如有）。要求 grep 旧版本号仅能找到历史条目（变更日志章节、其他包的锁文件条目），且构建和测试通过。
- 本地提交与打标签：使用 git add 添加步骤 2 中的每个文件和 CHANGELOG.md，查看暂存差异统计，提交信息为 "chore(release): vX.Y.Z"，创建附注标签 "Release vX.Y.Z"。若现有标签格式不同，使用仓库自身的标签格式（通过 git tag --sort=-v:refname | head -3 查看）。要求 git show --stat vX.Y.Z 显示发布提交仅包含这些文件。
- 确认后推送：向用户展示提交、标签、远程和分支信息，以及推送标签会触发什么（检查 .github/workflows/ 中的 on: push: tags 或 on: release，通常是包发布）。通过 AskUserQuestion 询问：推送提交和标签 / 暂不推送。仅在用户明确同意后执行 git push origin <branch> 和 git push origin vX.Y.Z，先推送提交再推送标签，以确保标签指向远程已有的提交。
- 确认后创建 GitHub 发布：再次询问后，若用户同意，执行 gh release create vX.Y.Z --title "vX.Y.Z" --notes-file <保存到临时文件的变更日志章节>。没有变更日志时使用 --generate-notes。然后运行 gh run list --limit 3 显示发布启动的工作流并报告其状态。要求用户获得发布 URL 和任何触发工作流的状态。
使用方式
通过调用技能并传入版本提升参数（$ARGUMENTS）使用，参数可为 patch、minor、major 或显式版本号；为空时技能会询问。技能内部按步骤执行，并在关键节点（推送前、创建发布前）要求用户确认。
适用场景
适用于需要规范发布流程的软件仓库，尤其是包含多种版本文件、变更日志和 GitHub 发布的项目。也适用于遵循特定发布文档的仓库。
限制
- 要求工作区干净、位于默认分支且与上游同步、gh 已认证，否则停止。
- 版本文件不一致时停止并询问。
- 基于 Git 标签的版本推导项目（如 setuptools-scm、hatch-vcs、semantic-release）无需修改版本文件，标签即为版本提升。
- 推送和创建发布需要用户明确确认。
- 发布后删除标签或发布需用户同意；已发布的包版本通常无法复用，应发布下一个补丁版本。