atelier-grill-me

徹底的に問い詰める

計画や設計を、真に共通理解が得られるまでユーザーに質問して検証します。意思決定ツリーの重要な分岐をすべて解決し、それらの判断の依存関係を順序どおりに確定します。目的は、ただ問い詰めることではありません。実装中や本番環境で問題になる前に、想定、エッジケース、分岐点を洗い出すことです。

これは「コードを書く前に考える」に対する、必要に応じて発動する、妥協のない対応策です。その習慣では必要に応じて確認しますが、このスキルではコードを1行でも書く前に、ツリー全体をたどることを徹底します。

やり取りとエージェントとしての規律：メインのアトリエスキルの「Interaction」セクションに従います（簡潔に、最初に答えを示し、emダッシュを使わず、各質問では推奨案を先に示し、インタビューの終了時に次のステップを提示します）。コミットとテストに関する2つのゲート（ルール24～25）も適用します。1ラウンドの上限はここでは適用されません。複数ラウンドの質問こそ、このスキルが認める目的です。

使用する場面

• ユーザーから、徹底的に質問してほしい、または計画や設計をストレステスト／厳しく検証してほしいと頼まれた場合。
• 判断の結果が重大で、誤った決定を覆すコストが高い場合。たとえば、アーキテクチャ、データモデル、公開 API の形、移行、依存関係の選択、セキュリティ境界などです。
• 新しい製品や機能の計画の場合：作り方を厳しく検討する前に、そもそも作るべきかを検討します（アトリエの references/product.md § 作る前に検証する）。その問題があることを示す証拠は、チーム内以外に何がありますか？ 実装に着手する前に需要を検証する最も低コストな方法（ランディングページやコンシェルジュ形式での試行など）は何ですか？ 「やめる」と言えるようにする、日付入りの実施／中止基準は何ですか？ リリース後に継続するか中止するかを決める導入の基準値は何ですか？ インタビューにかかるコストでアイデアを中止できることは、このスキルにとって最良の結果です。
• 計画が曖昧、広範、または未表明の分岐を多く含んでいる場合。

質問の厳しさは、重要度に合わせてください。「この変数の名前を変える」といった些細な作業に対する5つの質問はノイズです。取るに足らない作業や、すでに十分に具体化された作業では、徹底的な質問は省いてください。

インタビューの進め方

1. 中立的に整理する。 特定の答えに誘導せず、目標を1、2文で言い換え、掘り下げる前に認識が合っているか確認します。
2. 質問する前に調べる。 コードベースから分かることは自分で確認します。ファイル、設定、既存のパターンを読みます。grep で分かることをユーザーに尋ねてはいけません。ユーザーに調査を頼むのではなく、調査結果を提示します。
3. 一度に質問は1つだけにする。 質問を1つだけして、回答を待ってから次の質問をします。10個の質問を番号付きリストで並べると、相手を圧倒し、回答も表面的になります。
4. 推奨する回答を先に示す。 各質問では、何を選ぶか、その理由を1行で伝え、ユーザーが「はい」と答えるか、修正できるようにします。推奨案のない質問は、作業を相手に戻すだけです。
5. ツリーを深さ優先でたどり、依存関係を順に解決する。 ある判断が他の判断を制約する場合は、先にその判断を確定し、その分岐をたどります。現在の分岐が解決するまで、新しい分岐を開きません。重要な場合は依存関係を明示します（「静的エクスポートを維持するなら、リクエストごとのキャッシュに関する疑問はなくなります」）。
6. 状態を追跡する。 解決済みの判断と未解決の質問を継続的に記録し、長いツリーでも双方が状況を見失わないようにします。
7. 共通理解が得られたら終了する。 重要な分岐がすべて解決し、推測せずに実装できる状態になったら終了です。インタビューの途中で曖昧に終わらせず、完了したことを明確に伝えます。

出力

インタビューの結論がまとまったら、簡潔な意思決定記録を作成してください。目標、各決定とその理由を一行で示し、最初に取り組む具体的な次のステップを記載します。簡潔にまとめてください。これは、実装が従う仕様です。却下した代替案と、記録に残す価値のある撤回手順がある決定は、リポジトリにコミットする ADR（docs/adr/NNNN-title.md、atelier references/governance.md § Decision records）の形式にしてください。構築するかどうかの判断の場合は、明示的な基準を記載した、日付入りの実施／見送りチェックリスト（atelier references/product.md）を記録として作成します。

質問への回答は、最も凝った設計ではなく、質問を経ても成り立つ最もシンプルな設計に導いてください。推奨する回答はすべて、YAGNI と「最もコストの安いコードとは、書かずに済んだコードである」という原則を守る必要があります。

.claude/LESSONS.md に記録を残すリポジトリでは、長く活用できる選択肢を [decision] エントリーとして提案してください（承認後に追記）。次のセッションでリポジトリの方針を再検討せずに済むよう、選択肢を引き継げます。