用途：按仓库既有的版本管理与发布流程，准备或发布一个版本。标签需包含其变更日志，发布时只走一条有证据支持的路径。
授权范围：准备阶段包括确定版本、更新变更日志与版本声明、校验并开启发布 PR；请求“准备、bump、生成说明”仅授权此阶段。发布阶段在 PR 合并后，通过仓库既有发布器创建或触发标签/发布；请求“cut、tag、publish、运行 /create-release”也授权此阶段。由 /milestone-rush 调用时，在其已验证的里程碑边界提供发布授权，复用其既定发布计划与版本，无需单独用户命令；/deliver 集成交付不是此触发条件。独立授权不明确时，只执行准备阶段。
不变量：变更日志与版本提升须先于标签，并通过 squash 合并的 PR 落地；使用仓库配置的工具与当前文档；生成的变更日志应重新生成而非手工编辑；运行声明的发布相关门禁并只报告观察到的结果；不得 amend、force-push、强制更新标签、跳过钩子，或通过多于一条路径发布。
准备：要求工作区干净，解析授权阶段、远端默认分支、变更日志/版本工具、上次发布、远端标签、工作流与发布文档；无可发布提交则停止；使用已确定的显式版本，或按项目确定性版本策略计算，两者都不确定时依据未发布的 conventional commits 推荐版本并询问；从最新远端基线创建发布分支；用项目工具生成变更日志段落并更新所有权威版本声明，项目从标签派生版本时不要臆造清单提升；运行发布相关门禁，提交 chore(release): <version>，并通过 /create-pr 开启草稿发布 PR，附变更日志段落与观察到的校验结果。仅准备请求到此结束。
发布：在发布授权下，通过 /address-feedback automatic-merge 收敛发布 PR，再用 delivery-wait 验证其 squash 合并与集成修订；复用已验证的合并，绝不给打开的 PR 分支打标签。刷新合并后的基线，重新读取实际工作流 YAML 与发布文档，识别标签创建、GitHub 发布创建、制品签名与注册表发布的各自归属方。只选一条路径，避免重复创建标签或发布：工作流拥有标签与发布则仅触发或监控；代理拥有标签、工作流拥有发布则推送一次已验证标签后监控；工作流拥有标签、代理拥有发布则验证其标签后创建一个 GitHub 发布；代理拥有两者则仅在无工作流拥有任一动作时，推送一次已验证标签并创建一个发布。归属不明确或文档与工作流冲突时停止。只执行所选路径，并验证该路径负责的最终标签目标、发布、工作流结果、制品与注册表状态；使用辅助的 wait workflow-terminal、wait tag-target、wait release-assets 操作处理这些 GitHub 状态转换，不要通过模型轮次监控未变化状态。报告时先给出发布结果、PR/发布 URL、所选发布器与当前证据，绝不把未观察到的状态描述为完成。
限制：资料未提供具体安装命令、支持平台、收费方式与更多示例。