propagate-design-change

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,review_gate,automation,automation_always_ask,workflow,system_overrides

上で解決済みです。変更せずに使用してください。--review は今回の実行で review_mode を上書きします。ブロックがない場合は、.claude/docs/config-resolution.md のデフォルトを使用します。

質問ツールで質問してください。質問ツールがない場合は、選択肢に番号を付けて列挙し、ユーザーの応答を待つためにターンを終了してください。質問がスキップまたは閉じられた場合、それは回答ではありません。プレーンテキストでもう一度質問してください。

設計変更の反映

GDD が変更されると、それを前提として記述されたアーキテクチャ上の決定が、もはや有効でない場合があります。このスキルは、変更の影響を受けるすべての ADR を見つけ、ADR が前提としていた内容と現在の GDD の記述を比較し、それぞれについてユーザーと確認を進めます。

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

質問は .claude/docs/automation-modes.md に従います（協調モードでは常に質問し、ガイド付きモードでは重要な選択肢について質問し、自律モードでは記録して続行します。automation_always_ask カテゴリでは常に質問します。この場合、ADR への影響は schema_changes と architecture_decisions に該当します）。

ティア。 変更された GDD のシステムに対する workflow を使用します。該当するものがあれば、そのシステムの system_overrides の行を使用し、なければプロジェクトの値を使用します。minimal に固定されたシステムでは、プロジェクトが standard であっても ADR はありません。full ではすべての ADR を確認し、standard では Foundation レイヤーの重要な ADR と、変更された GDD に言及している ADR を確認します。minimal では確認対象はありません（Phase 4）。

Phase 1：GDD のパス

スキル名の後に入力されたテキストから、--review <mode> のペアを除いたものが、変更された GDD です。これは必須です。指定されていない場合：「使用方法：/propagate-design-change design/gdd/[system].md — 変更された GDD のパスを指定してください。」ファイルではない場合：「[path] が見つかりません。パスを確認して、もう一度お試しください。」

Phase 2：変更内容

必ず git に問い合わせてください。2 つの文書全体を目視で比較してはいけません。

git diff HEAD -- design/gdd/[filename].md

空の場合：変更はすでにコミットされている可能性があるため、このファイルに最後に触れたコミットまで対象を広げます：git diff HEAD~1 HEAD -- design/gdd/[filename].md。

• 履歴がまったくない場合（git log --oneline -1 -- design/gdd/[filename].md が何も出力しない）： 「git に以前のバージョンがありません。これは改訂ではなく、新しい GDD です。反映するものはありません。」と伝えて終了します。
• 履歴はあるものの、両方の diff が空の場合：「[file] に未コミットの変更も、最後のコミットによる変更もありません」と報告し、どのリビジョンを反映するか尋ねます。diff が空ということは、ここでは何も変更されていないという意味であり、影響がないという意味ではありません。

変更箇所から判断します。@@ ヘッダーは各変更が含まれるセクションを示すため、変更されたセクションの一覧は diff 自体から取得します。hunk がないセクションは、変更されていないものとして扱います。hunk だけでは理解できない場合（上のルールによって意味が決まる数値の変更など）に限り、該当するセクションの周辺を読みます。その場合も、そのセクションだけにしてください：bash .claude/scripts/md-section.sh extract design/gdd/[file].md "[Section]"。

Phase 3：変更の要約

## Change Summary: [GDD filename]
Date of revision: [today]

Changed sections:
- [Section]: [what changed — new rule, removed rule, formula modified, …]

Unchanged sections:
- [Section]

Key changes affecting architecture:
- [change likely to affect ADRs]

これらの事実を使用する他の GDD。 design/registry/entities.yaml が存在しない場合、またはエントリーがない場合（/design-system が設定するまで空のスタブとして提供されます）は、この手順をスキップしてください。以下の ADR チェックは引き続き実行します。それ以外の場合、このファイルには、このシステムの事実に依存する GDD が記録されています。source: design/gdd/[filename] を検索してください。この GDD が所有するエンティティ、定数、または数式のうち、diff によって値が変更されたものについては、referenced_by: リストに、現在の記述と食い違う可能性のある GDD が記載されています。それらを「再確認が必要な下流 GDD」の下に列挙してください。

フェーズ 4：対象範囲の ADR

bash .claude/scripts/adr-status.sh は、すべての ADR のステータス、レイヤー、欠落しているセクションを一覧表示します。

• full: すべての ADR。
• standard: 重要な ADR（layer 列が Foundation、またはレイヤーが設定されていないもの。不明な場合は重要とみなします）と、変更された GDD の名前を含む ADR。
• minimal: 「minimal ワークフローでは ADR の確認なし — 設計変更を記録済み。アーキテクチャへの影響分析なし。」と報告して終了します。

まず分母を確定します。件数は N です。N が 0 の場合：「docs/architecture/ に ADR が見つかりません — 確認対象はありません。」と報告して終了します。

この GDD を参照している ADR。 ADR 全体を読まずに、次を確認します。

1. 各 ADR の GDD Requirements Addressed セクション （bash .claude/scripts/md-section.sh extract <adr> "GDD Requirements Addressed"）で、変更された GDD を記載した行を確認します。
2. ADR 内で変更された GDD のファイル名を検索します。これにより、表の行ではなく本文で参照している ADR も見つけられます。

この 2 つの結果を合わせたものが、影響を受ける ADR の集合 M です。

結果	意味	対応
M ≥ 1	通常です。	続行します。N − M 件は今回の確認対象外です。影響がないことを検証済みであるかのように説明してはいけません。
M = 0、かつ対象範囲のすべての ADR に GDD Requirements Addressed がない（missing 列）	トレーサビリティを計算できません。	「[N] 件の ADR が見つかりましたが、'GDD Requirements Addressed' セクションを持つものはありません — トレーサビリティを計算できません（本番前ゲートのブロッカーです）。/architecture-decision retrofit [adr] を実行してください。」と報告して終了します。
M = 0、セクションは存在する	この GDD を参照する ADR はありません。	「[gdd] を参照する ADR はありません — アーキテクチャへの影響はありません。」と報告して終了します。

docs/architecture/requirements-traceability.md が存在する場合は読みます。

次のように報告します：「[N] 件の ADR を確認しました。[M] 件が [gdd filename] を参照しています（要件表内が [X] 件、本文のみが [Y] 件）。」

フェーズ 5：影響分析

M に含まれる各 ADR について、md-section.sh extract を使って Context、Decision、Consequences の各セクションを読みます。判断が今も有効かどうかを確認するには、その根拠が必要です。表の行だけを見て判断してはいけません。次に、変更された GDD から各 ADR が挙げている要件について、以下を確認します。

1. その要件は現在の GDD にも存在していますか？
2. ADR の作成時に GDD はどのように記述しており、現在はどのように記述されていますか？
3. その判断は今も有効ですか？

各 ADR を分類します。

ステータス	意味
✅ 引き続き有効	変更は、この ADR が決定した内容に影響しません
⚠️ 要レビュー	変更が影響する可能性があり、人による判断が必要です
🔴 置き換えられた可能性が高い	変更が、この ADR の前提と矛盾します

### ADR-NNNN: [title]
Status: [Still Valid | Needs Review | Likely Superseded]

What the ADR assumed about this GDD:
  "[quote from its GDD Requirements Addressed or Context]"

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

Assessment:
  [whether the decision still holds, and why]

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

フェーズ 6：影響レポートを提示してからレビューする

アクションを求める前に、レポート全体を提示します。

## Design Change Impact Report
GDD: [filename]
Date: [today]
Changes detected: [N sections changed]
ADRs referencing this GDD: [M]

### Not Affected
[ADRs whose decisions still hold]

### Needs Review ([count])
[ADRs that may need updating]

### Likely Superseded ([count])
[ADRs whose assumptions the change contradicts]

技術レビュー。 上記の review_gate 行を確認します。skill-gates=skip （単独またはリーン）：エージェントは使用せず、TD-CHANGE-IMPACT skipped — [Solo | Lean] mode と記録します。 skill-gates=run：レビューをゲート TD-CHANGE-IMPACT（.claude/docs/director-gates/td-change-impact.md。エージェント自身が読み取ります）とともに technical-director エージェントに渡します。概要：

• 目的： ユーザーがアクションを起こす前に、影響レポートを確認します。
• 渡すもの： 上記のレポート全体：変更の概要、分類と推奨アクションを含む、影響を受けるすべての ADR。
• 確認事項： ADR が過小分類されていないこと、推奨アクションが妥当であること、他の ADR やシステムへの波及効果を見落としていないこと。
• 回答： APPROVE、CONCERNS、REJECT、または不足している入力を明記した NOT ASSESSED。
• 制約： ファイルは編集しません。

判定に応じて対応します。

• APPROVE： フェーズ 7 に進みます。
• CONCERNS： 指摘された ADR またはアクションを提示し、「どのように進めますか？」と尋ねます。選択肢：影響評価を修正する／指摘された懸念を承知のうえで承認する／さらに議論する。
• REJECT： フェーズ 7 には進まず、まず影響を再分析します。
• NOT ASSESSED： 承認ではありません（.claude/docs/director-gates.md）。不足していたものを明記してから補い、レビューを再実行します。または、ユーザーがレビューなしで進めることを選んだ場合は、フェーズ 7 に進み、レポートと最終判定行に TD-CHANGE-IMPACT: NOT ASSESSED — [input] と記載します。

フェーズ 7：各 ADR を解決する

Needs Review または Likely Superseded とマークされた ADR について、1 つずつ次のように尋ねます：「ADR-NNNN （[title]）— [status]。どのようにしますか？」選択肢：

• Superseded とマークする（新しい ADR を作成します）
• その場で更新する（小規模な改訂）：改訂内容を記録します。編集はユーザーが行います
• 現状のままにする（この変更はこの決定に影響しません）
• 今はスキップする（後で再確認します）

Superseded とマークする。「[ADR file] の Status を Superseded に設定してもよいですか？」と尋ねます。承認されたら、その ## Status セクションの本文のみを置き換えます。

bash .claude/scripts/md-section.sh replace docs/architecture/[adr-file].md "Status" <<'EOF'
Superseded — replacement pending (see docs/architecture/change-impact-[date]-[system-slug].md)
EOF

このスキルが書き込む形式はこれだけです。adr-status.sh はこれを Superseded として読み取るため、/dev-story と /create-stories は、まだその ADR を参照しているストーリーをブロックします。新しい ADR を作成したら、どの ADR を置き換えるのかを記録します。ADR の他の箇所は変更しません。内容はそのまま維持されます。

フェーズ 8：トレーサビリティインデックス

docs/architecture/requirements-traceability.md が存在する場合、「変更した要件をトレーサビリティインデックスに追加してもよいですか？」と尋ねます。承認されたら、変更した要件ごとに 1 行追加します。

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

フェーズ 9：変更影響ドキュメント

「変更影響レポートを docs/architecture/change-impact-[date]-[system-slug].md に書き込んでもよいですか？」と尋ねます。このドキュメントには、変更の概要、影響分析、各 ADR について選択した解決方法、および新規作成または更新が必要な ADR が記載されます。

フェーズ 10：フォローアップ

解決方法に基づいて、次の内容を伝えます。

• Superseded とマークされた ADR：「置き換え用の ADR を作成するには /architecture-decision [title] を実行し、その後、対象範囲を再確認するために /propagate-design-change をもう一度実行してください。」
• その場で更新する ADR：それぞれで変更するフィールド。
• 影響を受ける ADR が多数ある場合：「更新後に /architecture-review を実行し、トレーサビリティマトリックスの整合性を確認してください。」

フェーズ 9 で書き込んだ後は Verdict: COMPLETE — change impact report saved で終了します。書き込みを拒否された場合は Verdict: BLOCKED — user declined the write で終了します。