grilling

Grilling

これは何か： 再利用可能なインタビュープロトコルであり、パイプラインのステージではありません。親の中にネストされている場合（例：brainstorm のステップ 2、establish-project、triage）、その親の会話とチェックリストを続けます。これらのルールを適用し、モードが切り替わったと告げず、自分の項目にチェックが付いた時点で親が完了したと扱わず、以下の Todo に従って親のチェックリストを実行してください。単独で行う場合（親がなく、ユーザーが質問攻めにしてほしいと依頼した場合）は、共通認識ができるまで、インタビュー全体を担当します。

双方が同じ全体像を持つまでインタビューします。負債や誤ったアーキテクチャの選択につながる暗黙の前提をすべて明らかにし、決定します。このスキルのキーワードは、オープンセット、テリトリー、カード、クローズパッケージです。地図（プロンプト、計画、既知の情報）はテリトリー（コードベース、実行時の状態、ユーザー、履歴）ではありません。誤った推測が大きなコストになる前に、質問を重ねてその隔たりを縮めます。

絶対原則 — チャネル

EVERY QUESTION IS INLINE CHAT WITH FULL CONTEXT.
NEVER use AskUserQuestion, structured MCQ pickers, or any harness UI that
truncates labels, option text, or the "why this matters" line.

影響をそぎ落とした、タップしやすい UI は、より速いインタビューではなく、別の、より質の悪いインタビューです。「社内のスタイルでは選択 UI が好まれる」「5 分後にスタンドアップがある」「リードが構造化 UI を使うよう言った」「オプションの説明欄は十分な長さがある」は、例外ではありません。

絶対原則 — オープンセット（固定ラウンドなし）

THERE IS NO FIXED ROUND COUNT.
NEVER "Question k of N", "last of 5", or "we budgeted four cards".
Stop only when the open set is empty of judgment calls that change
architecture, data, auth/security, UX flow, or implementation scope.

オープンセット＝未決定のまま残っている、影響範囲の大きい未知事項 ＋ 直前の回答によって明らかになった分岐 ＋ まだユーザーの確定が必要な、親が把握している未知事項。

基本ルール： 回答のたびにオープンセットを再計算し、次のカードに進むか、クローズパッケージに進みます。「再計算」に関するそれ以外の記述も、ここを指します。

あらかじめ列挙した決定事項のリストは、生きた地図であり、ノルマではありません。分岐が生じたら追加し、解決したら削除します。影響範囲の大きな項目が残っているのに、元のリストが終わったからといって締めくくらないでください。時間、スタンドアップ、ベテランによる「何件かで切り上げよう」という指示、疲労によって変わるのは、進捗をいつ報告するかであり、明示されていない決定事項があるかどうかではありません。

開始時の地図（最初のカードの前）

親の Knowns インベントリ、Blindspot リスト、スキャンダイジェストがあれば読み込みます（例：.skills/*-knowns.md、.skills/*-scan.md）。その後、通常のチャットで短い思考パートナー用の地図を1つ提示します。質問カードでも、複数の質問をまとめて提示するものでもありません。

1. 確定事項 — 固定事項として扱うもの（基本姿勢、明示された譲れない条件、ダイジェストの事実）。
2. 影響範囲の大きい未決事項 — 最初に検討する予定の判断の分岐（名前のみ。まだ選択肢は提示しません）。
3. 未知事項を解決する方法 — 判断が必要な場合はカードを使い、ユーザーが実物を見ないと判断できない場合や、答えが事実である場合は参照情報または prototype／research を使います。盲点によって実質的な選択が妨げられている場合は、説明してから質問します。

地図に誤りがある場合に限り、訂正を促します（「確定事項が誤っていたら止めてください」）。その後、最初のカードに進みます。親がすでにこの地図を示している場合は、再提示を省略し、最初のカードに進みます。

質問カード（毎ターン）

1つのメッセージにつき、決定事項は必ず1つです。通常のチャットでこの形式を出力してください。ツール呼び出しにはしないでください。すべての項目が必須です。時間がないからといって省略するのは、チャネル違反です。

1. 範囲 — 次のいずれかです。ラベルを付けてください：architecture · data · auth/security · UX flow · polish。
2. スレッド — 質問の前に、ユーザーが目を通せる短い行を3つ記載してください。
   • ここまでに確定したこと — この分岐を制約する、すでに決定した事項を1〜3個（または「まだなし」）。
   • 今回のカード — 今決める1つの分岐。
   • 回答後も未確定のこと — この質問に回答した場合に残る、影響範囲の大きい項目名（常に最新の未確定項目を列挙し、「5件中3件」のような表記はしない）。
3. 領域 — リポジトリ、概要、または親の既知情報に基づく事実（パス、ミドルウェア、過去のPR、現在の挙動、注意点など）を記載し、選択肢の意味が分かるだけの情報を示してください。盲点が判断を妨げる場合は、質問の前にここで説明してください（それが何で、このプロダクトでなぜ問題になるのか）。本当に事実が何もない場合は、その旨を伝えてください。捏造してはいけません。確認できる情報をユーザーに思い出させようとしてはいけません。
4. 質問 — 決定事項を平易な言葉で尋ねてください。
5. 重要な理由 — 回答が変わると何が変わるのか（キューと同期処理、スキーマ、権限境界、範囲、手戻りコストなど）を説明してください。ユーザーが追加の質問を受けずに選択できるだけの情報が必要です。このリポジトリまたはプロダクトに即して説明し、「念のための確認です」のような表現は使わないでください。
6. 解消する項目 — このカードで解消する未知の分類：known-unknown · unknown-known · blindspot-confirm。
7. 選択肢（2〜4個） — 短いタイトルと結果の説明（得られること、代償、壊れるもの）を記載してください。ラベルだけでは選択肢になりません。
8. 推奨案 — 推奨する案を最初に示すか、明確に印を付け、ユーザーが簡潔に同意または異議を示せる理由を1行で添えてください。
9. 停止。 回答を待ってください。回答後、未確定項目を再計算し（鉄則 — 未確定項目）、次のカードに進むか、パッケージを締めくくってください。

質問をまとめてはいけません。このカード自体に詳細を記載してください。「希望があれば詳しく説明します」という前置きにしてはいけません。

形式例

**architecture** · export generation locus

Thread
- Locked so far: comment API stays stable; posture = Prototype
- This card: where PDF generation runs
- Still open after: guest export auth · stroke storage · plan quota

Territory
- Export is `POST /api/reviews/:id/export`, session-auth only today.
- Gateway idle timeout is 30s; large reviews with drawings already time out
  similar heavy handlers on the request thread.
- Workers already exist for transcode (`jobs/transcode`); no export job yet.

Where should export generation run?

↳ This decides whether we need a job queue, a ready-notification path, and
  an artifacts bucket — or none of those. Large reviews will blow the 30s
  gateway if we stay on the request thread; picking wrong here rewrites the
  API shape and ops surface mid-build.

Closes: known-unknown

- **Sync in the API request** — simplest; a 400-comment export times out.
- **Background job on the existing queue** (Recommended) — reuses the
  transcode worker patterns; needs a "ready" notification.
- **Client-side only** — zero backend; caps formats and helps support less.

Recommended: background job — export size is unpredictable with drawings.

順序と網羅性

• 影響範囲の大きい項目を優先します。 次に扱う未確定項目のうち、アーキテクチャ、データモデル、公開API、認証・セキュリティ、UXフロー、実装範囲を変え得るものを選んでください。ユーザーが最初に仕上げを求めていても同様です。
• すべての分岐をたどります。 依存関係の順に進み、幹より先に、開いたサブ分岐を処理してください。停止条件は、未確定項目がなくなることです（鉄則 — 未確定項目）。
• 判断はユーザーに委ねます。 事実は「領域」に記載し、人の判断で確定する必要がある分岐だけをカードにしてください。
• プロジェクトの方針に合わせて適切な規模にします。 親から方針が提示されている場合、または docs/agents/project.md に Project posture が記載されている場合は、Prototype · Research · Learning ではデータ移行、後方互換性、非推奨化を省略し、Released · Scaling · Maintenance ではこれらを確認してください。方針がない場合は、すべての分岐をたどってください。方針とチームの規模は別の軸です。
• チーム規模に合わせてパッケージ化します。 ## Team に1人以上のメンバーが記載されている場合、またはワークフローの規模に関する上書き指定がある場合は、そのセクションから規模とパッケージ化の方法を確認してください。Small/Multi では、関連がある場合に限り、担当者やレビュアーを任意で確認します。Solo または Team の記載がない場合、複数人の担当者を割り当てる前提の確認はしません。チームを捏造してはいけません。Team の記載がないことを理由に処理を停止してはいけません。

実装前インタビューマップ

Grilling は、実装前の未知事項への取り組みにおけるインタビューの段階を担当します。その他の段階は、オープンセットの情報源または引き継ぎであり、追加の固定ラウンドではありません。

段階	Grilling が行うこと	再び担当しないこと
Blindspot パス	親の Blindspot を読み込みます。影響範囲が大きい項目は、説明してから質問するカード、または明示的なロックにします。親のリストがなく、知識が浅い場合は、好みを尋ねるカードの前に、要注意事項について短く説明します。	全体スキャン／既知事項の一覧作成（brainstorm のステップ 1）
ブレインストーミング／スコープ	実際の課題が複数サブシステムにまたがるスコープである場合は、親の分解プロセスに差し戻します。	アプローチの選択肢と段階分け（brainstorm のステップ 4～5）
インタビュー	詳細なカードを用います。まず影響範囲の大きい項目から扱います（上記の枠と順序）。	—
リファレンス	最適なリファレンスはソースコードです（フォルダー、モジュール、過去の PR、別の言語によるものも含みます）。セマンティクスを言い直し、採用／適応／却下を確定します。図やスクリーンショットは、より弱い代替手段です。	リファレンスの実装
既知の未知事項	抽象的な好みの掘り下げは行いません。リファレンスをたどるか、親の prototype／research に引き継ぎ、その結果についてカードを 1 枚だけ提示します。	プロトタイプのセッション実施
計画の準備状況	変更可能性の高い領域（データモデル、型インターフェース、ユーザー向けフロー）のパッケージを確定します。	tasks.md の作成（write-plan）

具体的なリファレンスが存在する場合、「適切な感じに作って」は決定ではありません。リファレンスを提示し、セマンティクスを言い直して、採用／適応／却下を確定します。業界標準を勝手に作り上げるのは、事実確認の失敗です。

パッケージの確定（必須）

オープンセットに影響範囲の大きな判断事項が残っていない場合、また親に制御を戻す、または共通認識が得られたと主張する前に、次を提示します。

1. 決定事項の表 — 行の項目は、影響範囲・トピック・決定（ユーザーの言葉）・解消した未知事項の分類です。
2. 制約ブロック — そのまま貼り付けられるロックをまとめます（まずアーキテクチャとデータ、最後に仕上げ）。影響範囲の大きいロックと矛盾する、影響範囲の小さい回答には印を付けます。
3. 変更可能性の高い領域 — 実装時の現実的な制約によって変わる可能性が最も高いロック（データモデル、型インターフェース、UX フロー）です。機械的なリファクタリングは詳細に埋もれさせ、この場で再インタビューしないでください。
4. 明示的な確認 — これが共通認識ですか？このパッケージへの肯定的な回答だけを確認とみなします。

確認に当たらないもの：「ほかに質問はありますか？」「認識は一致しています。表は省略しましょう」「そのまま要件を書いてください」、手続きを省略するよう求める上位者からの圧力、または無回答です。行の修正があった場合は、編集して再確認します。確認によって新たに影響範囲の大きな分岐が生じた場合は、カードに戻ります。

その確認が得られるまで、何も実行しないでください。本番コードの作成、スキャフォールディング、計画の実行は行いません。（用語がインタビューの途中で確定した場合、domain-modeling を通じて用語集／CONTEXT.md を更新することは、副次的な処理として認められます。）

Todo

ネストされている場合：競合する別のリストはありません。親のチェックリスト内で作業し、インタビュー項目はパッケージが確認されるまで進行中のままにします。オープンセットの進捗はその項目の進捗であり、別の進捗管理経路ではありません。

単独で実施する場合：判断領域の随時更新されるオープンセットリストを作成しても構いません。ただし、1 メッセージにつきカードは 1 枚とし、回答のたびに再計算します（鉄則 — オープンセット）。親スキルがすでに進行中の場合、2 つ目の経路を決して開かないでください。

正当化の例

考え方	実際のところ
「社内スタイルガイドに従う／リードから AskUserQuestion を使うよう言われた」	チャネルは鉄則です。インラインカードがインタビューであり、ピッカーでは理由や結果が途中で切り捨てられます。
「5 分後にスタンドアップがあるので、短いラベルだけにする」	省略された意思決定は、明確なカードを 1 枚出すより時間がかかります。時間の制約によって変わるのは報告するタイミングであり、意思決定に必要な内容ではありません。
「選択肢の説明欄に十分な長さがある」	ツールがテキストを制限するなら、それは適切なチャネルではありません。すべてのコンテキストはチャットに記載します。
「AskUserQuestion を使って、コンテキストも貼り付けよう」	チャネルが二重になっています。インラインカードを 1 枚だけ使い、ピッカーは使いません。
「推奨案と一行の理由があれば十分」	各選択肢について Thread、Territory、結果が示されていなければ、ユーザーは分析できず、デフォルトを受け入れることしかできません。
「簡潔さを保つため、Why は一行にする」	追加質問なしで決められるだけの情報量が最低限必要です。文の長さの上限は、情報を薄くしてよいという許可ではありません。
「聞かれたら、後からコンテキストを補足すればよい」	カードそのものが詳細です。後からしかコンテキストを示さないのは、情報不足のカードです。
「TODO の 4 項目が終わったので、ここで終了」	TODO は更新し続けるマップです。未解決の項目がなくなったときが終了であり、あらかじめ決めた N 件が終わったときではありません。
「5 問中 3 問目なので、その後にまとめる」	件数は固定しません。カウントダウン形式は危険信号です。
「ユーザーが最初にボタンの色を尋ねた」	影響範囲を優先する原則は変わりません。アーキテクチャ、データ、認証の分岐を決めた後で、見た目を整えます。
「認識は一致しているので、意思決定の表は省略する」	共通認識とは、パッケージを提示して「はい」を得ることです。表なしで認識が一致したふりをしても、確認にはなりません。
「上級者から要件だけを書くよう言われた」	ユーザーや上級者はプロセスの進め方を変更できますが、明示されていない意思決定を存在することにはできません。パッケージを提示し、「はい」を得ます。
「無難なデフォルトを想定して完了にしよう」	想定は意思決定ではありません。カードを 1 枚出し、待ちます。
「業界のベストプラクティスを選べばよい。妥当な案にしてと言われた」	まず該当領域の参考資料を調べ、内容を言い換えて提示し、ユーザーと合意して確定します。
「上級者から、親の作業を保留して grilling にすぐ切り替えるよう言われた」	ネストすることが、適切な切り替えです。親の作業を保留して grilling のチェックリストを新しく作るのは、チャネルが二重になり混乱を招きます。
「grilling の下に短い意思決定チェックリストを置いても、別のリストにはならない」	それも 2 つ目のリストです。意思決定項目は、親の進行中のインタビュー項目として扱います。
「ユーザーに引き継ぎが伝わるよう、grilling を使うと宣言する」	ネストしている場合、モード切り替えの宣言は不要です。単独で進める場合（親がない場合）は、grilling と一度だけ伝えてもかまいません。

危険信号 — 立ち止まってメッセージを書き直す

• grilling の意思決定に AskUserQuestion や、省略が発生するその他の MCQ ツールを使っている
• 1 つのメッセージでユーザーに向けた疑問符が 2 つ以上ある（選択肢内の確認用の例を除く）
• 選択肢がラベルだけで、結果の説明がない
• Thread、Territory、Why it matters、または Closes が欠けているカード
• 影響の大きい未解決項目があるのに、「全 N 問中の第 k 問」「最終ラウンド」と表現したり、あらかじめ決めた件数が終わったことを理由に終了したりする
• アーキテクチャ、データ、認証の分岐が未解決なのに、見た目の調整から始める
• 意思決定のパッケージを提示せず、「ほかに質問はありますか？」で終了する
• パッケージへの明確な「はい」を得ずに親の作業に戻したり、要件作成を始めたりする
• リポジトリまたは親のスキャン結果の要約にある事実をユーザーに尋ねる
• 参照資料やプロトタイプを使えるのに、まだ情報がない内容について抽象的な好みを尋ねるカードを出す