grilling

ユーザーに対象のあらゆる側面について徹底的に質問し、共通認識に達するまで続けてください。設計ツリーとしてモデル化します。各決定は、その決定にぶら下がる決定へ枝分かれします。

フロンティア

フロンティアとは、前提となる決定が確定している未決定事項すべてです。まだ聞いていない回答を推測せずに、今尋ねられる質問のことです。回答のたびにツリーは形を変えます。ノードを確定し、その下の決定を可能にし、矛盾があれば以前の分岐を再び開くこともあります。回答のたびにフロンティアを再計算してください。事前に用意されたリストではありません。

質問する

回答によって設計が変わる間は、一度に一問だけ尋ねてから、回答を待ってください。ツリーの中で最も多くの決定を可能にするフロンティアの項目を選んでください。推奨案が二回答続けて採用された場合、または残りが重要度の低い事項や独立した事項（配置、命名、日付、ADR の形式など）になった場合は、残りのフロンティアを、各項目に推奨デフォルトを付けた番号付きの一括質問として送信し、「残りを承認」または例外の提示を求めてください。ユーザーが読まずに承認する可能性がある項目に限り、一括質問に含めてください。一括質問のデフォルトは、読まずに承認されるものです。そのため、そこに含める各前提（パス、名前空間、認証、上限）には、ファイル名と行番号を付けてください。「既存の X で対応済み」という形式のデフォルトや、並行処理または競合状態に関するデフォルトにも、番号付きのインターリーブ手順（誰が何を、いつ読み取るか）を付け、その手順をまたいで状態を保持する値と、その値が読み取られるファイル名と行番号を明記してください。その値を特定できない競合状態に関するデフォルトは一括質問に含めず、個別の質問として尋ねてください。記録済みの決定を覆す質問、ADR を作成する質問、または選択肢が三つ以上ある質問は、推奨案が何度採用されていても、一度に一問だけ尋ねてください。すぐに受け入れられたからといって、ユーザーに余裕があるとは限りません。推奨案への信頼を示しているにすぎません。

各質問は、次の形式にしてください。

❓ **Q<n>** - **<question title>** (<k> more on the frontier)

<question body, might be multiple paragraphs, including the choices>

➡️ <your recommended answer, and why>

推奨案は、質問への回答として表現してください。そうすれば、それに同意することが「はい」と答えることに当たります。

選択肢が以前の作業で使われたラベル（プロトタイプのバリエーション、別チケットの決定、コードネームなど）で示される場合は、質問文にその内容を示してください。該当する成果物があれば（画像のパスやリンクなど）そのものを示し、なければ平易な一文で説明してください。ユーザーがセッションをまたいでもラベルを覚えているとは想定しないでください。

ユーザーがラウンド形式を求めた場合は、代わりにフロンティア全体を一度に尋ねてください。各質問には上記の形式で番号を付け、--- で区切ってください。他の質問に依存する質問は、同じラウンドに含めず、次のラウンドで尋ねてください。

事実、デフォルト、意思決定

_事実_を見つけるのはあなたの仕事です。質問の答えに環境（コード、ファイル、ドキュメント、ツール）の事実が必要なら、尋ねるのではなく調べてください。時間のかかる作業はサブエージェントに依頼してください。リポジトリに存在するものが事実なら、フェッチ後の origin/<default> を基準に述べてください。作業ツリーを基準にしてはいけません。ローカルのチェックアウトはキャッシュであり、フェッチしていないと、すでにマージされた変更を存在しないものとして誤って説明してしまいます。これは各選択肢の前提にも当てはまります。選択肢を示す前に、それぞれが依存する事実（対象システムの形式、パス、制限、権限）を列挙し、調べてください。前提が未検証の選択肢は、本文でその旨を示し、その選択肢に基づいて推奨してはいけません。名前は前提ではありません。テーブル、関数、ロールの名前は、その作者が何を意図したかを示すにすぎません。それを根拠にする前に、データを読み込むコードを開き、各前提にファイルと行番号を付けてください。別のコードベースや以前の設計から数値を引き継いだデフォルトは、対象の規模（比較対象の値と、それをスケーリングする修正値）に照らして確認し、選択肢には比較内容を示してください（「6 以上のヒット。ここでのヒットは 3～6」）。これらの回答をもとに作成した用語集、仕様書、ADRをレビューするたびに新たな事実誤認が一つ見つかる場合は、レビューを止め、設計がたどるコードパスを読む事実確認を一度行ってください。進行中の調査が妨げるのは、それに依存する質問だけです。調査中も、残りの未解決事項については確認を続けてください。調査中は主張も制限されます。調査結果が返るまでは、返ってきた情報だけを述べ、未調査のシステムについての推論には推測であることを明記してください。

方向性に関する意思決定（何を、誰のために、何から始めるか）はユーザーが行います。それぞれについてユーザーに尋ね、推奨がどれほど明白に見えても、回答を待ってください。

_デフォルト_は、妥当な根拠のある実装上の選択です。ユーザーが詳しく読まなくても受け入れるであろう推奨を指します。それぞれを一行で述べ、そのまま先に進み、ユーザーが異議を唱えられるようにしてください。試作するかどうかを尋ねる前に、作業の土台となる既存の成果物（ダッシュボード、スクリプト、モックなど）が設計上の疑問にすでに答えていないか確認してください。答えているなら、その成果物が試作品です。

計画がステークホルダーのドキュメントに記された作業の順序に従っている場合は、まずその順序に異議を唱えてください。ドキュメントの中心的な主張を一文で示し、各作業項目を、その主張をどれだけ直接実現するかに応じて順位付けしてください。「着手可能」は、同順位の場合にのみ優先順位を決める基準です。

完了

未解決事項がなくなり、すべての分岐を確認して暗黙の前提が何も残っていないとき、セッションは完了です。そのうえで、確定した意思決定と明示したデフォルトを列挙し、その一覧が共通認識と合っているかユーザーに確認してください。ユーザーが確認するまでは、それに基づいて行動してはいけません。