propagate-design-change

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Propagate Design Change

传播设计变更

When a GDD changes, architectural decisions written against it may no longer be valid. This skill finds every affected ADR, compares what the ADR assumed against what the GDD now says, and guides the user through resolution.

Usage:

/propagate-design-change design/gdd/combat-system.md

当GDD发生变更时，基于它制定的架构决策可能不再有效。本Skill会找出所有受影响的ADR，对比ADR原本的假设与GDD当前的内容，并引导用户完成解决流程。

用法：

/propagate-design-change design/gdd/combat-system.md

1. Validate Argument

1. 验证参数

A GDD path argument is required. If missing, fail with:

"Usage:
/propagate-design-change design/gdd/[system].md
Provide the path to the GDD that was changed."

Verify the file exists. If not, fail with:

"[path] not found. Check the path and try again."

必须提供GDD路径参数。如果缺失，返回错误提示：

"用法：
/propagate-design-change design/gdd/[system].md
请提供已变更的GDD文件路径。"

验证文件是否存在。如果不存在，返回错误提示：

"[路径] 未找到。请检查路径后重试。"

2. Read the Changed GDD

2. 读取已变更的GDD

Read the current GDD in full.

完整读取当前GDD的内容。

3. Read the Previous Version

3. 读取历史版本

Run git to get the previous committed version:

bash

git show HEAD:design/gdd/[filename].md

If the file has no git history (new file), report:

"No previous version in git — this appears to be a new GDD, not a revision. Nothing to propagate."

If git returns the previous version, do a conceptual diff:

Identify sections that changed (new rules, removed rules, modified formulas, changed acceptance criteria, changed tuning knobs)
Identify sections that are unchanged
Produce a change summary:

undefined

通过git获取上一次提交的版本：

bash

git show HEAD:design/gdd/[filename].md

如果文件没有git历史记录（新文件），则提示：

"git中无历史版本——这似乎是一份新的GDD，而非修订版本。无需传播任何变更。"

如果git返回了历史版本，执行概念性差异分析：

识别已变更的章节（新增规则、移除规则、修改公式、变更验收标准、调整参数）
识别未变更的章节
生成变更摘要：

undefined

Change Summary: [GDD filename]

变更摘要：[GDD文件名]

Date of revision: [today]

Changed sections:

[Section name]: [what changed — new rule, removed rule, formula modified, etc.]

Unchanged sections:

[Section name]

Key changes affecting architecture:

[Change 1 — likely to affect ADRs]
[Change 2]

---

修订日期：[今日]

已变更章节：

[章节名称]：[变更内容——新增规则、移除规则、公式修改等]

未变更章节：

[章节名称]

影响架构的关键变更：

[变更1——可能影响ADR]
[变更2]

---

4. Load Architecture Inputs

4. 加载架构输入

Read all ADRs in

docs/architecture/

For each ADR, read the full file
Extract the "GDD Requirements Addressed" table
Note which GDD documents and requirement IDs each ADR references

Read

docs/architecture/architecture-traceability.md

if it exists.

Report: "Loaded [N] ADRs. [M] reference [gdd filename]."

读取

docs/architecture/

目录下的所有ADR：

读取每个ADR的完整内容
提取“GDD需求对应表”
记录每个ADR引用的GDD文档和需求ID

如果

docs/architecture/architecture-traceability.md

存在，读取该文件。

提示："已加载[N]份ADR。其中[M]份引用了[gdd文件名]。"

5. Impact Analysis

5. 影响分析

For each ADR that references the changed GDD:

Compare the ADR's "GDD Requirements Addressed" entries against the changed sections of the GDD. For each referenced requirement:

Locate the requirement in the current GDD — does it still exist?
Compare: What did the GDD say when the ADR was written vs. what it says now?
Assess the ADR decision: Is the architectural decision still valid?

Classify each affected ADR as one of:

Status	Meaning
✅ Still Valid	The GDD change doesn't affect what this ADR decided
⚠️ Needs Review	The GDD change may affect this ADR — human judgment needed
🔴 Likely Superseded	The GDD change directly contradicts what this ADR assumed

For each affected ADR, produce an impact entry:

undefined

针对每一份引用了已变更GDD的ADR：

将ADR的“GDD需求对应表”条目与GDD的已变更章节进行对比。对于每个引用的需求：

定位需求：在当前GDD中查找该需求是否仍然存在？
对比内容：ADR撰写时GDD的内容与当前内容有何差异？
评估ADR决策：该架构决策是否仍然有效？

将每个受影响的ADR分类为以下状态之一：

状态	含义
✅ 仍然有效	GDD变更不影响该ADR的决策
⚠️ 需要评审	GDD变更可能影响该ADR——需要人工判断
🔴 可能已过时	GDD变更直接与该ADR的假设相矛盾

为每个受影响的ADR生成影响条目：

undefined

ADR-NNNN: [title]

ADR-NNNN: [标题]

Status: [Still Valid / Needs Review / Likely Superseded]

What the ADR assumed about this GDD: "[relevant quote from the ADR's GDD Requirements Addressed section]"

What the GDD now says: "[relevant quote from the current GDD]"

Assessment: [Explanation of whether the ADR decision is still valid, and why]

Recommended action: [Keep as-is | Review and update | Mark Superseded and write new ADR]

---

状态：[仍然有效 / 需要评审 / 可能已过时]

ADR对该GDD的假设： "[ADR的GDD需求对应部分的相关引用]"

GDD当前内容： "[当前GDD的相关引用]"

评估： [说明ADR决策是否仍然有效及原因]

建议操作： [保持原样 | 评审并更新 | 标记为过时并撰写新ADR]

---

6. Present Impact Report

6. 呈现影响报告

Present the full impact report to the user before asking for any action. Format:

undefined

在请求用户执行任何操作前，先向用户呈现完整的影响报告。格式如下：

undefined

Design Change Impact Report

设计变更影响报告

GDD: [filename] Date: [today] Changes detected: [N sections changed] ADRs referencing this GDD: [M]

GDD：[文件名] 日期：[今日] 检测到的变更：[N个章节已变更] 引用该GDD的ADR：[M份]

Not Affected

未受影响

[ADRs referencing this GDD whose decisions remain valid]

[引用该GDD但决策仍有效的ADR列表]

Needs Review ([count])

需要评审 ([数量])

[ADRs that may need updating]

[可能需要更新的ADR列表]

Likely Superseded ([count])

可能已过时 ([数量])

[ADRs whose assumptions are now contradicted]

---

[假设已被矛盾的ADR列表]

---

6b. Director Gate — Technical Impact Review

6b. 主管审核门——技术影响评审

Review mode check — apply before spawning TD-CHANGE-IMPACT:

```
solo
```
→ skip. Note: "TD-CHANGE-IMPACT skipped — Solo mode." Proceed to Phase 7.
```
lean
```
→ skip. Note: "TD-CHANGE-IMPACT skipped — Lean mode." Proceed to Phase 7.
```
full
```
→ spawn as normal.

Spawn

technical-director

via Task using gate TD-CHANGE-IMPACT (

.claude/docs/director-gates.md

Pass: the full Design Change Impact Report from Phase 6 (change summary, all affected ADRs with their Still Valid / Needs Review / Likely Superseded classifications, and recommended actions).

The technical-director reviews whether:

The impact classifications are correct (no ADRs under-classified)
The recommended actions are architecturally sound
Any cascading effects on other ADRs or systems were missed

Apply the verdict:

APPROVE → proceed to Phase 7 resolution workflow

CONCERNS → surface the specific ADRs or recommendations flagged; use

AskUserQuestion

with options:

Revise the impact assessment

Accept with noted concerns

Discuss further

REJECT → do not proceed to resolution; re-analyze the impact before continuing

评审模式检查——在启动TD-CHANGE-IMPACT前执行：

```
solo
```
→ 跳过。提示："TD-CHANGE-IMPACT已跳过——单例模式。" 进入第7阶段。
```
lean
```
→ 跳过。提示："TD-CHANGE-IMPACT已跳过——精简模式。" 进入第7阶段。
```
full
```
→ 正常启动。

通过Task启动

technical-director

，使用审核门TD-CHANGE-IMPACT（

.claude/docs/director-gates.md

）。

传递内容：第6阶段生成的完整设计变更影响报告（变更摘要、所有受影响ADR的状态分类及建议操作）。

技术主管需评审以下内容：

影响分类是否正确（无ADR被低估影响）
建议操作是否符合架构合理性
是否遗漏了对其他ADR或系统的连锁影响

根据评审结果执行：

批准 → 进入第7阶段的解决工作流
有疑问 → 列出被标记的特定ADR或建议；使用
```
AskUserQuestion
```
提供选项：
```
修订影响评估
```
/
```
接受并记录疑问
```
/
```
进一步讨论
```
拒绝 → 不进入解决流程；重新分析影响后再继续

7. Resolution Workflow

7. 解决工作流

For each ADR marked "Needs Review" or "Likely Superseded", ask the user what to do:

Ask for each ADR in turn:

"ADR-NNNN ([title]) — [status]. What would you like to do?" Options:
"Mark Superseded (I'll write a new ADR)" — updates ADR status line to
Superseded by: [pending]
"Update in place (minor revision)" — opens the ADR for editing; note what to revise

"Keep as-is (the change doesn't actually affect this decision)"

"Skip for now (revisit later)"

For ADRs marked Superseded:

Update the ADR's Status field:

Superseded by ADR-[next number] (pending — see change-impact-[date]-[system].md)

Ask: "May I update the status in [ADR filename]?"

针对每一份标记为“需要评审”或“可能已过时”的ADR，询问用户操作方式：

逐个询问每个ADR：

"ADR-NNNN ([标题]) — [状态]。您希望如何处理？" 选项：
"标记为过时（我将撰写新ADR）" — 将ADR状态行更新为
Superseded by: [pending]
"就地更新（小幅修订）" — 打开ADR进行编辑；注明需要修订的内容

"保持原样（变更实际不影响该决策）"

"暂时跳过（稍后再处理）"

对于标记为过时的ADR：

更新ADR的状态字段：

Superseded by ADR-[下一个编号] (pending — see change-impact-[date]-[system].md)

询问："是否允许我更新[ADR文件名]中的状态？"

8. Update Traceability Index

8. 更新可追溯性索引

docs/architecture/architecture-traceability.md

exists:

Add the changed GDD requirements to the "Superseded Requirements" table:

markdown

undefined

如果

docs/architecture/architecture-traceability.md

存在：

将已变更的GDD需求添加到“已过时需求”表中：

markdown

undefined

Superseded Requirements

已过时需求

Date	GDD	Requirement	Changed To	ADRs Affected	Resolution
[date]	[gdd]	[old requirement text]	[new requirement text]	ADR-NNNN	[Superseded/Updated/Valid]


Ask: "May I update the traceability index?"

---

日期	GDD	需求	变更后内容	受影响ADR	解决结果
[日期]	[gdd]	[旧需求文本]	[新需求文本]	ADR-NNNN	[过时/已更新/有效]


询问："是否允许我更新可追溯性索引？"

---

9. Output Change Impact Document

9. 输出变更影响文档

Ask: "May I write the change impact report to

docs/architecture/change-impact-[date]-[system-slug].md

The document contains:

The change summary from step 3
The full impact analysis from step 5
Resolution decisions made in step 7
List of ADRs that need to be written or updated

If user approved: Verdict: COMPLETE — change impact report saved. If user declined: Verdict: BLOCKED — user declined write.

询问："是否允许我将变更影响报告写入

docs/architecture/change-impact-[date]-[system-slug].md

？"

该文档包含：

第3阶段的变更摘要
第5阶段的完整影响分析
第7阶段做出的解决决策
需要撰写或更新的ADR列表

如果用户批准：结果：完成——变更影响报告已保存。如果用户拒绝：结果：受阻——用户拒绝写入操作。

10. Follow-Up Actions

10. 后续操作建议

Based on the resolution decisions, suggest:

ADRs marked Superseded: "Run
```
/architecture-decision [title]
```
to write the replacement ADR. Then re-run
```
/propagate-design-change
```
to verify coverage."
ADRs to update in place: List the specific fields to update in each ADR
If many ADRs affected: "Run
```
/architecture-review
```
after all ADRs are updated to verify the full traceability matrix is still coherent."

根据解决决策，给出以下建议：

标记为过时的ADR："运行
```
/architecture-decision [标题]
```
来撰写替代ADR。然后重新运行
```
/propagate-design-change
```
以验证覆盖范围。"
需就地更新的ADR：列出每个ADR中需要更新的具体字段
若大量ADR受影响："在所有ADR更新完成后运行
```
/architecture-review
```
，以验证完整的可追溯性矩阵仍然一致。"

Collaborative Protocol

协作协议

Read silently — compute the full impact before presenting anything
Show the full report first — let the user see the scope before asking for action
Ask per-ADR — don't batch decisions; each affected ADR may need different treatment
Ask before writing — always confirm before modifying any file
Non-destructive — never delete ADR content; only add "Superseded by" notes

静默计算——在呈现任何内容前先完成完整的影响计算
先展示完整报告——让用户先了解范围再请求操作
逐个询问ADR——不要批量决策；每个受影响的ADR可能需要不同处理
写入前询问——修改任何文件前始终确认
非破坏性——永远不要删除ADR内容；仅添加“被以下内容替代”的注释