Claude Code Game Studios 首发日补丁规划技能 /day-one-patch 深度解析：发布即知问题的优先级排期、耗时估算与 P0 升级机制-平芜编程栈

Claude Code Game Studios 首发日补丁规划技能 /day-one-patch 深度解析：发布即知问题的优先级排期、耗时估算与 P0 升级机制

【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios

/day-one-patch是 Claude Code Game Studios（CCGS）框架中负责首发日补丁（day-one patch）规划的发布流程实用技能。它以 v1.0 发布时已知但被有意推迟修复的问题为输入，读取production/bugs/下的未关闭缺陷报告与故事文件中标注为延后的验收标准（deferred AC），产出一份按严重度排序、带修复耗时估算的补丁计划，并写入production/releases/day-one-patch.md。读完本文，你将掌握该技能的完整行为规范：输入数据源与输出格式、"May I write" 协作协议、基于严重度的耗时估算规则、P0 关键缺陷的/hotfix升级路径、延后验收标准的自动纳入逻辑，以及如何借助本仓库的 Skill Testing Framework 对技能进行静态与行为级验证。

一、技能定位：发布链路中的"收尾计划员"

在 CCGS 的完整发布工作流中，/day-one-patch承担的是"把已知问题在发布后第一时间修完"的规划职责。它不属于任何设计、开发或评审阶段，而是一个发布规划类（release planning）实用技能。

从框架 README 的技能分类看，它归属于utility分类，与start、adopt、hotfix、release-checklist、smoke-check等并列；在 catalog.yaml 中，day-one-patch的登记条目为priority: low、category: utility，即中等以下优先级的通用工具型技能。

从发布链路的上下游关系看，它的位置非常清晰：

上游：launch-checklist 的静态断言中明确把/day-one-patch列为完成首发清单后的下一步交接项（next-step handoff）；
本体：读取production/bugs/中所有未关闭缺陷 + 故事文件中Status: Done但标注了延后验收标准的条目，生成补丁计划；
下游：计划执行完之后，面向玩家的 patch-notes 技能（生成玩家可见的补丁说明）是独立步骤，由计划执行后再调用，二者不耦合。

也就是说，首发日补丁计划的生成（本技能）→ 补丁的紧急修复（/hotfix）→ 补丁的执行与验证（/smoke-check）→ 玩家沟通文档（/patch-notes）构成了一条完整的 post-ship 修复流水线，/day-one-patch是这条流水线的"排期中枢"。

二、核心职责：输入、输出与不可违反的协议

技能行为规范用一段 Skill Summary 精确刻画了技能的三要素：

2.1 输入：两个数据源

production/bugs/目录下的未关闭缺陷报告：这些报告由 bug-report 技能生成，遵循production/bugs/bug-[date]-[slug].md命名约定，且必须包含 7 个必填字段：Title、Repro Steps、Expected Behavior、Actual Behavior、Severity（CRITICAL/HIGH/MEDIUM/LOW）、Affected System(s)、Build/Version。严重度枚举正是后续排序与估算的依据。
故事文件中的延后验收标准：即状态为Status: Done（由 story-done 标记）但在完成说明（Completion Notes）里记录了DEFERRED AC（延后验收标准）的故事。/story-done规范明确规定：无法自动验证的验收标准会被标记为 DEFERRED，并记录在完成说明中，最终产出COMPLETE WITH NOTES判定——这正是day-one-patch第二个输入源的生产机制。

2.2 输出：一份带估算的补丁计划

计划写入production/releases/day-one-patch.md，每条工作项必须包含：

优先级顺序（priority order）：按严重度从高到低排列；
预计时间线（estimated timeline）：每个问题的修复耗时估算；
负责系统（responsible system）：问题归属的游戏系统/模块；
修复描述（fix description）：问题与修复方向的说明。

2.3 三条铁律协议

协议	内容
协作写入协议	写入`production/releases/day-one-patch.md`之前必须询问 "May I write to`production/releases/day-one-patch.md`?"，得到用户确认后才能落盘
判定协议	所有路径下，技能判定恒为COMPLETE（空计划、P0 升级、正常排期均不例外）
门禁协议	不触发任何 director gate（CD-/TD-/AD-/PR-均不出现），技能执行期间不派生子代理

此外还有一条关键升级规则：如果发现P0（发布后仍可造成严重后果的 CRITICAL 缺陷），技能必须先触发引导，要求用户运行/hotfix处理，P0 问题不会进入补丁计划的时间线（详见第四节 Case 2）。

三、静态断言：7 项结构性合规检查

凡是utility分类的技能，都要通过 Skill Testing Framework 定义的 7 项静态检查（对应 quality-rubric.md 的U1 指标：/skill-test static [name]返回 COMPLIANT 且 0 FAIL）。/day-one-patch的静态断言明确要求：

具备必需的 frontmatter 字段：name、description、argument-hint、user-invocable、allowed-tools
包含 ≥2 个阶段标题（phase headings）
包含判定关键字：COMPLETE
在写计划之前包含 "May I write" 协作协议语言
包含下一步交接（如 P0 时指向/hotfix，后续跟进指向/release-checklist）

这些检查无需任何 fixture，可由/skill-test static全自动验证。而行为级验证则依赖下一节的 5 个测试用例。完整的 spec 模板结构可参考 templates/skill-test-spec.md，任何新技能都按该模板编写行为规范。

四、行为规范：5 个测试用例逐条拆解

行为规范是day-one-patch文档的主体，通过 5 个用例覆盖了技能的所有执行路径。它们共同定义了"技能在不同项目状态下必须表现出什么行为"，这是本技能可测试、可验证、可审计的基础。

4.1 Case 1：Happy Path —— 3 个已知问题，产出带估算的补丁计划

Fixture：production/bugs/下存在 3 个未关闭缺陷，严重度为 1 个 MEDIUM、2 个 LOW；冲刺故事中没有延后 AC；所有缺陷都有复现步骤和系统标识。

期望行为：

读取全部 3 个未关闭缺陷；
为每个缺陷分配修复耗时估算：MEDIUM 缺陷 = 1~2 天，LOW 缺陷 = 每个 4 小时；
生成补丁计划，MEDIUM 缺陷排在首位（严重度优先）；
计划包含：优先级顺序、预计时间线、负责系统、修复描述；
询问 "May I write toproduction/releases/day-one-patch.md?"；
文件写入，判定 COMPLETE。

断言要点：3 个缺陷全部出现在计划中；严重度排序正确（MEDIUM 在 LOW 之前）；每个问题都有修复估算；写入前必问 "May I write"；判定为 COMPLETE。

这里揭示了本技能的核心排期模型——严重度 → 优先级排序 + 耗时估算。估算规则目前是规格级硬编码：MEDIUM 按 1~2 天、LOW 按 4 小时计。Coverage Notes 中明确说明这是基于严重度的粗略估算（rough estimates），而非基于团队真实速率（velocity），因为技能无法感知团队历史吞吐；而补丁整体可用时间线（如"补丁 3 天后可用"）需要人工 QA 与构建时间估算来补充。

4.2 Case 2：P0 关键缺陷 —— 升级为 /hotfix 引导，P0 不入排期

Fixture：v1.0 发布后发现一个 CRITICAL 严重度缺陷，且会造成所有存档文件数据丢失。

期望行为：

读取缺陷并识别出 CRITICAL 严重度问题；
升级提示："P0 ISSUE DETECTED — data loss bug requires immediate hotfix before patch planning can proceed"（P0 问题已检测——数据丢失缺陷需要在补丁规划前立即热修复）；
不把 P0 问题纳入补丁计划的时间线（它需要立即处理，而非按天排期）；
明确指示："Run/hotfixto resolve this issue first"；
发出 P0 引导后，其余低严重度缺陷的补丁计划照常生成并写入，判定仍为 COMPLETE。

断言要点：P0 升级消息在补丁计划之前醒目出现；/hotfix被显式指定为 P0 处理手段；P0 不进入计划时间线；非 P0 问题仍然完成规划；判定 COMPLETE。

这一用例体现了 CCGS 对"计划"与"应急"的边界划分：/day-one-patch只负责可排期的已知问题，而数据丢失这类 P0 灾难必须走 hotfix 的紧急流程——从 main 拉出 hotfix 分支、定位修复、跑/smoke-check验证、用户确认后合回 main，判定为HOTFIX COMPLETE或HOTFIX BLOCKED。Coverage Notes 补充说明：多个 CRITICAL 缺陷同时存在时，与 Case 2 处理方式一致——所有 P0 一并升级。

4.3 Case 3：延后 AC 自动纳入 —— 来自 /story-done 的延后验收标准

Fixture：production/sprints/sprint-008.md中有一个故事状态为Status: Done，其完成说明包含："DEFERRED AC: Gamepad vibration on damage — deferred to post-launch patch"（手柄振动伤害反馈——延后到发布后补丁）；同一系统没有未关闭缺陷。

期望行为：

读取冲刺故事并检测到延后 AC 标注；
延后 AC自动作为工作项纳入补丁计划；
计划条目标注来源："Deferred from sprint-008: Gamepad vibration on damage"；
为该条目分配修复估算；"May I write" 批准后写入计划；
判定 COMPLETE。

断言要点：故事文件中的延后 AC 被自动拉取；延后条目按来源故事（sprint-008）标注；延后 AC 获得与缺陷条目相同的修复估算；判定 COMPLETE。

这条链路非常值得注意：/story-done在验收标准无法自动验证或用户确认延后时，会记录 DEFERRED 并产出COMPLETE WITH NOTES，而/day-one-patch会自动扫描这些延后项并将其转化为可排期的补丁工作项。这实现了"开发期延后 → 发布后自动回收"的闭环，无需人工重新转录问题清单。

4.4 Case 4：零已知问题 —— 空计划 + 模板保留

Fixture：production/bugs/为空；没有任何故事存在延后 AC。

期望行为：

读取缺陷——无；
读取故事延后 AC——无；
生成带备注 "No known issues at launch"（发布时无已知问题）的空补丁计划；
保留模板结构（标题等骨架完整），供未来复用；
询问 "May I write toproduction/releases/day-one-patch.md?"；
文件写入，判定 COMPLETE。

断言要点："No known issues at launch" 备注出现在写入文件中；空计划仍保留模板标题；没有问题时技能不报错；判定 COMPLETE。

这是典型的边界用例设计：空数据不是异常，而是合法的输出状态。模板骨架得以保留意味着后续发现新问题时，只需在原文件上追加条目，无需重建文档结构。

4.5 Case 5：Director Gate —— 规划类工具不触发任何门禁

Fixture：production/bugs/存在已知问题。

期望行为：

正常生成并写入补丁计划；
不派生任何 director 代理；
输出中不出现任何 gate ID。

断言要点：不调用 director gate；不出现 gate skip 消息；无门禁检查的情况下判定仍为 COMPLETE。

结合 quality-rubric.md 的U2 指标（"若技能会触发 director gate，则必须正确读取 review-mode 并应用 full/lean/solo 逻辑"）可以理解为：utility 类技能默认不走门禁，day-one-patch因属于规划工具而天然豁免。真正正式的阶段门禁由 gate-check 技能管理，与本技能职责分离。

五、协议合规清单：可审计的执行契约

行为规范的最后部分是 Protocol Compliance，它把上述用例中的通用协议抽成可逐项勾选的合规清单：

生成计划前先读取production/bugs/中的未关闭缺陷
扫描故事文件中的延后 AC 标注
对 CRITICAL（P0）缺陷升级并给出显式/hotfix引导
无问题时产出带备注的空计划（而非报错）
写入production/releases/day-one-patch.md前询问 "May I write toproduction/releases/day-one-patch.md?"
所有路径下判定均为 COMPLETE

这份清单与templates/skill-test-spec.md中定义的通用协议一致：写文件前 "May I write"、先呈现草案再请求批准、结尾给出下一步建议、未经批准不自动创建文件。它保证了day-one-patch的行为可被逐项验证，也使其在任何游戏项目中都具备一致的可预期性。

六、验证方法：如何用 Skill Testing Framework 测试本技能

本仓库的 CCGS Skill Testing Framework 是独立的测试基础设施，专用于验证技能与代理本身（而非用 CCGS 开发出的游戏）。对/day-one-patch可以执行三种粒度的验证：

# 1. 静态结构合规检查（7 项，无需 fixture） /skill-test static day-one-patch # 2. 行为规范测试（按 spec 的 5 个用例逐条评估） /skill-test spec day-one-patch # 3. 分类基准检查（utility 类的 U1/U2 指标） /skill-test category day-one-patch

其中行为级测试要求测试者先阅读 catalog.yaml 中该技能的spec:路径，再对照 skills/utility/day-one-patch.md 逐用例执行断言，并可按需构造 fixture（在production/bugs/、production/sprints/下准备对应的缺陷报告与故事文件）。测试结果可写入results/目录并回填catalog.yaml的last_spec/last_spec_result字段。若技能在实际运行中表现与 spec 不符，正确流程是先修正技能本身，再同步更新 spec——spec 描述的是当前行为而非理想行为。

七、小结：从一份行为规范看 CCGS 的发布工程哲学

/day-one-patch的技能规范虽然只有 175 行，却完整呈现了 CCGS 框架在"发布后运维"环节的设计思路：

数据源标准化：缺陷报告（production/bugs/）与故事文件（production/sprints/）由上游技能按固定约定产出，使得本技能可以无歧义地扫描、排序、估算；
严重度驱动排期：优先级与耗时估算完全由 CRITICAL/HIGH/MEDIUM/LOW 严重度推导，规则简单、可解释、可测试，同时明确承认这是粗略估算而非团队速率；
应急与计划分离：P0 必须走/hotfix即时通道，绝不被排进按天计算的补丁计划，其余问题则照常排期——规划器不做救火队；
延后项自动回收：/story-done记录的延后 AC 会在发布后被自动拉回计划，避免"发布前推迟、发布后遗忘"；
全路径判定 COMPLETE：空计划、P0 升级、正常排期都能稳定收敛到明确判定，配合 "May I write" 协作协议，让 AI 代理在每一个写操作前都尊重用户决策权。

对于希望在自己的游戏项目中落地这套发布流程的开发者，可以按本规范为模板，将/day-one-patch接入现有的production/目录约定，并配合/hotfix、/smoke-check、/patch-notes组成完整的 post-ship 修复链路——而这份行为规范，就是验证链路中每一环是否按预期工作的"测试合同"。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考