team-release

---
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**：监控接收到的缺陷报告，排查回归问题
- 如果出现问题，安排发布后复盘

## 输出
涵盖以下内容的总结报告：发布版本、范围、质量门禁结果、放行/中止决策、部署状态和监控计划。