Claude Code Game Studios /propagate-design-change:GDD修订后如何追踪下游ADR、TR-registry、Epic与Story并按工件逐个审批

发布时间:2026/9/13 2:15:07
Claude Code Game Studios /propagate-design-change:GDD修订后如何追踪下游ADR、TR-registry、Epic与Story并按工件逐个审批 Claude Code Game Studios /propagate-design-changeGDD修订后如何追踪下游ADR、TR-registry、Epic与Story并按工件逐个审批【免费下载链接】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在一个已经跑完/create-epics和/create-stories的 Claude Code Game Studios 项目里GDD 不是一次写完就不动的某个系统的需求改了一行公式下游的 ADR、TR-registry 条目、Epic 和 Story 就可能带着过期假设继续往下走。/propagate-design-change就是为这个时刻准备的它读取修订后的 GDD与 git 中的上一版本做对比扫描所有引用该 GDD 的下游工件输出一份影响报告然后逐个工件向你请求写入许可——分析阶段只读写入阶段每个文件单独审批它不会自动应用任何修改。前提是项目已克隆并能在 Git 仓库中运行GDD 已有提交历史修订要能被 git 对比出来且项目已按模板目录布局组织GDD 在design/gdd/ADR 与 TR-ID 注册表在docs/architecture/Epic 与 Story 在production/epics/下。这个目录约定在 WORKFLOW-GUIDE.md 的 Phase 5 一节有说明/propagate-design-change正是「GDD 在 Story 创建之后发生变化」时的入口。执行命令与参数要求基本用法就是一条带路径参数的斜杠命令文档中的示例是/propagate-design-change design/gdd/combat-system.md参数是必填的。技能定义SKILL.md规定缺少参数时直接失败并输出用法提示Usage: /propagate-design-change design/gdd/[system].md提示你提供被修改的 GDD 路径。参数指向的文件不存在时报[path] not found. Check the path and try again.行为规范测试规范还要求无参数时列出最近修改过的 GDD 作为建议但不会替你悄悄选一个 GDD 开始分析。技能内部的分析流程命令执行后技能按 SKILL.md 定义的阶段推进你可以把下面这些阶段当作它「应该做到什么」的核对清单1. 读取新旧两版 GDD。它先完整读取当前 GDD然后取 git 中的上一个提交版本做对比git show HEAD:design/gdd/[filename].md[filename]即你传入参数中的文件名。如果文件没有 git 历史新建的 GDD它会报告No previous version in git — this appears to be a new GDD, not a revision. Nothing to propagate.也就是说对全新 GDD 运行此技能会得到明确结论而不是报错。如果 git 能取回上一版它会做概念性 diff识别哪些章节变了新规则、删除的规则、改动的公式、改动的验收标准、改动的调优旋钮哪些没变并生成一份 Change Summary其中单列「Key changes affecting architecture」——即那些可能波及 ADR 的改动。2. 加载架构侧输入。它读取docs/architecture/下所有 ADR 全文提取每个 ADR 的「GDD Requirements Addressed」表记录哪些 ADR 引用了当前 GDD 及其需求 ID如果docs/architecture/architecture-traceability.md存在也会读入。完成后会报告形如Loaded [N] ADRs. [M] reference [gdd filename]的加载情况。3. 扫描下游工件。按行为规范技能扫描 ADR、TR-registry 条目、Epic 和 Story 中对这份 GDD 的引用找出受影响的部分。这里 TR-registry 的角色由 tr-registry.yaml 文件头注释定义它为每条 GDD 技术需求分配永久 TR-ID格式TR-[system-slug]-NNN规则是——需求换措辞意图不变时更新requirement文本并加revised日期ID 保持不变需求从 GDD 移除时置status: deprecated需求被拆分或替换时置superseded-by指向新 TR-ID。ID 永不重排、永不删除这样 Story 中内嵌的 TR-ID 引用/create-stories写入的才不会失效。当修订后的 GDD 要求新增或更新 TR-ID 时这部分影响属于分析阶段的产出与 ADR 影响遵循同一套逐工件审批模式。4. 对每个受影响 ADR 做影响判定。技能把 ADR 中「当时 GDD 怎么说」与「现在 GDD 怎么说」逐条对照给出三类状态状态含义✅ Still ValidGDD 的改动不影响该 ADR 的决定⚠️ Needs Review改动可能波及该 ADR需要人判断 Likely Superseded改动直接推翻了该 ADR 的假设每个受影响 ADR 都会得到一条影响条目包含ADR 当时引用的需求原文、当前 GDD 的对应表述、判定理由以及建议动作Keep as-is / Review and update / Mark Superseded and write new ADR。5. 先给完整报告再谈审批。在请求任何动作之前技能必须完整呈现影响报告格式为## Design Change Impact Report GDD: [filename] Date: [today] Changes detected: [N sections changed] ADRs referencing this GDD: [M] ### Not Affected ### Needs Review ([count]) ### Likely Superseded ([count])如果某个被引用的 Story 正处于Status: In Progress影响报告中会出现一条高一级别的警告先于该工件的审批请求出现大意是「该 Story 正在开发中更新前先与开发者协调」警告不阻断选项你仍然可以为它批准或跳过更新。在full审查模式下报告还会交给technical-director做 TD-CHANGE-IMPACT 门检核对分类是否有漏判、建议动作是否架构合理、是否遗漏级联影响APPROVE 则进入解决流程CONCERNS 则就具体条目给你修订/接受/继续讨论的选项REJECT 则回到重新分析。solo或lean模式下该门检跳过并注明原因。按工件逐个审批报告呈现后对每个标记为 Needs Review 或 Likely Superseded 的 ADR技能逐个询问ADR-NNNN ([title]) — [status]. What would you like to do?选项为Mark Superseded (Ill write a new ADR)— 把该 ADR 状态行更新为Superseded by ADR-[next number] (pending — see change-impact-[date]-[system].md)Update in place (minor revision)— 就地打开 ADR 编辑并标注修订点Keep as-is— 确认该改动实际不影响这条决策Skip for now— 留待以后处理随后每个写入动作都单独确认更新 ADR 状态前问 May I update the status in [ADR filename]?把被取代需求写入architecture-traceability.md的 Superseded Requirements 表Date / GDD / Requirement / Changed To / ADRs Affected / Resolution 六列前问 May I update the traceability index?;把整份变更影响报告落盘前问 May I write the change impact report todocs/architecture/change-impact-[date]-[system-slug].md?。这套「先展示草稿、逐文件请求许可」是项目的协作协议见 COLLABORATIVE-DESIGN-PRINCIPLE.md技能还承诺非破坏性从不删除 ADR 内容只追加Superseded by标注。如何验证一次运行是否完成判定结论Verdict是文档明确给出的核对点下游没有任何引用时技能输出 No downstream impact found判定为NO IMPACT不发起任何写入。全部批准的内容已写入、变更影响报告保存后判定为COMPLETE。你拒绝了最终写入时判定为BLOCKED — user declined write。同时可以核对影响报告是否在审批之前完整呈现May I write 是否按工件逐一发出而不是对整批工件问一次In Progress 的 Story 是否在审批请求之前被加警告全部工件批准后是否以 COMPLETE 收尾并给出下一步交接。后续动作技能结束时会按你的解决决定建议下一步均来自 SKILL.md 第 10 步被标记 Superseded 的 ADR运行/architecture-decision [title]写替代 ADR然后重新运行/propagate-design-change验证覆盖。需要就地更新的 ADR列出每个 ADR 要更新的具体字段。影响面较大时所有 ADR 更新完成后运行/architecture-review校验完整追溯矩阵仍然连贯。需要注意的边界该技能依赖 git 历史识别「什么变了」新建且未提交的 GDD 不在它的处理范围内它替代的是「人工 grep 一遍谁引用了这个 GDD」不替代对 ADR 本身的架构判断——Needs Review 与 Likely Superseded 的分寸仍由你最终拍板。【免费下载链接】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),仅供参考