godot-grill

Godot Grill

誰もシーンツリーを設計したりコードを書いたりする前に、開発者だけが決められる事項を確定します。出力するのは意思決定記録であり、設計ではありません。

関連スキル： 決定が確定した後のシーンツリー、シグナルマップ、計画については godot-brainstorming、コンポジションと継承のトレードオフについては scene-organization、以降の内容を教える形式で提供する場合は godot-mentor を参照してください。

1. 事実ではなく、決定を尋ねる

ユーザーだけが知っていること、つまり意図、制約、優先事項、好みだけを尋ねます。

ノードの種類、API シグネチャ、バージョンによる違いは事実です。調べて確認し（godot-brainstorming/references/node-selection.md、各ドメインスキルを参照）、判断して記録します。これらについて質問してはいけません。

アーキテクチャの選択肢――データの保存先、状態の表現方法、保存形式――は、ユーザーの回答に基づいて決めるものであり、技術の選択肢として尋ねるものではありません。背景にある制約を尋ねてください（「デザイナーがインスペクターでアイテムを編集しますか？」など）。その回答から、こちらで Resource .tres を選びます。

質問	判定
「使い捨てのプロトタイプですか、それとも他のコードが基盤として使うシステムですか？」	決定事項 — 尋ねる
「プレイヤーには CharacterBody2D と RigidBody2D のどちらを使うべきですか？」	事実 — 判断して記録する
「2 人のクライアントの意見が食い違った場合、どちらが正しいですか？」	決定事項 — 尋ねる
「4.3 では Tween でステップを連結できますか？」	事実 — 決して尋ねない

2. 依存関係ツリーの種

前提条件のないルートは 4 つあります。

ルート	選択肢
スコープ	使い捨ての一部分 / 1 つの機能 / 他のものが基盤として使うシステム
次元	2D / 3D / 2.5D
言語	GDScript / C# / 両方
権限	シングルプレイヤー / ネットワーク対応（ネットワーク対応の場合、権限を持つのは誰か）

これを確定すると…	…次の判断が可能になります
スコープ	分岐を絞り込めます。使い捨ての一部分なら、永続化、データの保存先、ネットワーク、テストを省略します
権限	状態の所有者（信頼できる唯一の情報源）、シグナルと RPC の使い分け
次元	物理モデル、カメラモデル
言語	回答が「両方」の場合の相互運用境界
スコープ + 次元	エンティティモデル：コンポジションと継承の使い分け
エンティティモデル	データの保存先（Resource .tres / オートロード / ノードローカルの @export）；通信方法（上方向へのシグナル、下方向への呼び出し / EventBus / DI）
権限 + エンティティモデル	状態の表現方法（enum FSM / ノード FSM / AnimationTree / なし）；永続化の境界
データの保存先 + 永続化	保存形式（ConfigFile / JSON / Resource のシリアライズ）

右側の列には、回答を受けてこちらが判断できることを示しています。ユーザーには技術ではなく、その背景にある制約を尋ねてください。このツリーは種であり、台本ではありません。回答によって枝が広がります。「ネットワーク対応」という回答からは、シングルプレイヤーという回答では生じない分岐が生まれます。依頼やプロジェクトですでに答えが出ているルート（project.godot、既存のスクリプトなど）は飛ばしてください。ほとんどのセッションで確認するノードはわずかです。

3. ラウンド

第 1 ラウンドの前に、意思決定記録の保存場所を確認します。次の順に確認してください。まず、ユーザーの指示、またはプロジェクトのエージェント指示ファイル（CLAUDE.md、AGENTS.md、…）。次に、既存の意思決定記録または ADR のディレクトリです。記録済みの決定は確定済みの前提条件です。決して再質問せず、その先のフロンティアから開始してください。

フロンティアとは、前提条件が確定している未決の判断すべてです。推奨する回答をそれぞれ添えて、フロンティア全体を番号付きで 1 通のメッセージにまとめて質問してください。

❓ **Q1** — **<title>**: <the question, with its options>

➡️ <recommended answer, and why in one clause>

そこで止めて、回答を待ちます。前提条件がまだ未確定の質問は、後のラウンドに回します。尋ねる内容はすべて番号付きリストに含めます。その後に「ところで、ジャンルは……？」などと付け加えてはいけません。尋ねる価値のある内容には番号と ➡️ を付け、それ以外は次のラウンドまで保留します。

第 1 ラウンドは小規模にし、まずスコープを確定します。 スコープが最も多くの枝を絞り込むためです。「使い捨ての一部分」という回答なら、第 2 ラウンドでセッションが終わることもよくあります。

各ラウンドの後、回答をもとにフロンティアを再導出します。回答が記録済みの決定と矛盾する場合は、その旨を伝え、決定を見直すかどうか尋ねます。記録を黙って上書きしてはいけません。

4. グリルを終える

フロンティアが空になるか、どのラウンドでも（最初のメッセージを含めて）オフランプで「とにかく作って」／「質問は飛ばして」／「質問攻めはやめて」と言われたら、グリルを終了します。その後は質問をやめ、未決定の項目について、いま採用するすべての前提を一覧にして、ユーザーが確認して覆せるようにします。

**オフランプでは、確認や承認のゲートはありません。**前提を列挙し、記録を作成して、対応するドメインスキル、またはステップ 2 の godot-brainstorming を、セクションごとのチェックインなしで使って実装します。

フロンティアが空になったら、記録（§5）を作成し、1 つのメッセージで共通認識を確認して、待ちます。その後、次のように引き継ぎます。

• シーンツリー、シグナルマップ、または計画が必要 → ステップ 2 の godot-brainstorming
• 内容が明確な単一の変更 → 対応するドメインスキル

5. 意思決定の記録

GodotPrompter には専用の意思決定フォルダーがありません。このプロジェクトで記録を保管している場所に、次の順で確認して記録を書きます。まず、ユーザーの指示またはプロジェクトのエージェント指示ファイル（CLAUDE.md、AGENTS.md など）、次に既存の意思決定または ADR ディレクトリを確認します。該当するものがなければ、ユーザーに尋ね、docs/decisions/ を提案します。尋ねられない場合（サブエージェントまたは非対話型の実行）は、docs/decisions/ を使用します。ファイル名は YYYY-MM-DD-<topic>.md とします。パスは変更しないでください。次のグリルでは、この記録を読み返します。

# <Topic> — decisions

| Decision | Choice | Why | Revisit when |
|---|---|---|---|
| Bag model | Fixed 20 slots | Grid UI already designed | a weight system is wanted |
| Item data | Resource `.tres` | Inspector editing, typed exports | items exceed ~200 |

## Open / deferred
- Equipment stat aggregation — deferred to a later pass.
- Save slots — **assumed** 1 (off-ramp); revisit before shipping.

Revisit when は、決定を再検討できるようにするものであり、拘束力を持たせるものではありません。オフランプで採用した前提は Open / deferred の下に assumed と明記します。ファイルを書き込めない場合は、代わりに最終メッセージに記録を記載してください。

6. アンチパターン

アンチパターン	問題点	代わりに
質問を 1 つずつする	順番を事前に固定してしまい、前提条件より先に質問が届き、やり取りが増えます	フロンティア全体を質問します
事実を質問する	モデルの仕事にユーザーの注意を使わせてしまいます	調べて、判断し、記録します
推奨案のない質問	ユーザーは何も手掛かりのない状態で答えることになり、ラウンドが遅くなります	すべての質問に ➡️ を付けます
番号付きリストの外に最後の質問を置く	推奨案がなく、番号で回答する際に見落とされやすくなります	番号を付けるか、次のラウンドに回します
バグ修正や明示的な依頼についてグリルする	このスキルが陥ってはならない過剰修正です	ドメインスキルに引き継ぎます
記録済みの決定を再度質問する	記憶喪失のように感じられ、記録を無駄にします	まずプロジェクトの意思決定記録を保管している場所を読みます
最後の回答の後にコーディングする	共通認識の確認を飛ばしてしまいます	確認してから引き継ぎます

チェックリスト

• 第 1 ラウンドの前に既存の意思決定記録を読んだ
• 第 1 ラウンドでは、まずスコープを確定した
• すべての質問が意思決定に関するもので、番号と推奨案がある
• 各ラウンドでフロンティア全体を提示し、回答を待った
• オフランプが選ばれた → 前提を列挙した
• 記録を作成した（ファイルを書き込めない場合は最終メッセージに記載した）
• フロンティアが空になった → 設計またはコードの前にユーザーの確認を得た。オフランプの場合 → ゲートを設けず、列挙した前提に基づいて実装した