team-release

团队发布

参数检查： 如果未提供版本号：

1. 读取 production/session-state/active.md 和 production/milestones/ 中最新的文件（如果存在），以推断目标版本。
2. 如果找到版本号：报告“未提供版本参数 — 已根据里程碑数据推断为 [version]。继续。”然后通过 AskUserQuestion 确认：“正在发布 [version]。是否正确？”
3. 如果无法找到版本号：使用 AskUserQuestion 询问“应发布哪个版本号？（例如，v1.0.0）”，并等待用户输入后再继续。不要默认使用硬编码的版本字符串。

调用此技能时，通过结构化流水线协调发布团队。

决策点： 在每个阶段转换时，使用 AskUserQuestion 将子代理的提议作为可选项呈现给用户。先在对话中写出 Agent 的完整分析，再用简洁标签记录决定。 在 collaborative 模式下，用户必须先批准，才能进入下一阶段。 在 guided 模式下，流水线会自动推进，除非某个阶段处于 BLOCKED 状态； 在 autonomous 模式下，流水线会端到端运行，并通过 log_decision 记录每个阶段的结果。automation_always_ask 类别中的决定（is_always_ask_category 辅助函数）无论处于何种模式，始终都会提示用户。参见 .claude/docs/automation-modes.md。

阶段 0：解析配置

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,team.size,workflow,project.stage

已在上方解析 — 按原样使用；--review 会覆盖 review_mode。未阻止 → 使用 .claude/docs/config-resolution.md 中的默认值。

阶段检查 — 必须在启动任何流程前进行。 此技能会发布版本，而 /gate-check release 是必须先通过的就绪门禁；只有该门禁的结果为 PASS 时，project.stage 才会设为 Release。如果解析出的 project.stage 是其他任何值 — Polish、更早的阶段或未设置 — 必须在阶段 1 前停止，且不启动任何流程：

“发布就绪门禁尚未通过（project.stage: [stage]）— 请先运行 /gate-check release。”

然后在所有 automation 模式下通过 AskUserQuestion 提问 — 绝不能代替用户决定是否覆盖：[A] 停止 — 我将运行 /gate-check release（推荐） / [B] 仍要继续 — 覆盖阶段检查。选择 [A] 时，结束运行：结论为 BLOCKED — 发布门禁未通过。选择 [B] 时，用普通文本询问原因，然后将覆盖记录为 Stage override: project.stage was [stage] — release gate not passed; the user chose to proceed: [reason]，并写入阶段 1 简报、go/no-go 记录（go-no-go-[version].md）和最终报告。覆盖绝不会改变阶段本身。

review_mode 决定总监门禁的深度，而此流水线没有总监门禁：无论 review_mode 为何，以下阶段都不会启动 CD-、TD-、PR- 或 AD-PHASE-GATE。其阶段门禁是流水线自身的决策点（定义见下文 team.size），参与这些门禁的 Agent 是团队成员，而非总监门禁。

automation 控制上方的“决策点”说明。有关各模式如何改变流水线行为，请参见上方的“决策点”说明和 .claude/docs/automation-modes.md。 team.size：哪些 Agent 处于活跃状态（与 review_mode 的门禁深度和工作流文档正交）。

• individual（默认）：仅 release-manager。其他 Agent 由 release-manager 咨询，不单独生成。
• small：增加 producer、devops-engineer、qa-lead 和 community-manager。
• studio：增加 security-engineer、analytics-engineer、localization-lead、performance-analyst；如果游戏支持多人游戏，还会增加 network-programmer（即文档中所述的完整流程）。 在 individual 模式下，需要使用的非核心 Agent 会由最近的活跃核心 Agent 负责，并附上说明性备注。“阶段门禁”指本流程列出的、以 AskUserQuestion 决策点结束的任何阶段——包括上文“决策点”中的转换、阶段检查或第 6 阶段的部署问题，不论 automation 模式为何。guided 和 autonomous 会改变通过门禁的方式（自动推进或通过 log_decision 记录），但不会改变它是否属于门禁，因此以下有界例外条件（3）在所有模式下都适用于此类阶段。仅限“阶段门禁”的 Agent 会在这些节点生成，不会在其他节点生成。以下流程中的所有阶段均适用此活跃集范围：任何阶段提及活跃集以外的 Agent 时，都由最近的核心 Agent 负责，而不是生成该 Agent。

在第 1 阶段之前公布活跃集——绝不能默默缩减。 生成任何 Agent 之前，用一行说明本次运行实际会生成哪些 Agent，以及下方流程提及但在已确定的 team.size 下不会生成哪些 Agent。例如：

活跃集（team.size: <已确定的值>）：<上文该级别所列的 Agent>。 本次运行不会生成：<此流程提及的所有其他 Agent> — 由 <最近的活跃核心 Agent> 负责。提高 team.size（或 modes.rigor）可扩大范围。

直接根据上方的 team.size 列表和本文流程提及的 Agent 填写，不要依据示例。两个集合会因编排器而异。

下方流程读起来像是多个 Agent 并行执行，但在当前默认设置下，实际只会有一到两个 Agent——team-release 提及十个 Agent，却只运行一个；team-narrative 在五个阶段中提及六个 Agent，却只运行 writer。这种缩减是正确的：team.size 以严谨度为先，而较窄的默认范围是控制 token 用量的手段。 如果不说明这一点，读者就无法分辨这是正确缩减的运行，还是流程故障；而且，上文“由最近的核心 Agent 负责，并附上说明性备注”这条逐个 Agent 的规则会在路由时触发，却不会说明整体运行的形态。

这与本文其他位置有关跳过检查的报告规则相同：对阅读输出的人来说，执行了约束却从未明示，与从未执行约束无法区分。

团队组成

• release-manager — 发布标签、版本管理、更新日志、补丁说明、部署
• qa-lead — 测试签核、回归测试套件、发布质量门禁
• devops-engineer — 构建流水线、构建产物、部署自动化
• security-engineer — 发布前安全审计（如果游戏包含在线／多人游戏功能或玩家数据，则启用）
• network-programmer — 网络代码稳定性签核（如果游戏支持多人游戏，则启用）
• analytics-engineer — 验证遥测事件是否正确触发、仪表板是否已上线
• localization-lead — 验证所有已发布字符串均已翻译
• performance-analyst — 根据性能目标对发布构建进行基准测试
• community-manager — 根据补丁说明撰写上线公告和面向玩家的信息
• producer — 是否发布的决策、利益相关者沟通、排期

如何委派

使用 Agent 工具将每位团队成员作为子代理启动：

• subagent_type: release-manager — 发布标签、版本管理、变更日志、补丁说明、部署
• subagent_type: qa-lead — 测试签核、回归测试套件、发布质量门禁
• subagent_type: devops-engineer — 构建流水线、构建产物、部署自动化
• subagent_type: security-engineer — 在线／多人游戏／数据功能的安全审计
• subagent_type: analytics-engineer — 遥测事件验证和仪表板就绪情况
• subagent_type: community-manager — 根据补丁说明撰写发布公告
• subagent_type: producer — 是否发布的决策、利益相关方沟通
• subagent_type: network-programmer — 网络代码稳定性签核（如果游戏包含多人游戏，则调用）
• subagent_type: localization-lead — 翻译完整性签核（第 4 阶段）
• subagent_type: performance-analyst — 对照目标进行性能基准测试（第 4 阶段）

向每位代理简要说明任务，不要倾倒上下文。 只读取一次共享输入，并在提示中传递提炼后的简报：仅提供每位代理实际需要的内容，绝不要提供你已读过的文档路径（代理拿到路径后会重新读取整个文件）。只有在你尚未读过某份文档且只有该代理需要它时，才提供路径。

每条代理提示都必须以返回约定结尾： “将完整输出写入 [path] — 该指定路径即为下方有限例外范围内授权你写入的位置，因此无需另行申请批准，直接写入即可。仅返回 (1) 已写入的路径，(2) 不超过 5 条的决策摘要，(3) 需要阻塞处理／关注的事项，每项一行。不要复述你读过的文档。” 没有这段约定，代理会把读过的所有内容都返回到当前会话中。

将 [path] 替换为实际路径。 每位代理的文件都应位于 production/releases/ 下，但固定位置的两份文件除外。由当前启用的代理代替未启用的代理时，应写入该代理对应的文件：

阶段／代理	写入位置	目标位置由谁确定
第 1 阶段 producer	production/releases/release-plan-[version].md	此技能
第 2 阶段 release-manager	production/releases/release-checklist-[version].md	/release-checklist
第 3 阶段 qa-lead	production/releases/qa-gate-[version].md	此技能
第 3 阶段 devops-engineer	production/releases/build-[version].md	此技能
第 3 阶段 security-engineer	production/releases/security-signoff-[version].md	此技能
第 3 阶段 network-programmer	production/releases/netcode-signoff-[version].md	此技能
第 4 阶段 localization-lead	production/releases/localization-signoff-[version].md	此技能
第 4 阶段 performance-analyst	production/releases/performance-signoff-[version].md	此技能
第 4 阶段 analytics-engineer	production/releases/analytics-signoff-[version].md	此技能
第 5 阶段 go/no-go	production/releases/go-no-go-[version].md	此技能
第 6 阶段 release-manager	docs/patch-notes/[version].md	/patch-notes
第 6 阶段 community-manager	production/releases/announcement-[version].md	此技能
第 7 阶段 release-manager	production/releases/release-report-[version].md	此技能

上述 13 项输出都必须注明目标位置。 /release-checklist 已写入 production/releases/，/patch-notes 已写入 docs/patch-notes/[version].md，因此无论由哪个技能生成，发布记录都会归到同一处。

每位代理单独写入一个文件，不要追加到同一文件。 第 3 阶段和第 4 阶段会并行启动代理；两位代理同时向一个文件追加内容会产生竞争，后写入的部分可能悄无声息地消失。 为什么这不会违反 Collaboration Protocol。 CLAUDE.md 要求 Agent 在执行 Write/Edit 前询问“可以将内容写入 [filepath] 吗？”。在此处启动的子 Agent 会不经询问直接写入，这是有意设定的、范围明确的例外，并非疏忽——此前已对 consistency-check 追加内容到 active.md 做出相同处理。只有同时满足以下三个条件时，这项例外才成立：（1）路径由你在提示词中指定，因此用户在批准阶段时也批准了目标位置；（2）这是 production/、docs/ 或 tests/ 下的新产物，绝不涉及修改现有源文件或配置；（3）生成该产物的阶段本身受 AskUserQuestion 把关，只有在此之后流水线才会继续。若不满足这三个条件，Agent 必须询问。不要通过逐个询问子 Agent 来“修复”此问题——每个阶段都要给每个 Agent 单独提问，会让编排器无法使用，这正是设置此例外的原因。

在流水线允许的情况下并行启动互相独立的 Agent（例如，Phase 3 的 Agent 可以同时运行）。

流水线

Phase 1：发布规划

委派给 producer：

• 确认所有里程碑验收标准均已满足
• 确定本次发布中推迟的范围项
• 设定目标发布日期并告知团队
• 输出：含范围确认的发布授权

Phase 2：发布候选版本

委派给 release-manager：

• 在 main 上相关的所有文件中更新版本号；包含版本号更新的提交即为发布候选版本。开发采用基于主干的模式——发布是在 main 上打标签（在 Phase 6 执行），而不是创建分支
• 确认 Polish 的发布检查清单（/release-checklist，在 /gate-check release 前运行）已针对该候选版本完成；仅当尚无检查清单时才在此处运行
• 仅当本次发布需要稳定化（冻结、平台认证）时，才从候选版本创建 release/[version] 分支——该分支上只能修复 Bug，且每项修复都必须同时合入 main
• 输出：发布候选版本提交（以及已创建的 release/* 分支，如有）和检查清单

Phase 3：质量门禁（并行）

并行委派：

• qa-lead：执行完整回归测试套件。测试所有关键路径。确认不存在 /gate-check release 会针对此 workflow 拦截的未解决 Bug：所有层级均不得有 S1；在 full 层级下，S2 和 S3 也不得存在。对质量签字确认。
• devops-engineer：为所有目标平台构建发布产物。确认构建干净且可复现。在 CI 中运行自动化测试。
• security-engineer （如果游戏具有在线功能、多人游戏功能或玩家数据）：开展发布前安全审计。审查身份验证、反作弊和数据隐私合规性。对安全状况签字确认。
• network-programmer （如果游戏具有多人游戏功能）：对网络代码的稳定性签字确认。验证负载下的延迟补偿、重新连接处理和带宽使用情况。

当任一 Agent 属于当前激活集合时，根据 project.yaml 中的 platform.online 和 platform.multiplayer，以及游戏是否存储玩家数据，判断是否满足其启用条件。缺少某个键并不等于值为 false：应询问用户，而不是假设游戏处于离线状态。基于这些条件跳过的 Agent 必须在 Phase 3 输出中注明名称，例如：security-engineer: not spawned — platform.online: false, platform.multiplayer: false, no player data。

Phase 4：本地化、性能与分析

委派（资源充足时可与 Phase 3 并行运行）：

• 验证所有字符串均已翻译（如有 localization-lead，则委派给它）
• 对照目标运行性能基准测试（如有 performance-analyst，则委派给它）
• analytics-engineer：验证所有遥测事件均能在发布构建中正确触发。确认仪表板能接收数据。检查关键漏斗（引导、进度、变现，如适用）均已完成埋点。
• 输出：本地化、性能和分析的签字确认——每个 Agent 各输出一个文件（见上表）

阶段 5：Go/No-Go

委派任务前，先获得 technical-director 的发布签核。producer 无法生成 Agent，因此由编排器负责：仅当 review_mode: full 时才生成 technical-director；这属于总监审查，而非 PHASE-GATE，因此 lean 和 solo 模式会跳过。请其针对候选版本的技术状态给出 GO、CONCERNS 或 NO-GO；若无法评估，则给出 NOT ASSESSED 并说明无法读取的内容。如果未生成该 Agent，Go/No-Go 记录应写为 technical-director sign-off: not run (review_mode: <mode>)，而不是将其列为已签核；NOT ASSESSED 答复应如实记录，且绝不能视为签核。

委派给 producer，并传递迄今收集到的所有签核：

• 收集以下人员的签核：qa-lead、release-manager、devops-engineer、security-engineer（若在阶段 3 中生成）、network-programmer（若在阶段 3 中生成）以及 technical-director（若在上文中生成）
• 如果有阶段检查覆盖，将其作为 Stage override: 行写入 Go/No-Go 记录
• 评估所有未解决的问题：它们是否会阻止发布，还是可以随版本发布？
• 做出 Go/No-Go 决定
• 输出：发布决定及其理由

如果 producer 宣布 NO-GO：

• 立即传达决定：“PRODUCER: NO-GO — [理由，例如：在阶段 3 发现 S1 级错误]。”
• 使用 AskUserQuestion，并提供以下选项：
  • 修复阻塞问题并重新运行受影响的阶段
  • 将发布推迟到之后的日期
  • 以书面理由覆盖 NO-GO（用户必须提供书面说明）
• 完全跳过阶段 6——不要打标签、部署到预发布环境、部署到生产环境，也不要生成 community-manager。
• 生成一份部分报告，总结阶段 1–5、被跳过的内容（阶段 6）及原因。
• 结论：BLOCKED——未部署该版本。

用户选择“以书面理由覆盖 NO-GO”后：

• 通过纯文本（而非控件）询问：“请说明覆盖 NO-GO 结论的理由。该内容将写入发布记录。”
• 等待用户提供书面理由。
• 在进入阶段 6 前，将理由写入部分审批记录，并追加字段：“⚠️ Override Justification: [用户提供的文本]”。
• 只有完成上述步骤后，才能继续阶段 6。

阶段 6：部署（若为 GO）

无论 modes.automation 如何设置，本阶段始终需要用户明确批准——包括 autonomous 模式。 生产环境部署不可撤销且风险极高；它不属于可配置的 automation_always_ask 类别，因此此技能会始终对此进行保护。 打标签或部署前，使用 AskUserQuestion：

• 提示：“Producer 的结论为 GO。执行阶段 6——打标签、部署到预发布环境、部署到生产环境？”
• 选项：[A] 是，部署 / [B] 仅部署到预发布环境——暂缓生产部署 / [C] 到此为止

只有获得明确批准后，才委派给 release-manager 和 devops-engineer：

• 在版本控制中为该版本打标签
• 完成以波兰语起草的更新日志（/changelog），并补充自阶段门以来的变更
• 部署到预发布环境，进行最终冒烟测试
• 部署到生产环境（仅当用户已批准生产部署时）
• 人工团队行动：发布后 48 小时内监控仪表板和错误率。在 48 小时节点使用 /retrospective 安排后续回顾。

部署同时，委派给 release-manager：

• 使用 /patch-notes [version] 完成以波兰语起草的补丁说明——release-manager 具备该技能以及其 git log 步骤所需的 Bash 访问权限；community-manager 两者都不具备

然后将补丁说明交给 community-manager：

• 准备发布公告（商店页面更新、社交媒体、社区帖子）
• 如果有任何 S3 级或更高级别的问题随版本发布，则起草已知问题公告
• 输出：所有面向玩家的发布沟通内容，在确认部署后即可发布

阶段 7：发布后

• release-manager：生成发布报告（已发布内容、延期内容、指标）
• producer：更新里程碑跟踪情况，并与利益相关方沟通
• qa-lead：监控新收到的缺陷报告，检查是否存在回归问题
• community-manager：发布所有面向玩家的沟通内容，并监控社区情绪
• analytics-engineer：确认线上仪表盘运行正常；如果缺少任何关键事件，则发出警报
• 保持阶段 6 的 48 小时监控窗口：发布后 48 小时内持续关注缺陷、仪表盘和社区情绪（release-manager 自行监控至其 72 小时报告）
• 如果发生问题，则安排发布后复盘

错误恢复协议

首先，验证产物。 如果返回约定中指定了路径，请先检查该路径是否存在，再将阶段视为完成——指定的产物若不在磁盘上，即表示阶段失败，无论回复读起来多么流畅。 Agent 可能耗费整个阶段，只返回一段看似合理的开场白，却什么也没写；这既不是 BLOCKED，也不是错误或“无法完成”，因此下面的触发条件永远不会触发。恢复执行时，请指出尚未满足的约定；上下文通常还在。

如果任何已启动的 Agent 返回 BLOCKED、出错或无法完成：立即说明情况，不要越过其阻塞的依赖，并且始终生成部分报告。 完整流程见：.claude/docs/error-recovery-protocol.md。

常见阻塞情况：

• 缺少输入文件（未找到故事、缺少 GDD）→ 转至创建该文件的技能
• ADR 状态为 Proposed → 不要实施；决定后通过 /architecture-decision accept ADR-NNNN 接受
• 范围过大 → 通过 /create-stories 拆分成两个故事
• ADR 与故事中的说明相互冲突 → 指出冲突，不要猜测

文件写入协议

所有文件写入（发布清单、变更日志、补丁说明、部署脚本）都委托给子 Agent 和子技能。二者遵循不同规则，这种区别在此处比流程中的其他任何环节都更重要：

• 通过 Agent 启动的子 Agent遵循上文“为什么这不违反协作协议”中说明的有限例外——路径由你指定，产物是在 production/、docs/ 或 tests/ 下新建的，并且阶段由 AskUserQuestion 控制。子 Agent 在这些范围内写入时无需逐次询问；超出范围则必须先询问。
• 子技能不是子 Agent，此例外不适用于它们。它们遵循常规协作协议，并在写入前询问。

此编排器不会直接写入文件。这里的任何内容都不授权执行对外操作或不可逆操作——无论适用上述哪条规则，标签、推送、构建和商店页面变更都需要明确确认。

输出

一份摘要报告，涵盖：发布版本、范围、质量关卡结果、是否继续的决定、部署状态和监控计划。

结论：COMPLETE——发布已执行并部署。 结论：BLOCKED——发布已停止；阶段检查将其拦截，是否继续的决定为 NO，或仍有未解决的硬性阻塞。

后续步骤

• 监控发布后仪表盘 48 小时。
• 如果发布期间发生重大问题，则运行 /retrospective。
• project.stage 会读取 Release，除非阶段检查已被覆盖：/gate-check release 是 Polish → Release 就绪关卡，应在运行此技能前执行。覆盖后，阶段仍会读取原来的值。只有 /gate-check 会更改 project.stage（状态为 PASS，或状态为 CONCERNS 且用户接受了相关风险时），因此此技能绝不会写入 project.stage 或 production/stage.txt。Release 是 project.stage 枚举中的终止阶段——没有发布后阶段值。线上／发布后状态应记录在发布报告中，而不是 project.stage 中。