Back to Details

day-one-patch

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Day-One Patch

首日补丁（Day-One Patch）

Every shipped game has a day-one patch. Planning it before launch day prevents chaos. This skill scopes the patch to only what is safe and necessary, gates it through a lightweight QA pass, and ensures a rollback plan exists before anything ships. It is a mini-sprint — not a hotfix, not a full sprint.
When to run:
  • After the gold master build is locked (cert approved or launch candidate tagged)
  • When known bugs exist that are too risky to address in the gold master
  • When cert feedback requires minor fixes post-submission
  • When a pre-launch playtest surfaces must-fix issues after the release gate passed
Day-one patch scope rules:
  • Only P1/P2 bugs that are SAFE to fix quickly
  • No new features — this is fix-only
  • No refactoring — minimum viable change
  • Any fix that requires more than 4 hours of dev time belongs in patch 1.1, not day-one
Output: 
production/releases/day-one-patch-[version].md
每款已发布的游戏都有首日补丁。在发布日前做好规划可以避免混乱。本技能将补丁范围限定为仅安全且必要的内容，通过轻量化的QA验证关卡，并确保在发布任何内容前都有回滚计划。这是一个迷你迭代——不是紧急修复，也不是完整迭代。
执行时机：
  • 黄金版本（gold master）构建锁定后（已通过认证或标记为发布候选版本）
  • 存在已知Bug，且在黄金版本中修复风险过高时
  • 认证反馈要求提交后进行小幅修复时
  • 发布关卡通过后，预发布测试发现必须修复的问题时
首日补丁范围规则：
  • 仅包含可快速安全修复的P1/P2级Bug
  • 不添加新功能——仅修复问题
  • 不进行重构——仅做最小可行修改
  • 任何需要超过4小时开发时间的修复都应放入1.1补丁，而非首日补丁
输出： 
production/releases/day-one-patch-[version].md

Phase 1: Load Release Context

阶段1：加载发布上下文

Read:
  • production/stage.txt
    — confirm project is in Release stage
  • The most recent file in 
    production/gate-checks/
    — read the release gate verdict
  • production/qa/bugs/*.md
    — load all bugs with Status: Open or Fixed — Pending Verification
  • production/sprints/
    most recent — understand what shipped
  • production/security/security-audit-*.md
    most recent — check for any open security items
If 
production/stage.txt
is not 
Release
or 
Polish
:
"Day-one patch prep is for Release-stage projects. Current stage: [stage]. This skill is not appropriate until you are approaching launch."
读取：
  • production/stage.txt
    —— 确认项目处于Release阶段
  • production/gate-checks/
    中最新的文件 —— 读取发布关卡的评审结果
  • production/qa/bugs/*.md
    —— 加载所有状态为“Open”或“Fixed — Pending Verification”的Bug
  • production/sprints/
    中最新的内容 —— 了解已发布的内容
  • production/security/security-audit-*.md
    中最新的文件 —— 检查是否有未处理的安全事项
如果
production/stage.txt
不是
Release
或
Polish
：
“首日补丁准备适用于Release阶段的项目。当前阶段：[stage]。在临近发布前，本技能才适用。”

Phase 2: Scope the Patch

阶段2：确定补丁范围

Step 2a — Classify open bugs for patch inclusion

步骤2a —— 分类可纳入补丁的未解决Bug

For each open bug, evaluate:
CriterionInclude in day-one?
S1 or S2 severityYes — must include if safe to fix
P1 priorityYes
Fix estimated < 4 hoursYes
Fix requires architecture changeNo — defer to 1.1
Fix introduces new code pathsNo — too risky
Fix is data/config only (no code change)Yes — very low risk
Cert feedback requirementYes — required for platform approval
S3/S4 severityOnly if trivial config fix; otherwise defer
针对每个未解决的Bug，评估：
评估标准是否纳入首日补丁？
S1或S2严重程度是——如果安全可修复则必须纳入
P1优先级是
修复预估时间<4小时是
修复需要架构变更否——推迟至1.1补丁
修复会引入新代码路径否——风险过高
修复仅涉及数据/配置（无代码变更）是——风险极低
认证反馈要求是——平台批准所需
S3/S4严重程度仅当是简单配置修复时纳入；否则推迟

Step 2b — Present patch scope to user

步骤2b —— 向用户展示补丁范围

Use 
AskUserQuestion
:
  • Prompt: "Based on open bugs and cert feedback, here is the proposed day-one patch scope. Does this look right?"
  • Show: table of included bugs (ID, severity, description, estimated effort)
  • Show: table of deferred bugs (ID, severity, reason deferred)
  • Options: 
    [A] Approve this scope
    / 
    [B] Adjust — I want to add or remove items
    / 
    [C] No day-one patch needed
If [C]: output "No day-one patch required. Proceed to 
/launch-checklist
." Stop.
使用
AskUserQuestion
：
  • 提示：“基于未解决的Bug和认证反馈，以下是提议的首日补丁范围。是否合理？”
  • 展示：纳入的Bug表格（ID、严重程度、描述、预估工作量）
  • 展示：推迟的Bug表格（ID、严重程度、推迟原因）
  • 选项：
    [A] 批准此范围
    / 
    [B] 调整——我想添加或移除项目
    / 
    [C] 无需首日补丁
如果选择[C]：输出“无需首日补丁。继续执行
/launch-checklist
。”停止流程。

Step 2c — Check total scope

步骤2c —— 检查总范围

Sum estimated effort. If total exceeds 1 day of work:
"⚠️ Patch scope is [N hours] — this exceeds a safe day-one window. Consider deferring lower-priority items to patch 1.1. A bloated day-one patch introduces more risk than it removes."
Use 
AskUserQuestion
to confirm proceeding or reduce scope.
汇总预估工作量。如果总时长超过1天：
“⚠️ 补丁范围为[N小时]——超出了安全的首日补丁窗口。考虑将低优先级项目推迟至1.1补丁。臃肿的首日补丁带来的风险大于其解决的问题。”
使用
AskUserQuestion
确认是否继续或缩小范围。

Phase 3: Rollback Plan

阶段3：回滚计划

Before any code is written, define the rollback procedure. This is non-negotiable.
Spawn 
release-manager
via Task. Ask them to produce a rollback plan covering:
  • How to revert to the gold master build on each target platform
  • Platform-specific rollback constraints (some platforms cannot roll back cert builds)
  • Who is responsible for triggering the rollback
  • What player communication is required if a rollback occurs
Present the rollback plan. Ask: "May I write this rollback plan to 
production/releases/rollback-plan-[version].md
?"
Do not proceed to Phase 4 until the rollback plan is written.
在编写任何代码之前，定义回滚流程。这是必不可少的步骤。
通过Task调用
release-manager
，要求其生成一份回滚计划，涵盖：
  • 如何在每个目标平台上回退到gold master构建版本
  • 平台特定的回滚限制（部分平台无法回退已认证的构建版本）
  • 负责触发回滚的人员
  • 回滚发生时所需的玩家沟通内容
展示回滚计划。询问：“我可以将此回滚计划写入
production/releases/rollback-plan-[version].md
吗？”
在回滚计划写入完成前，不得进入阶段4。

Phase 4: Implement Fixes

阶段4：实施修复

For each bug in the approved scope, spawn a focused implementation loop:
  1. Spawn 
    lead-programmer
    via Task with:
    • The bug report (exact reproduction steps and root cause if known)
    • The constraint: minimum viable fix only, no cleanup
    • The affected files (from bug report Technical Context section)
  2. The lead-programmer implements and runs targeted tests.
  3. Spawn 
    qa-tester
    via Task to verify: does the bug reproduce after the fix?
For config/data-only fixes: make the change directly (no programmer agent needed). Confirm the value changed and re-run any relevant smoke test.
针对批准范围内的每个Bug，启动聚焦的实施循环：
  1. 通过Task调用
    lead-programmer
    ，提供：
    • Bug报告（已知的精确复现步骤和根本原因）
    • 约束条件：仅做最小可行修复，不进行清理
    • 受影响的文件（来自Bug报告的技术上下文部分）
  2. lead-programmer实施修复并运行针对性测试。
  3. 通过Task调用
    qa-tester
    进行验证：修复后Bug是否还会复现？
对于仅涉及配置/数据的修复：直接修改（无需程序员agent）。确认值已更改并重新运行相关的冒烟测试。

Phase 5: Patch QA Gate

阶段5：补丁QA关卡

This is a lightweight QA pass — not a full 
/team-qa
. The patch is already QA-approved from the release gate; we are only re-verifying the changed areas.
Spawn 
qa-lead
via Task with:
  • List of all changed files
  • List of bugs fixed (with verification status from Phase 4)
  • The smoke check scope for the affected systems
Ask qa-lead to determine: Is a targeted smoke check sufficient, or do any fixes touch systems that require a broader regression?
Run the required QA scope:
  • Targeted smoke check — run 
    /smoke-check [affected-systems]
  • Broader regression — run targeted tests in 
    tests/unit/
    and 
    tests/integration/
    for affected systems
QA verdict must be PASS or PASS WITH WARNINGS before proceeding. If FAIL: scope the failing fix out of the day-one patch and defer to 1.1.
这是轻量化的QA验证——不是完整的
/team-qa
。补丁已通过发布关卡的QA批准；我们仅重新验证变更的区域。
通过Task调用
qa-lead
，提供：
  • 所有变更文件的列表
  • 已修复的Bug列表（含阶段4的验证状态）
  • 受影响系统的冒烟测试范围
询问qa-lead：针对性冒烟测试是否足够，或者是否有修复涉及需要更广泛回归测试的系统？
执行所需的QA范围：
  • 针对性冒烟测试 —— 运行
    /smoke-check [affected-systems]
  • 更广泛回归测试 —— 针对受影响系统运行
    tests/unit/
    和
    tests/integration/
    中的针对性测试
QA结果必须为PASS或PASS WITH WARNINGS才能继续。如果FAIL：将失败的修复从首日补丁范围中移除，推迟至1.1补丁。

Phase 6: Generate Patch Record

阶段6：生成补丁记录

markdown
undefined
markdown
undefined

Day-One Patch: [Game Name] v[version]

Day-One Patch: [Game Name] v[version]

Date prepared: [date] Target release: [launch date or "day of launch"] Base build: [gold master tag or commit] Patch build: [patch tag or commit]
准备日期: [date] 目标发布时间: [launch date or "day of launch"] 基础构建版本: [gold master tag or commit] 补丁构建版本: [patch tag or commit]

Patch Notes (Internal)

内部补丁说明

Bugs Fixed

已修复Bug

BUG-IDSeverityDescriptionFix summary
BUG-NNNS[1-4][description][one-line fix]
BUG-ID严重程度描述修复摘要
BUG-NNNS[1-4][description][one-line fix]

Deferred to 1.1

推迟至1.1补丁的内容

BUG-IDSeverityDescriptionReason deferred
BUG-NNNS[1-4][description][reason]
BUG-ID严重程度描述推迟原因
BUG-NNNS[1-4][description][reason]

QA Sign-Off

QA签署确认

QA scope: [Targeted smoke / Broader regression] Verdict: [PASS / PASS WITH WARNINGS] QA lead: qa-lead agent Date: [date] Warnings (if any): [list or "None"]
QA范围: [Targeted smoke / Broader regression] 结果: [PASS / PASS WITH WARNINGS] QA负责人: qa-lead agent 日期: [date] 警告（如有）: [list or "None"]

Rollback Plan

回滚计划

See: 
production/releases/rollback-plan-[version].md
Trigger condition: If [N] or more S1 bugs are reported within [X] hours of launch, execute rollback. Rollback owner: [user / producer]
详见: 
production/releases/rollback-plan-[version].md
触发条件: 如果发布后[X]小时内报告了[N]个或更多S1级Bug，执行回滚。 回滚负责人: [user / producer]

Approvals Required Before Deploy

部署前所需批准

  • lead-programmer: all fixes reviewed
  • qa-lead: QA gate PASS confirmed
  • producer: deployment timing approved
  • release-manager: platform submission confirmed
  • lead-programmer: 所有修复已审核
  • qa-lead: 确认QA关卡已通过
  • producer: 部署时间已批准
  • release-manager: 平台提交已确认

Player-Facing Patch Notes

面向玩家的补丁说明

[Draft for community-manager to review before publishing]
[list player-facing changes in plain language]

Ask: "May I write this patch record to `production/releases/day-one-patch-[version].md`?"

---
[供community-manager审核后发布的草稿]
[用通俗易懂的语言列出面向玩家的变更内容]

询问：“我可以将此补丁记录写入`production/releases/day-one-patch-[version].md`吗？”

---

Phase 7: Next Steps

阶段7：后续步骤

After the patch record is written:
  1. Run 
    /patch-notes
    to generate the player-facing version of the patch notes
  2. Run 
    /bug-report verify [BUG-ID]
    for each fixed bug after the patch is live
  3. Run 
    /bug-report close [BUG-ID]
    for each verified fix
  4. Schedule a post-launch review 48–72 hours after launch using 
    /retrospective launch
If any S1 bugs remain open after the patch:
"⚠️ S1 bugs remain open and were not patched. These are accepted risks. Document them in the rollback plan trigger conditions — if they occur at scale, rollback may be preferable to a follow-up patch."
Use 
AskUserQuestion
:
  • Prompt: "Day-one patch complete. What's next?"
  • Options: 
    • [A] Run /patch-notes — generate player-facing patch notes
    • [B] Run /bug-report to log any issues found post-deploy
    • [C] Stop here
补丁记录写入完成后：
  1. 运行
    /patch-notes
    生成面向玩家的补丁说明版本
  2. 补丁上线后，针对每个已修复的Bug运行
    /bug-report verify [BUG-ID]
  3. 针对每个已验证的修复运行
    /bug-report close [BUG-ID]
  4. 使用
    /retrospective launch
    安排发布后48–72小时的复盘会议
如果补丁发布后仍有S1级Bug未解决：
“⚠️ 仍有未解决的S1级Bug且未纳入补丁。这些是已接受的风险。将其记录在回滚计划的触发条件中——如果大规模出现，回滚可能比后续补丁更合适。”
使用
AskUserQuestion
：
  • 提示：“首日补丁已完成。下一步是什么？”
  • 选项： 
    • [A] 运行/patch-notes —— 生成面向玩家的补丁说明
    • [B] 运行/bug-report记录部署后发现的问题
    • [C] 到此为止

Collaborative Protocol

协作协议

  • Scope discipline is everything — resist scope creep; every addition increases risk
  • Rollback plan first, always — a patch without a rollback plan is irresponsible
  • Deferred is not forgotten — every deferred bug gets a 1.1 ticket automatically
  • Player communication is part of the patch — 
    /patch-notes
    is a required output, not optional
  • 范围管控至关重要 —— 抵制范围蔓延；每一项新增内容都会增加风险
  • 始终优先制定回滚计划 —— 没有回滚计划的补丁是不负责任的
  • 推迟不等于遗忘 —— 每个推迟的Bug都会自动生成1.1补丁的工单
  • 玩家沟通是补丁的一部分 —— 
    /patch-notes
    是必填输出项，而非可选内容