| name | team-release |
| description | 编排发布团队：协调 release-manager、qa-lead、devops-engineer 和 producer，从候选版本到部署执行完整发布流程。 |
| argument-hint | [版本号或 'next'] |
| user-invocable | true |
| allowed-tools | Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite |
当此技能被调用时，通过结构化管线编排发布团队。
决策点： 在每个阶段转换时，使用 AskUserQuestion 将子代理的提案以可选项的形式呈现给用户。在对话中展示代理的完整分析，然后用简洁的标签记录决策。用户必须批准后才能进入下一阶段。
团队构成
- release-manager — 发布分支、版本管理、变更日志、部署
- qa-lead — 测试签收、回归测试套件、发布质量门禁
- devops-engineer — 构建管线、产物、部署自动化
- producer — 放行/中止决策、利益相关者沟通、排期
委派方式
使用 Task 工具将每位团队成员作为子代理启动：
subagent_type: release-manager — 发布分支、版本管理、变更日志、部署subagent_type: qa-lead — 测试签收、回归测试套件、发布质量门禁subagent_type: devops-engineer — 构建管线、产物、部署自动化subagent_type: producer — 放行/中止决策、利益相关者沟通
始终在每个代理的提示中提供完整上下文（版本号、里程碑状态、已知问题）。在管线允许的情况下并行启动独立代理（例如，阶段 3 的代理可以同时运行）。
管线
阶段 1：发布规划
委派给 producer：
- 确认所有里程碑验收标准均已满足
- 识别从本次发布中推迟的范围项
- 设定目标发布日期并通知团队
- 输出：附带范围确认的发布授权
阶段 2：候选版本（Release Candidate）
委派给 release-manager：
- 从约定的提交切出发布分支
- 在所有相关文件中递增版本号
- 使用
/release-checklist 生成发布检查清单
- 冻结分支——不再接受功能变更，仅允许缺陷修复
- 输出：发布分支名称和检查清单
阶段 3：质量门禁（并行）
并行委派：
- qa-lead：执行完整回归测试套件。测试所有关键路径。确认不存在 S1/S2 级别缺陷。签收质量。
- devops-engineer：为所有目标平台构建发布产物。验证构建干净且可复现。在 CI（持续集成）中运行自动化测试。
阶段 4：本地化与性能
委派（如果资源允许，可与阶段 3 并行运行）：
- 验证所有字符串已完成翻译（如可用，委派给 localization-lead）
- 针对性能目标运行基准测试（如可用，委派给 performance-analyst）
- 输出：本地化和性能签收
阶段 5：放行/中止决策
委派给 producer：
- 收集以下人员的签收：qa-lead、release-manager、devops-engineer、technical-director
- 评估所有未解决的问题——是阻塞项还是可以随版本发布？
- 做出放行/中止决策
- 输出：附带理由的发布决策
阶段 6：部署（如通过）
委派给 release-manager + devops-engineer：
- 在版本控制中打标签
- 使用
/changelog 生成变更日志
- 部署到预发布环境进行最终冒烟测试
- 部署到生产环境
- 发布后监控 48 小时
阶段 7：发布后
- release-manager：生成发布报告（已发布内容、已推迟内容、度量数据）
- producer：更新里程碑跟踪，通知利益相关者
- qa-lead：监控接收到的缺陷报告，排查回归问题
- 如果出现问题，安排发布后复盘
输出
涵盖以下内容的总结报告：发布版本、范围、质量门禁结果、放行/中止决策、部署状态和监控计划。
