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 StudiosCCGS框架中负责首发日补丁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、SeverityCRITICAL/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 toproduction/releases/day-one-patch.md?得到用户确认后才能落盘判定协议所有路径下技能判定恒为COMPLETE空计划、P0 升级、正常排期均不例外门禁协议不触发任何 director gateCD-/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 1Happy Path —— 3 个已知问题产出带估算的补丁计划Fixtureproduction/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 2P0 关键缺陷 —— 升级为 /hotfix 引导P0 不入排期Fixturev1.0 发布后发现一个 CRITICAL 严重度缺陷且会造成所有存档文件数据丢失。期望行为读取缺陷并识别出 CRITICAL 严重度问题升级提示P0 ISSUE DETECTED — data loss bug requires immediate hotfix before patch planning can proceedP0 问题已检测——数据丢失缺陷需要在补丁规划前立即热修复不把 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 的延后验收标准Fixtureproduction/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零已知问题 —— 空计划 模板保留Fixtureproduction/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 5Director Gate —— 规划类工具不触发任何门禁Fixtureproduction/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 标注对 CRITICALP0缺陷升级并给出显式/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 修复链路——而这份行为规范就是验证链路中每一环是否按预期工作的测试合同。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考