用途：按仓库既有约定为发布打标签（patch、minor、major），并把发布流程跟进到成功状态。请求本身即授权创建、推送标签并运行仓库既定的发布工作流；只有必需值无法推导或仓库状态导致发布有歧义时才询问用户。
主要流程与能力： 1）先同步到 origin 默认分支：检查 origin URL，用 git ls-remote --symref origin HEAD 解析远程符号 HEAD 得到默认分支，执行 git fetch origin --tags --prune；从 origin URL 解析 GitHub owner/repository，并在每条 gh 命令中显式传 --repo 或 -R，避免被 GH_REPO 或其他 remote 重定向。以 git rev-parse origin/<default-branch> 记录候选发布提交；默认分支为红或必需检查未通过时不得发布。 2）读取既有发布约定：用 gh release list -R <owner/repository>、git ls-remote --tags --refs origin 'refs/tags/<relevant-prefix>*' 查看历史，确定版本格式（是否带前导 v、包名前缀、预发布或构建后缀）、标签类型（轻量、附注或签名，用 git cat-file -t 与 git verify-tag 判断）以及发布机制（仅推送标签由流水线接管，还是用 gh release create 创建 Release）。无历史版本时使用仓库文档中的起始版本或询问。 3）计算下一版本：在相关系列最新标签基础上做语义化递增，patch 为 x.y.(z+1)，minor 为 x.(y+1).0，major 为 (x+1).0.0，并保留前导 v 与包名前缀；预发布到稳定版的转换遵循仓库历史，无法确定时询问。 4）打标签前复核：重新 fetch 并确认默认分支、其 SHA、最新相关标签未变，目标标签不存在，发布 SHA 的必需检查为绿；如有变化则重新计算。打标签时显式指向抓取到的远程 HEAD，轻量用 git tag <version> origin/<default-branch>，附注用 git tag -a <version> origin/<default-branch> -m "<version>"；若仓库既有标签未签名需加 --no-sign，已签名则签名。 5）推送并跟踪到绿：执行 git push origin <version>；若约定包含 Release，推送后再用 gh release create <version> --verify-tag ... 并传 --repo。用 git ls-remote 校验标签解析（附注或签名标签比对 peeled ^{}），用 gh run watch --exit-status 跟踪流水线，用 gh release view 确认产物，全部满足才算完成。 6）报告：说明切出的版本、指向的提交 SHA、标签类型及发布或流水线结果。
限制：不打红分支的发布；必需检查未决时不得打标签；仅在授权范围内修复失败；不改变工作树与本地分支；资料未提供具体收费、价格或平台信息。