用途：team-release 用于编排游戏项目的发布团队，从候选版本（release candidate）推进到部署。它把发布拆成多个阶段，由不同子代理分工完成，并在阶段转换处让用户确认决策。
主要能力：按 team.size 决定激活哪些代理。individual（默认）只启动 release-manager；small 增加 producer、devops-engineer、qa-lead、community-manager；studio 再增加 security-engineer、analytics-engineer、localization-lead、performance-analyst，多人游戏时还包括 network-programmer。流程覆盖发布计划、版本号提升与发布清单、并行质量门禁（回归测试、构建产物、安全审计、网络代码签核）、本地化/性能/分析验证、go/no-go 决策、部署与发布报告。
使用方式：调用时若未提供版本号，会从 production/session-state/active.md 和 production/milestones/ 推断，并用 AskUserQuestion 确认；无法推断则询问版本号。运行前会检查 project.stage 是否为 Release，未通过 /gate-check release 时默认停止，用户可显式覆盖并记录理由。各阶段通过 Agent 工具生成子代理，每个代理输出写入 production/releases/ 下的独立文件，避免并行写入冲突。
适用场景：需要结构化发布流程的游戏项目，尤其是带在线功能、多人模式或玩家数据的项目。
限制：发布就绪门禁未通过时默认不继续；NO-GO 时跳过部署阶段；自动化模式不改变阶段门禁的存在，只改变通过方式；具体配置项与默认值以项目内文档为准，资料未提供完整细节。