design-review

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

上記で解決済みです。そのまま使用してください。--review は review_mode を上書きします。--depth は同じフラグの 1.1 より前の名称です。--depth <mode> は --review <mode> とまったく同じように扱い、名称が変更されたことを一度だけ説明してください。両方が指定されている場合は --review が優先され、--depth は無視されます。その旨を説明してください。ブロックがない場合のデフォルト値は .claude/docs/config-resolution.md に記載されています。

デザインレビュー

Phase 0：引数の解析

チェックの全パターンについては .claude/docs/director-gates.md を参照してください。個別のゲート定義は .claude/docs/director-gates/[gate-id].md にあります。起動されたエージェントは自身のゲートファイルを読み取ります。親セッションでは読み取らないでください。

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

レビュー対象の GDD の workflow — ブロックに <system> 用の system_overrides 行があればそれを使用し、なければプロジェクトの値を使用します。検証範囲はティアに従います。

• full — 8 つすべてのセクションを検証します。セクションが欠けている場合は承認をブロックします。
• standard — 必須の 5 セクション（Overview、Detailed Rules、Edge Cases、 Dependencies、Acceptance Criteria）が欠けている場合はブロックします。Formulas は、システムが数値ルール（率、曲線、しきい値、コストなど）を定義している場合にのみブロックします（カテゴリはヒントであり、判定基準ではありません）。Player Fantasy と Tuning Knobs は、workflow_overrides で必須とされていない限り、参考項目として扱います（警告は出しますが、ブロックはしません）。
• minimal — GDD は想定されていません。存在する場合は、標準の 5 セクションを参考として検証します。

解決されたモードによって、このレビューの詳細度が決まります。

• full：完全なレビュー — すべてのフェーズと専門エージェントへの委任（Phase 3b）
• lean：すべてのフェーズを実施し、専門エージェントへの委任は行いません — より迅速な単一セッションでの分析
• solo：Phase 1〜4 のみ実施し、委任も Phase 5 の次のステップのプロンプトも行いません — 別のスキル内から呼び出された場合に使用します

---

Phase 1：ドキュメントの読み込み

まず鮮度を確認してください。変更されていないドキュメントを再レビューすると、全コストがかかるうえ、同じ結論が再現されます。 次を実行します。

Bash: bash .claude/scripts/review-receipts.sh check "design/gdd/reviews/[doc-name]-review-log.md" "[target-doc-path]" "design/registry/entities.yaml"

このレビューではドキュメント間の事実確認のためにレジストリを参照するため、レジストリもチェック対象に含まれています。変更されていない GDD でも、変更されたレジストリを基にレビューすれば結論が異なる可能性があります。そのため、スキップしても安全なのは、リストにあるすべての行が UNCHANGED と表示されている場合に限られます（レジストリが存在しない場合は出力に表示されず、スキップの妨げにはなりません）。

• すべてが UNCHANGED で、ログの最新エントリに判定が記録されている場合は、それを提示します： 「このドキュメントは、[date] の前回レビューからバイト単位で変更されていません（判定： [verdict]）。」 判定が APPROVED の場合は、AskUserQuestion で次の選択肢を提示します： [A] 前回の判定を使用する（推奨） / [B] それでも再レビューする — guided では [A] を選択してその旨を記録し、autonomous では log_decision を使って記録し、前回の判定を使用します。判定が NEEDS REVISION または MAJOR REVISION NEEDED の場合は、明確に伝えます：ドキュメントはレビューで不合格になってから変更されていません。前回の指摘は引き続き有効です。次のステップはドキュメントの修正であり、再レビューではありません。ログから前回の指摘を表示するかどうかを尋ねます。
• レジストリの行だけが CHANGED（ドキュメントは UNCHANGED）の場合 — 文書間の事実を除き、前回の判定を維持します。ドキュメント内のレジストリ由来の値を新しいレジストリと照合して再検証し、判定を再発行します。矛盾が見つかった場合に限り、完全な再レビューに切り替えます。
• 対象ドキュメントが CHANGED または NEW、あるいは RECEIPT: NONE の場合 — 以下の完全なレビューを実施します。変更されていないセクションを読んだり再分析したりせずに済ませる、部分的な差分レビューを提案してはいけません。 セクション限定の再レビューでは、完全なレビューで見つかる欠陥を見落とし、節約できることもほとんどありません。 「前回のレビューから変更なし」とは、その時点でレビューされた内容とバイト単位で同一という意味にすぎません。前回のレビュー自体が完全だったかどうかは分からず、「とにかくすべてをスキャンする」という指示をいくら与えても、モデルの注意が自然に変更箇所へ狭まるのを確実に防ぐことはできません。

対象の設計ドキュメントを最初から最後まで読んでください。プロジェクトの背景と規約を理解するため、CLAUDE.md を読んでください。

文書間の事実については、関連する GDD よりもレジストリを優先してください。 design/registry/entities.yaml が存在し、このシステムのエントリが含まれている場合は、grep で検索してください。これらは確立済みの事実であり、この GDD は矛盾してはなりません。兄弟 GDD を読み、これらの事実を改めて探す必要はありません。

Grep pattern="source: design/gdd/[system].md" path="design/registry/entities.yaml" output_mode="content" -A 6
Grep pattern="design/gdd/[system].md" path="design/registry/entities.yaml" output_mode="content" -B 8

1つ目の検索では、このシステムが所有するエントリを見つけます。-A 6 のコンテキストには、それらの referenced_by: ブロックが含まれます。2つ目の検索では、このシステムを参照するエントリを見つけます。referenced_by: はブロックシーケンス形式（キーとパスが別々の行）なので、-B 8 のコンテキストを使って、referenced_by.*name という1行のパターン（ブロック形式には一致しません）ではなく、所有するエントリを確認してください。

design/registry/entities.yaml が存在しない、またはこのシステムのエントリが含まれていない場合 — このファイルは空のスタブとして配置されているため、/design-system が内容を追加するまではこれが既定の状態です。対象ドキュメントの Dependencies セクションで指定されている関連 GDD を読む方法に切り替えてください。読み取る範囲はそれらに限定し、「暗黙に示されている」ものすべてには広げないでください。design/gdd/ 全体を glob で読み込んではいけません。

依存関係グラフの検証： Dependencies セクションに記載されている各システムについて、Glob を使い、その GDD ファイルが design/gdd/ に存在するか確認してください。まだ存在しないものは、後続の執筆者が遭遇する参照切れとして指摘してください。

設定・物語との整合性： design/gdd/game-concept.md（または、rigor: minimal の場合は1ページの概要である design/game-brief.md）や、design/narrative/ 内のファイルが存在する場合は、それらを読んでください。この GDD の仕組み上の選択が、確立済みの世界設定のルール、トーン、デザインの柱と矛盾していないか確認してください。Phase 3b では、このコンテキストを game-designer に渡してください。

前回のレビューの確認： design/gdd/reviews/[doc-name]-review-log.md が存在するか確認してください。存在する場合は、最新のエントリを読み、判定と、記載されていたブロッキング項目を確認してください。今回のセッションは再レビューです。前回の項目が対処されたか追跡してください。

フェーズ 2：完全性チェック

ステップ 2a — ドキュメントを読み込まずに、セクションの有無を確定的に確認します：

Bash: bash .claude/scripts/gdd-structure-check.sh [target-doc-path]

PRESENT: リストと、該当する場合は ABSENT: リストを出力します。有無のみを報告し、REQUIRED／ADVISORY の判定は行いません。それはステップ 2b の役割です。## Detailed Design は Detailed Rules の要件を満たすものとしてすでに認識されるため、これを不足として指摘しないでください。

ステップ 2b — ティアを適用します。 ステップ 2a のリストを使って、以下の Design Document Standard チェックリストに照らして評価します。解決済みのワークフローティア（フェーズ 0）に従って、各セクションを REQUIRED または ADVISORY と判定してください。 REQUIRED セクションが欠けていると承認されません。ADVISORY セクションが欠けている場合は推奨事項として提示しますが、承認の妨げにはなりません。

PRESENT と報告されたセクションでも、見出しだけで本文が空の場合はレビューに不合格となることがあります。判定を左右するセクションは、部分的に読み込んで確認してください。

• Overview セクション（1 段落の概要）がある — すべてのティアで REQUIRED
• Player Fantasy セクション（意図する感情）がある — full では REQUIRED、standard では ADVISORY
• Detailed Rules セクション（曖昧さのないゲームメカニクス）がある — full／standard では REQUIRED。GDD テンプレートではこのセクションに ## Detailed Design という見出しが付けられています（Core Rules／States／Interactions のサブ見出しが含まれます）。どちらの見出しでもこの要件を満たすものとして認めてください。## Detailed Design セクションがある場合、「Detailed Rules」が不足していると指摘しないでください。
• Formulas セクション（変数を用いてすべての計算式が定義されている）がある — full では REQUIRED。standard では、システムに数値ルール（レート、曲線、しきい値、コスト、ダメージ、ドロップ率）が定義されている場合は REQUIRED。それ以外は ADVISORY です。システムの Category は参考情報であり、判定基準ではありません。カテゴリーのトークンだけを根拠に、これをクリアと判断しないでください。
• Edge Cases セクション（通常とは異なる状況への対応）がある — full／standard では REQUIRED
• Dependencies セクション（他のシステムの一覧）がある — full／standard では REQUIRED
• Tuning Knobs セクション（設定可能な値が特定されている）がある — full では REQUIRED。standard では、workflow_overrides.tuning_knobs が指定されている場合を除き、ADVISORY
• Acceptance Criteria セクション（検証可能な成功条件）がある — full／standard では REQUIRED

---

フェーズ 3：整合性と実装可能性

内部整合性：

• 計算式の結果は、説明されている動作と一致していますか？
• エッジケースが主要なルールと矛盾していませんか？
• 依存関係は双方向になっていますか（相手側のシステムはこのシステムを認識していますか）？

実装可能性：

• プログラマーが推測せずに実装できるほど、ルールは明確ですか？
• 詳細が不足している「曖昧な」セクションはありませんか？
• パフォーマンスへの影響は考慮されていますか？
• 各受け入れ基準は個別にテスト可能ですか？テスト可能でないものは、それぞれ引用して指摘し、測定可能な内容に書き換えてください。「バランスが取れている」「正しく動作する」「性能が良い」は基準ではありません。full モードでは qa-lead もこれらを確認します（フェーズ 3b）。lean と solo では専門担当が実行されないため、このメインレビューでの確認が唯一の機会です。

システム間の整合性：

• 既存のゲームメカニクスと矛盾していませんか？
• 他のシステムとの意図しない相互作用が生じませんか？
• ゲームで確立されているトーンや柱と一致していますか？

---

フェーズ 3b：専門担当による敵対的レビュー（full モードのみ）

lean または solo モードでは、このフェーズをスキップしてください。

このフェーズは full モードでは必須です。 スキップしないでください。

エージェントを起動する前に、次の通知を表示してください：

"Full review: spawning specialist agents in parallel. This typically takes 8–15 minutes. Use --review lean for faster single-session analysis."

ステップ 1 — GDD が扱うすべてのドメインを特定する

フェーズ 1 ですでに読み込まれている GDD を使用します。再読込はしないでください。含まれているすべてのドメインを特定します。GDD は同時に複数のドメインを扱う場合があります。漏れのないように確認してください。一般的な手がかりは次のとおりです。

GDD に次の内容が含まれている場合…	次のエージェントを起動する
コスト、価格、ドロップ、報酬、経済	economy-designer
戦闘ステータス、ダメージ、体力、DPS	game-designer、systems-designer
AI の振る舞い、経路探索、ターゲット指定	ai-programmer
レベル構成、スポーン、ウェーブ構造	level-designer
プレイヤーの進行、XP、アンロック	economy-designer、game-designer
UI、HUD、メニュー、プレイヤー向け表示	ux-designer、ui-programmer
会話、クエスト、ストーリー、伝承	narrative-director
アニメーション、操作感、タイミング、演出	gameplay-programmer
マルチプレイヤー、同期、レプリケーション	network-programmer
オーディオキュー、音楽のトリガー	audio-director
パフォーマンス、ドローコール、メモリ	performance-analyst
エンジン固有のパターンや API	主要エンジンのスペシャリスト（engine.name に基づく <engine>-specialist — Godot→godot-specialist、Unity→unity-specialist、Unreal→unreal-specialist。該当しない場合は technical-preferences.md の ## Engine Specialists にある Primary 行を使用）
受け入れ基準、テストカバレッジ	qa-lead
データスキーマ、リソース構造	systems-designer
ゲームプレイシステム全般	game-designer（必ず）

ゲームプレイのメカニクスやプレイヤー向けルールを記述するすべての GDD で、game-designer を起動します。 数式またはシステム間の相互作用ルールを含むすべての GDD で、systems-designer を起動します。 これらは最も一般的な基本担当ですが、UI 仕様のみ、オーディオ仕様のみ、または伝承に関する文書では必須ではありません。上のドメイン表を使って、本当に関係するスペシャリストを判断してください。

ステップ 2 — 関連するすべてのスペシャリストを並行して起動する

重要：このスキルでの Agent はサブエージェントを起動します。サブエージェントは独立した別の Claude セッションであり、独自のコンテキストウィンドウを持ちます。タスク管理ではありません。スペシャリストの視点を内部でシミュレートしないでください。自分で各ドメインの観点から推論しないでください。実際に Agent を呼び出す必要があります。レビューをシミュレートしても、スペシャリストによるレビューにはなりません。

すべての Agent 呼び出しを同時に実行します。1 つずつ起動しないでください。

各スペシャリストには、批判的な観点からプロンプトを送ります。

「こちらが [system] の GDD と、メインレビューでこれまでに見つかった構造上の問題です。 あなたの役割は、この設計を肯定することではありません。問題を見つけることです。 専門分野の知識に基づき、設計上の選択に異議を唱えてください。何が間違っているか、 仕様が不十分か、問題を引き起こしそうか、あるいは完全に欠けているかを指摘してください。 具体的かつ批判的に述べてください。メインレビューと意見が異なっていてもかまいません。」

エージェントの種類ごとの追加指示：

• game-designer：この GDD のセクション B に記載されたプレイヤーファンタジーを基準にレビューしてください。この設計は実際にそのファンタジーを実現していますか？プレイヤーは意図された体験を得られますか？実装しやすさを優先したルールが、明示された感覚を損なっている場合は指摘してください。

• systems-designer：GDD にあるすべての数式に対して、境界値（妥当な入力の最小値と最大値）を代入してください。出力が破綻しないか確認してください。負の値、ゼロ除算、無限大、または極端な値での不合理な結果があれば報告してください。

• qa-lead：すべての受け入れ基準をレビューしてください。個別にテストできない基準を指摘してください。「バランスが取れているように感じる」「正しく動作する」「パフォーマンスが良い」などの表現は、受け入れ基準ではありません。この確認に通らない基準については、具体的な書き換え案を提示してください。

ステップ 3 — シニアリードレビュー

すべての専門家が回答した後、creative-director をシニアレビュアーとして起動します：

• 提供するもの：GDD、すべての専門家の調査結果、専門家間の意見の相違
• 質問：「これらの調査結果を統合してください。最も重要な問題は何ですか？専門家の意見に同意しますか？このデザインに対する総合的な判定は何ですか — APPROVED、NEEDS REVISION、または MAJOR REVISION NEEDED？」
• creative-director の統合結果が、フェーズ 4 における最終判定になります。このスキルで使用する判定用語を使い、READY や REJECT などの director-gate 用語は決して使わないでください。

ステップ 4 — 意見の相違を明示する

専門家同士、または専門家と creative-director の意見が異なる場合は、一方の見解を黙って選ばないでください。フェーズ 4 で意見の相違を明示し、ユーザーが判断できるようにします。

各調査結果に出典を付記してください：[game-designer]、[economy-designer]、[creative-director] など。

---

フェーズ 4：レビュー結果

## Design Review: [Document Title]
Specialists consulted: [list agents spawned]
Re-review: [Yes — prior verdict was X on YYYY-MM-DD / No — first review]

### Completeness: [X/N sections present, where N is the count REQUIRED at this project's `modes.workflow`]
[List only sections missing that are REQUIRED at this tier. Mark ADVISORY gaps
separately as "advisory at `standard`" — do not list them as missing.]

> **N is not 8 unless `workflow: full`.** The tier table earlier in this skill is
> authoritative: 8 required at `full`, 5 at `standard` (+ Formulas when the system
> defines numeric rules), 0 at `minimal`. Hardcoding `/8` here
> reintroduces the tier confusion in the presentation layer after the logic
> layer already handles it — reporting a `standard` project as "5/8 missing Player
> Fantasy, Formulas, Tuning Knobs" warns about three sections that project's own
> configuration says it does not need, which trains the reader to ignore the
> review.

### Dependency Graph
[List each declared dependency and whether its GDD file exists on disk]
- ✓ enemy-definition-data.md — exists
- ✗ loot-system.md — NOT FOUND (file does not exist yet)

### Required Before Implementation
[Numbered list — blocking issues only. Each item tagged with source agent.]

### Recommended Revisions
[Numbered list — important but not blocking. Source-tagged.]

### Specialist Disagreements
[Any cases where agents disagreed with each other or with the main review.
Present both sides — do not silently resolve.]

### Nice-to-Have
[Minor improvements, low priority.]

### Senior Verdict [creative-director]
[Creative director's synthesis and overall assessment.]

### Scope Signal
Estimate implementation scope based on: dependency count, formula count,
systems touched, and whether new ADRs are required.
- **S** — single system, no formulas, no new ADRs, <3 dependencies
- **M** — moderate complexity, 1-2 formulas, 3-6 dependencies
- **L** — multi-system integration, 3+ formulas, may require new ADR
- **XL** — cross-cutting concern, 5+ dependencies, multiple new ADRs likely
Label clearly: "Rough scope signal: M (producer should verify before sprint planning)"

### Verdict: [APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED / NOT ASSESSED]

> **`NOT ASSESSED` when the review could not actually be performed.**
> The other three verdicts are all claims about the design's quality, so each one
> asserts that the document was read and judged. Use `NOT ASSESSED` instead when
> the target document is absent, unreadable, or empty of the sections being
> reviewed, or when a document it depends on is missing so the criteria cannot be
> applied. **Name what was unavailable and which skill produces it.**
>
> `APPROVED` is the dangerous default here: a review that could not find its
> input has not approved anything, and this verdict is consumed downstream as a
> sign-off. `NOT ASSESSED` outranks `APPROVED` in any aggregate — it does not
> outrank the two revision verdicts, because a known problem is more actionable
> than an unknown one.

このスキルは読み取り専用です — フェーズ 4 ではファイルに書き込みません。

---

フェーズ 5：次のステップ

終了時のやり取りにはすべて AskUserQuestion を使用してください。通常のテキストだけで終えてはいけません。

最初のウィジェット — 次に行うこと：

APPROVED（初回レビューで、修正が不要）の場合は、システムインデックスウィジェット、レビューログウィジェット、最後に終了ウィジェットへと直接進みます。「次に何をするか」を尋ねるウィジェットは別に表示しないでください — 終了ウィジェットで次のステップを確認します。

NOT ASSESSED の場合は、何もレビューされていません。トラッキング情報の更新は提案せず、最後の終了ウィジェットへ直接進み、不足している入力を作成するスキルを最初に提示します（例：GDD が存在しない場合は /design-system [system]）。

NEEDS REVISION または MAJOR REVISION NEEDED の場合は、調査結果に基づいて選択肢を作成します：

• [A] GDD を今すぐ修正する — ブロッキング項目をまとめて対処する
• [B] ここで終了する — 別のセッションで修正する
• [C] 現状のまま受け入れて次に進む — すべての調査結果が助言のみの場合（Required Before Implementation が空の場合）のみ含めます。ブロッキング項目が1つでもある場合は、[A] と [B] のみ提示します。

ユーザーが [A] — 今すぐ修正する、を選択した場合：

すべてのブロッキング項目に対応します。GDD と既存ドキュメントだけでは問題を解決できない場合に限り、デザイン上の判断をユーザーに尋ねます。編集を始める前に、デザイン上の判断に関する質問をすべて1つの複数タブ AskUserQuestion にまとめてください — ブロッカーごとに修正作業を中断してはいけません。

すべての修正が完了した後、要約表（ブロッカー → 適用した修正）を表示し、修正後の終了ウィジェットとして AskUserQuestion を使用します：

• プロンプト：「修正が完了しました — [N] 件のブロッカーを解決しました。次はどうしますか？」
• 現在のコンテキスト使用率を注記します。コンテキスト使用率が約50%を超えている場合は、次を追加します：「（推奨：再レビューの前に /clear を実行してください — このセッションではコンテキストの X% を使用しました。完全な再レビューでは5つのエージェントを実行するため、クリーンなコンテキストが必要です。）」
• 選択肢：
  • [A] 新しいセッションで再レビューする — /clear の後に /design-review [doc-path] を実行
  • [B] 今回は修正を受け入れる — システムインデックスで In Review に設定。Approved の判定には再レビューが必要です
  • [C] 次のシステムに進む — /design-system [next-system]（デザイン順で #N）
  • [D] ここで終了する

共同モードとガイド付きモードでは、通常のテキストだけで修正フローを終えてはいけません — 必ずこのウィジェットで終了してください。自律モードでは、結果を要約し、 log_decision で記録します。

2つ目のウィジェット — トラッキング記録（APPROVED の場合にまとめて実行）：

判定が APPROVED の場合は、multiSelect: true を指定した単一の AskUserQuestion を使って、2つのトラッキング更新をまとめて提示します：

• プロンプト：「判定：APPROVED。トラッキング記録を更新できます。対応してほしい項目を選択してください：」
• 選択肢：
  • [system] の systems-index.md のステータスを 'Approved' に更新する
  • design/gdd/reviews/[doc-name]-review-log.md に承認記録を追記する

レビューログの選択肢が選ばれた場合は、以下と同じ形式で追記します。選択された両方のアクションを実行してから、最後の終了ウィジェットを表示してください。

判定が NEEDS REVISION または MAJOR REVISION NEEDED の場合は、これまでどおり別々のウィジェットを使用します： 2つ目の AskUserQuestion を使用します。

• プロンプト：「design/gdd/systems-index.md を更新して、[system] を [Needs Revision / In Review] に変更してもよいですか？」 — 修正が未完了の間は Needs Revision（この文字列をそのまま使用）、修正が反映され、再レビュー待ちの状態になったら In Review を指定します。このプロンプトで Approved を提示することはありません。修正の判定は承認ではないためです。
• 選択肢：[A] はい — 更新する / [B] いいえ — そのままにする

3つ目の AskUserQuestion を使用します。

• プロンプト：「このレビューの要約を design/gdd/reviews/[doc-name]-review-log.md に追記してもよいですか？これにより修正履歴が作成され、今後の再レビューで変更点を追跡できます。」
• 選択肢：[A] はい — レビューログに追記する / [B] いいえ — 省略する

「はい」の場合、次の形式でエントリーを追記します。

## Review — [YYYY-MM-DD] — Verdict: [APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED]
Scope signal: [S/M/L/XL]
Specialists: [list]
Blocking items: [count] | Recommended: [count]
Summary: [2-3 sentence summary of key findings from creative-director verdict]
Prior verdict resolved: [Yes / No / First review]
Findings:
- [BLOCKING] [section]: [one-line finding]
- [RECOMMENDED] [section]: [one-line finding]
[output of: Bash: bash .claude/scripts/review-receipts.sh hash "[target-doc-path]" — plus "design/registry/entities.yaml" if the registry file exists]

指摘事項のルール：指摘事項ごとに1行で記載し、その指摘があるセクション名を付けます。 判定に指摘事項がなかった場合は - none と記載します。これは修正履歴を読む人のためのドキュメントであり、スキルが読み返す仕組みではありません。変更のないセクションの再分析を省略する差分再レビューは、完全なレビューと比較して評価した結果、試行後に撤回されました（Phase 1 を参照）。

ハッシュ行は、次回実行時に Phase 1 がバイト単位で同一の再レビューを検出するために読み取る記録です。入力が単に前回のレビューで十分に確認されたと見なされるのではなく、確実に同一であることを証明できるため、実際に安全な唯一の省略方法です。判定が何であれ、必ず記載してください。以前のレビューに不合格だったドキュメントに変更がない場合こそ、冗長な再レビューを省略することで最も節約できます（前回の指摘事項がそのまま有効です）。

---

最後の確認ウィジェット — すべてのファイル書き込み完了後に必ず表示します。

systems-index とレビューログのウィジェットに回答したら、プロジェクトの状態を確認し、最後の AskUserQuestion を1つ表示します。

選択肢を作成する前に、以下を読み取ります。

• design/gdd/systems-index.md — Status が In Review または Needs Revision のシステムを探します（今回レビューしたものを除く）。
• /review-all-gdds の提示が適切かどうかを判断するため、design/gdd/ 内の .md ファイル数を数えます（game-concept.md、systems-index.md を除く）。
• 設計順で、Status が Not Started の次のシステムを探します。

選択肢の一覧は動的に作成し、次に実行する候補のみを含めます。

• [_] /design-review [other-gdd-path] を実行 — [system name] はまだ [In Review / Needs Revision] です（別の GDD がレビューを必要としている場合に含めます）
• [_] /consistency-check を実行 — この GDD の値が既存の GDD と矛盾しないか確認します（他に GDD が1つ以上ある場合は必ず含めます）
• [_] /review-all-gdds を実行 — 設計済みのすべてのシステムを対象に、設計理論の観点から包括的にレビューします（GDD が2つ以上ある場合に含めます）
• [_] /design-system [next-system] を実行 — 設計順で次のシステム（必ず含め、実際のシステム名を指定します）
• [_] ここで終了

含める選択肢にのみ A、B、C…の文字を割り当てます。パイプラインを最も進める選択肢に (recommended) を付けます。

共同モードおよびガイドモードでは、ファイルへの書き込み後に通常のテキストだけでスキルを終了してはなりません。必ずこのウィジェットを最後に表示します。自律モードでは、次のステップを表示し、log_decision で記録します。