| 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:监控接收到的缺陷报告,排查回归问题
- 如果出现问题,安排发布后复盘
输出
涵盖以下内容的总结报告:发布版本、范围、质量门禁结果、放行/中止决策、部署状态和监控计划。