review-all-gdds

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

すべての GDD をレビューする

このスキルは、すべてのシステム GDD を同時に読み込み、GDD ごとに個別に行うことのできない、相互に補完する次の 2 種類のレビューを実施します。

1. GDD 間の一貫性 — ドキュメント間の矛盾、古い参照、所有権の競合
2. ゲームデザインの全体性 — すべてのシステムをまとめて見たときに初めて明らかになる問題：支配的な戦略、破綻した経済、認知的な過負荷、ゲームの柱からの逸脱、競合する進行ループ

これは、GDD 1 件の内部的な完全性をレビューする /design-review とは異なります。 このスキルでは、すべての GDD 間の 関係性 をレビューします。

実行するタイミング：

• MVP ティアの GDD がすべて個別に承認された後
• 制作途中で GDD が大幅に改訂された後
• /create-architecture の開始前（整合性のない GDD を基に構築したアーキテクチャには、その不整合が引き継がれます）

すべての AskUserQuestion 呼び出しは .claude/docs/automation-modes.md に従います（collaborative は常に質問 · guided は主要な項目のみ · autonomous は記録して続行；automation_always_ask カテゴリは常に確認します）。

引数のモード：

フォーカス： $ARGUMENTS（空欄の場合は full）

• 引数なし / full：一貫性とデザイン理論の両方をレビュー
• consistency：GDD 間の一貫性チェックのみ（高速）
• design-theory：ゲームデザインの全体性チェックのみ
• since-last-review：前回のレビュー報告以降に変更された GDD のみ（git ベース）

---

各 GDD の workflow（.claude/docs/workflow-modes.md に準拠）：各 GDD は、適用されるティアに照らして検証します。適用されるティアはプロジェクトの値であり、ブロックにそのシステムの項目がある場合は、system_overrides の該当行によってシステムごとに上書きされます。full の場合は、すべての GDD の 8 セクションすべてを検証します。standard の場合は、必須の 5 セクションを検証します。任意のセクション（Player Fantasy、Tuning Knobs、条件付きの Formulas）は参考情報としてのみ提示します。minimal の場合、このスキルは適用されません（GDD がないため）。

Phase 1: すべてを読み込む

今すぐ references/1-load.md を読み、その指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮または再開された場合は、もう一度読み込んでください。

並列実行

Phase 2（一貫性）と Phase 3（デザイン理論）は独立しています。どちらも同じ GDD を入力として読み込みますが、別々の報告を作成します。Phase 2 の完了を待ってから Phase 3 を開始するのではなく、両方を同時に並列の Agent エージェントとして起動してください。統合報告を作成する前に、両方の結果を収集してください。

両方とも game-designer サブエージェント（subagent_type: game-designer）として起動してください。GDD の一貫性とデザイン理論のレビューは、その専門領域です。

Phase 2 と Phase 3 のエージェントを起動する際は、必ず次の情報を渡してください：

• 各フェーズに必要な、読み込み済みの GDD の 内容 — ファイルパスではありません。該当するセクションを貼り付けてください。サブエージェントには独自のコンテキストがあり、Phase 1 の結果を再読み込みできません。そのため、パスを渡すと全内容を再読み込みすることになり、以下の「再読み込みしない」というルールにも反します。各フェーズに必要な範囲のみを渡してください。Phase 2（一貫性）には、各 GDD の Dependencies、Detailed Design/Rules、Formulas、Tuning Knobs、Acceptance Criteria が必要です。Phase 3（デザイン理論）には、Player Fantasy、進行／報酬の構造、ゲームの柱が必要です。
• Phase 1b で読み込んだ場合は、エンティティレジストリ全体の内容（design/registry/entities.yaml のテキストを貼り付けてください。ファイルパスだけでは不十分です）
• そのエージェントのフェーズに割り当てられたチェックリスト項目（Phase 2 には 2a–2f、Phase 3 には 3a–3g）
• エンジン名とバージョン — project.yaml の engine.name と engine.version。各フィールドは個別に解決し（キーが存在しないか空の場合は .claude/docs/technical-preferences.md を使用）、さらに docs/engine-reference/[engine]/VERSION.md も渡してください

サブエージェントがこれらのファイルを再読み込みすることを前提にしないでください。サブエージェントには独自のコンテキストウィンドウがあり、Agent のプロンプトで明示的に渡さない限り、Phase 1 の結果にアクセスできません。

---

フェーズ 2：GDD 間の整合性

今すぐ references/2-consistency.md を読み、その指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮されたり再開されたりした場合は、もう一度読み直してください。

フェーズ 3：ゲームデザインの全体性

今すぐ references/3-design-holism.md を読み、その指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮されたり再開されたりした場合は、もう一度読み直してください。

フェーズ 4：システム横断シナリオの検証

今すぐ references/4-scenarios.md を読み、その指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮されたり再開されたりした場合は、もう一度読み直してください。

フェーズ 5：レビュー報告書の出力

今すぐ references/5-report.md を読み、その指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮されたり再開されたりした場合は、もう一度読み直してください。

フェーズ 6：報告書の作成とGDDへのフラグ付け

今すぐ references/6-write.md を読み、その指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮されたり再開されたりした場合は、もう一度読み直してください。

フェーズ 7：引き継ぎ

今すぐ references/7-handoff.md を読み、その指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮されたり再開されたりした場合は、もう一度読み直してください。

エラー復旧プロトコル

まず、成果物を確認してください。 戻り値の契約でパスが指定されている場合は、フェーズが完了したと判断する前に、そのパスが存在することを確認してください — 指定された成果物がディスク上にない場合、どれほど流暢な応答であっても、そのフェーズは失敗です。 エージェントがフェーズ全体を費やしながら何も書き込まず、もっともらしい前置きだけを返すことがあります。これは BLOCKED にもエラーにも「未完了」にも該当しないため、以下のトリガーが作動しません。満たされていない契約を明示して再開してください。コンテキストは通常、まだ残っています。

起動したエージェントが BLOCKED を返す、エラーになる、または完了できない場合は、ただちにその事実を伝え、依存関係を妨げる処理より先へ進まず、必ず部分報告書を作成してください（再試行の範囲はここでは、GDD の数を減らす／単一システムに限定することです）。手順の全文： .claude/docs/error-recovery-protocol.md

---

コラボレーションプロトコル

collaborative モード（デフォルト）では、次のとおりです。 guided モードと autonomous モードについては、.claude/docs/automation-modes.md を参照してください。autonomous モードでも PASS/CONCERNS/FAIL の判定は引き続き表示・記録されます — 省略されるのは、最後の引き継ぎウィジェットのみです。

1. 黙って読む — 何かを提示する前に、すべての GDD を読み込みます
2. すべてを提示する — 何らかのアクションを求める前に、整合性とデザイン理論の分析全体を提示します
3. ブロッキング事項と助言事項を区別する — すべての問題がアーキテクチャをブロックする必要があるわけではありません。どの問題がブロックするのかを明確にしてください
4. デザイン上の決定を下さない — 矛盾や選択肢を指摘しますが、どの GDD が「正しい」かを一方的に決めてはいけません
5. 書き込む前に確認を取る — 報告書の作成やシステムインデックスの更新を行う前に、確認してください
6. 具体的に述べる — 各問題について、該当する GDD、セクション、テキストを正確に示してください。曖昧な警告は避けてください