企业官网建设流程全解析

Claude Code Game Studios /propagate-design-change：GDD修订后如何追踪下游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 怎么说」逐条对照，给出三类状态：

每个受影响 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 (I'll 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