用途：引导完成一次专业发版，覆盖版本号确定、结构化发布说明撰写、变更日志更新、提交、打标签与推送，保证各次发布的一致性与质量。开始时应声明正在使用 release 技能。
适用时机：发布项目新版本；用户说 release、cut a release、ship it、bump version；实现完成且测试通过后。不适用于进行中的普通提交，以及不值得发版的修补。
署名规则：所有提交与标签均由用户署名，不添加 Co-Authored-By: Claude 或任何 AI 署名，作者取自 git config 的 user.name 与 user.email。
流程：一、预检：运行测试，失败即停止；检查 git status 与当前分支（通常从 main 或发布分支发版）；读取当前版本。二、确定版本号：用 git log <last-tag>..HEAD --oneline 查看变更，按语义化版本判断（破坏性变更升 Major，新功能升 Minor，修复与文档升 Patch），并向用户确认。三、撰写发布说明：参照现有 RELEASE-NOTES.md 的风格，先写最重要的变更，用叙述段落加分组标题，底部 Full Changelog 使用 feat:、fix:、refactor:、docs:、chore: 等前缀，不提及 AI。四、更新各清单文件中的版本号，如 .claude-plugin/plugin.json、marketplace.json、package.json、Cargo.toml、pyproject.toml 及 README 徽章。五、提交：git add -A 后 git commit -m "release: vX.Y.Z — [摘要]"。六、打标签：git tag -a vX.Y.Z -m "vX.Y.Z"。七、推送前询问用户，确认后 git push && git push --tags。八、用 gh release create 创建 GitHub Release，必要时用 gh repo edit 更新仓库描述，并用 gh repo view、gh release view 验证。
限制与反模式：不得跳过测试、不得用“bump version”作提交信息、不得把原始 git log 当发布说明、不得跳过标签、不得强制推送发布、不得从功能分支发版（除非用户明确确认）、不得只推标签而不建 GitHub Release、统计变化时不得忘记更新仓库描述。