team-release

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Argument check: If no version number is provided:

Read
```
production/session-state/active.md
```
and the most recent file in
```
production/milestones/
```
(if they exist) to infer the target version.
If a version is found: report "No version argument provided — inferred [version] from milestone data. Proceeding." Then confirm with
```
AskUserQuestion
```
: "Releasing [version]. Is this correct?"
If no version is discoverable: use
```
AskUserQuestion
```
to ask "What version number should be released? (e.g., v1.0.0)" and wait for user input before proceeding. Do NOT default to a hardcoded version string.

When this skill is invoked, orchestrate the release team through a structured pipeline.

Decision Points: At each phase transition, use

AskUserQuestion

to present the user with the subagent's proposals as selectable options. Write the agent's full analysis in conversation, then capture the decision with concise labels. The user must approve before moving to the next phase.

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

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

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

决策节点：在每个阶段过渡时，使用

AskUserQuestion

将子Agent的方案以可选选项形式呈现给用户。在对话中写入Agent的完整分析内容，然后用简洁标签记录决策结果。必须获得用户批准后才能进入下一阶段。

Phase 0: Resolve Review Mode

阶段0：确定评审模式

If
```
--review [mode]
```
was passed as an argument, use that mode.
Else read
```
production/review-mode.txt
```
— use whatever is written there.
Else default to
```
lean
```
.

Modes:

```
full
```
— spawn all director and lead gates as described
```
lean
```
— skip director gates unless they are PHASE-GATE type (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE)
```
solo
```
— skip all director gate spawning entirely; run the skill without any agent gates

Store the resolved mode for use in all subsequent phases.

如果传入了
```
--review [mode]
```
参数，则使用该模式。
否则读取
```
production/review-mode.txt
```
文件——使用文件中记录的模式。
若以上均无，则默认使用
```
lean
```
模式。

模式说明：

```
full
```
—— 按描述启用所有主管和负责人关卡
```
lean
```
—— 跳过主管关卡，除非是PHASE-GATE类型（CD-PHASE-GATE、TD-PHASE-GATE、PR-PHASE-GATE、AD-PHASE-GATE）
```
solo
```
—— 完全跳过所有主管关卡的启用；无需任何Agent关卡即可运行该技能

保存确定后的模式，供后续所有阶段使用。

Team Composition

团队组成

release-manager — Release branch, versioning, changelog, deployment
qa-lead — Test sign-off, regression suite, release quality gate
devops-engineer — Build pipeline, artifacts, deployment automation
security-engineer — Pre-release security audit (invoke if game has online/multiplayer features or player data)
analytics-engineer — Verify telemetry events fire correctly and dashboards are live
community-manager — Patch notes, launch announcement, player-facing messaging
producer — Go/no-go decision, stakeholder communication, scheduling

release-manager —— 发布分支管理、版本控制、变更日志、部署执行
qa-lead —— 测试签字确认、回归测试套件、发布质量关卡
devops-engineer —— 构建流水线、制品管理、部署自动化
security-engineer —— 发布前安全审计（若游戏包含在线/多人功能或玩家数据则调用）
analytics-engineer —— 验证遥测事件触发正常，且仪表盘处于可用状态
community-manager —— 更新补丁说明、发布公告、面向玩家的信息推送
producer —— 发布决策（Go/No-Go）、干系人沟通、进度排期

How to Delegate

任务分配方式

Use the Task tool to spawn each team member as a subagent:

```
subagent_type: release-manager
```
— Release branch, versioning, changelog, deployment
```
subagent_type: qa-lead
```
— Test sign-off, regression suite, release quality gate
```
subagent_type: devops-engineer
```
— Build pipeline, artifacts, deployment automation
```
subagent_type: security-engineer
```
— Security audit for online/multiplayer/data features
```
subagent_type: analytics-engineer
```
— Telemetry event verification and dashboard readiness
```
subagent_type: community-manager
```
— Patch notes and launch communication
```
subagent_type: producer
```
— Go/no-go decision, stakeholder communication
```
subagent_type: network-programmer
```
— Netcode stability sign-off (invoke if game has multiplayer)

Always provide full context in each agent's prompt (version number, milestone status, known issues). Launch independent agents in parallel where the pipeline allows it (e.g., Phase 3 agents can run simultaneously).

使用Task工具将每个团队成员生成为子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
```
—— 发布决策（Go/No-Go）、干系人沟通
```
subagent_type: network-programmer
```
—— 网络代码稳定性签字确认（若游戏包含多人功能则调用）

需在每个Agent的提示中提供完整上下文（版本号、里程碑状态、已知问题）。在流水线允许的情况下，并行启动独立Agent（例如阶段3的Agent可同时运行）。

Pipeline

发布流水线

Phase 1: Release Planning

阶段1：发布规划

Delegate to producer:

Confirm all milestone acceptance criteria are met
Identify any scope items deferred from this release
Set the target release date and communicate to team
Output: release authorization with scope confirmation

委托给producer：

确认所有里程碑验收标准已达成
识别本次发布中需推迟的范围项
设置目标发布日期并同步给团队
输出：包含范围确认的发布授权书

Phase 2: Release Candidate

阶段2：发布候选版本

Delegate to release-manager:

Cut release branch from the agreed commit
Bump version numbers in all relevant files
Generate the release checklist using
```
/release-checklist
```
Freeze the branch — no feature changes, bug fixes only
Output: release branch name and checklist

委托给release-manager：

从约定的提交记录中创建发布分支
更新所有相关文件中的版本号
使用
```
/release-checklist
```
生成发布检查清单
冻结分支——禁止新增功能，仅允许修复Bug
输出：发布分支名称与检查清单

Phase 3: Quality Gate (parallel)

阶段3：质量关卡（并行执行）

Delegate in parallel:

qa-lead: Execute full regression test suite. Test all critical paths. Verify no S1/S2 bugs. Sign off on quality.
devops-engineer: Build release artifacts for all target platforms. Verify builds are clean and reproducible. Run automated tests in CI.
security-engineer (if game has online features, multiplayer, or player data): Conduct pre-release security audit. Review authentication, anti-cheat, data privacy compliance. Sign off on security posture.
network-programmer (if game has multiplayer): Sign off on netcode stability. Verify lag compensation, reconnect handling, and bandwidth usage under load.

并行委托：

qa-lead：执行完整回归测试套件。测试所有关键路径。确认无S1/S2级Bug。签字确认质量达标。
devops-engineer：为所有目标平台构建发布制品。确认构建过程干净可复现。在CI中运行自动化测试。
security-engineer（若游戏包含在线功能、多人功能或玩家数据）：开展发布前安全审计。审查认证、反作弊、数据隐私合规性。签字确认安全状态达标。
network-programmer（若游戏包含多人功能）：签字确认网络代码稳定性。验证延迟补偿、重连处理及高负载下的带宽使用情况。

Phase 4: Localization, Performance, and Analytics

阶段4：本地化、性能与数据分析

Delegate (can run in parallel with Phase 3 if resources available):

Verify all strings are translated (delegate to localization-lead if available)
Run performance benchmarks against targets (delegate to performance-analyst if available)
analytics-engineer: Verify all telemetry events fire correctly on release build. Confirm dashboards are receiving data. Check that critical funnels (onboarding, progression, monetization if applicable) are instrumented.
Output: localization, performance, and analytics sign-off

委托执行（若资源允许，可与阶段3并行）：

验证所有字符串已完成翻译（若有localization-lead则委托给该角色）
针对目标指标运行性能基准测试（若有performance-analyst则委托给该角色）
analytics-engineer：验证发布版本中所有遥测事件触发正常。确认仪表盘正在接收数据。检查关键漏斗（新手引导、进度推进、若涉及 monetization则包含付费转化）已完成埋点。
输出：本地化、性能与数据分析的签字确认

Phase 5: Go/No-Go

阶段5：发布决策（Go/No-Go）

Delegate to producer:

Collect sign-off from: qa-lead, release-manager, devops-engineer, security-engineer (if spawned in Phase 3), network-programmer (if spawned in Phase 3), and technical-director
Evaluate any open issues — are they blocking or can they ship?
Make the go/no-go call
Output: release decision with rationale

If producer declares NO-GO:

Surface the decision immediately: "PRODUCER: NO-GO — [rationale, e.g., S1 bug found in Phase 3]."
Use
```
AskUserQuestion
```
with options:
- Fix the blocker and re-run the affected phase
- Defer the release to a later date
- Override NO-GO with documented rationale (user must provide written justification)
Skip Phase 6 entirely — do not tag, deploy to staging, deploy to production, or spawn community-manager.
Produce a partial report summarizing Phases 1–5 and what was skipped (Phase 6) and why.
Verdict: BLOCKED — release not deployed.

After the user selects "Override NO-GO with documented rationale":

Ask (plain text, not widget): "Please describe the justification for overriding the NO-GO verdict. This will be embedded in the release record."
Wait for the user's written justification.
Embed the justification text in the partial approval record before Phase 6: append a "⚠️ Override Justification: [user's text]" field.
Only then proceed to Phase 6.

委托给producer：

收集以下角色的签字确认：qa-lead、release-manager、devops-engineer、security-engineer（若阶段3已启用）、network-programmer（若阶段3已启用）以及technical-director
评估所有未解决问题——是否为阻塞性问题，还是可随版本发布？
做出Go/No-Go决策
输出：包含决策理由的发布结果

若producer判定为NO-GO：

立即告知用户：“PRODUCER: NO-GO — [理由，例如：阶段3发现S1级Bug]。”
使用
```
AskUserQuestion
```
提供选项：
- 修复阻塞问题并重新运行受影响的阶段
- 将发布推迟至更晚日期
- 提供书面理由后覆盖NO-GO决策（用户必须提交书面说明）
完全跳过阶段6——不得进行版本打标签、预发布环境部署、生产环境部署，也不得启用community-manager。
生成部分报告，总结阶段1-5的工作内容，以及跳过阶段6的原因。
结论：BLOCKED——发布未部署。

当用户选择“提供书面理由后覆盖NO-GO决策”：

以纯文本形式询问（不使用组件）：“请描述覆盖NO-GO决策的理由。该内容将嵌入发布记录中。”
等待用户提交书面理由。
在进入阶段6前，将理由文本添加到部分批准记录中：追加“⚠️ 覆盖理由：[用户提交的文本]”字段。
完成上述步骤后，方可进入阶段6。

Phase 6: Deployment (if GO)

阶段6：部署（若决策为Go）

Delegate to release-manager + devops-engineer:

Tag the release in version control
Generate changelog using
```
/changelog
```
Deploy to staging for final smoke test
Deploy to production
Human team action: Monitor dashboards and error rates for 48 hours post-release. Schedule a follow-up retrospective using
```
/retrospective
```
at the 48-hour mark.

Delegate to community-manager (in parallel with deployment):

Finalize patch notes using
```
/patch-notes [version]
```
Prepare launch announcement (store page updates, social media, community post)
Draft known issues post if any S3+ issues shipped
Output: all player-facing release communication, ready to publish on deploy confirmation

委托给release-manager + devops-engineer：

在版本控制系统中为发布打标签
使用
```
/changelog
```
生成变更日志
部署到预发布环境进行最终冒烟测试
部署到生产环境
人工团队操作：发布后48小时内监控仪表盘与错误率。在48小时节点使用
```
/retrospective
```
安排复盘会议。

并行委托给community-manager（与部署同步进行）：

使用
```
/patch-notes [version]
```
完成补丁说明最终版
准备发布公告（商店页面更新、社交媒体、社区帖子）
若有S3及以上级别问题随版本发布，撰写已知问题公告
输出：所有面向玩家的发布沟通内容，待部署确认后即可发布

Phase 7: Post-Release

阶段7：发布后工作

release-manager: Generate release report (what shipped, what was deferred, metrics)
producer: Update milestone tracking, communicate to stakeholders
qa-lead: Monitor incoming bug reports for regressions
community-manager: Publish all player-facing communication, monitor community sentiment
analytics-engineer: Confirm live dashboards are healthy; alert if any critical events are missing
Schedule post-release retrospective if issues occurred

release-manager：生成发布报告（已发布内容、推迟内容、相关指标）
producer：更新里程碑跟踪记录，与干系人沟通
qa-lead：监控新提交的Bug报告，排查是否存在回归问题
community-manager：发布所有面向玩家的沟通内容，监控社区舆情
analytics-engineer：确认在线仪表盘运行正常；若关键事件缺失则发出警报
若发布过程中出现重大问题，安排发布后复盘会议

Error Recovery Protocol

错误恢复机制

If any spawned agent (via Task) returns BLOCKED, errors, or cannot complete:

Surface immediately: Report "[AgentName]: BLOCKED — [reason]" to the user before continuing to dependent phases
Assess dependencies: Check whether the blocked agent's output is required by subsequent phases. If yes, do not proceed past that dependency point without user input.
Offer options via AskUserQuestion with choices:
- Skip this agent and note the gap in the final report
- Retry with narrower scope
- Stop here and resolve the blocker first
Always produce a partial report — output whatever was completed. Never discard work because one agent blocked.

Common blockers:

Input file missing (story not found, GDD absent) → redirect to the skill that creates it
ADR status is Proposed → do not implement; run
```
/architecture-decision
```
first
Scope too large → split into two stories via
```
/create-stories
```
Conflicting instructions between ADR and story → surface the conflict, do not guess

若任何通过Task生成的Agent返回BLOCKED、出错或无法完成任务：

立即告知用户：在进入依赖该Agent的后续阶段前，向用户报告“[AgentName]: BLOCKED — [原因]”
评估依赖关系：检查被阻塞的Agent的输出是否为后续阶段所需。若是，在获得用户输入前不得越过该依赖节点。
通过AskUserQuestion提供选项：
- 跳过该Agent，并在最终报告中记录此缺口
- 缩小范围后重试
- 在此处暂停，先解决阻塞问题
始终生成部分报告——输出已完成的所有工作内容。不得因单个Agent阻塞而丢弃已完成的工作。

常见阻塞场景：

输入文件缺失（未找到需求文档、GDD不存在）→ 引导至创建该文件的技能
ADR状态为Proposed → 不得执行；先运行
```
/architecture-decision
```
范围过大 → 通过
```
/create-stories
```
拆分为两个需求
ADR与需求文档存在冲突指令 → 告知用户冲突情况，不得自行猜测

File Write Protocol

文件写入规范

All file writes (release checklists, changelogs, patch notes, deployment scripts) are delegated to sub-agents and sub-skills. Each enforces the "May I write to [path]?" protocol. This orchestrator does not write files directly.

所有文件写入操作（发布检查清单、变更日志、补丁说明、部署脚本）均委托给子Agent和子技能。每个操作需遵循“是否允许写入[路径]？”的规范。本编排器不直接执行文件写入操作。

Output

输出内容

A summary report covering: release version, scope, quality gate results, go/no-go decision, deployment status, and monitoring plan.

Verdict: COMPLETE — release executed and deployed. Verdict: BLOCKED — release halted; go/no-go was NO or a hard blocker is unresolved.

一份总结报告，包含：发布版本、范围、质量关卡结果、Go/No-Go决策、部署状态以及监控计划。

结论：COMPLETE——发布已执行并部署。结论：BLOCKED——发布已暂停；Go/No-Go决策为No，或存在未解决的硬阻塞问题。

Next Steps

后续步骤

Monitor post-release dashboards for 48 hours.
Run
```
/retrospective
```
if significant issues occurred during the release.
Update
```
production/stage.txt
```
to
```
Live
```
after successful deployment.

发布后48小时内监控仪表盘。
若发布过程中出现重大问题，运行
```
/retrospective
```
。
部署成功后，将
```
production/stage.txt
```
更新为
```
Live
```
。