ask-questions-if-underspecified

要件が不明確な場合は質問する

目標

誤った作業を避けるために必要最小限の確認質問をしてください。必須の質問への回答があるまで、またはユーザーが提示した前提での作業開始を明示的に承認するまで、実装を始めないでください。

ワークフロー

1) 要件が不明確かどうかを判断する

作業の進め方を検討した後も、以下のいずれか、またはすべてが明確でない場合は、要件が不明確だと判断してください。

• 目的の定義（何を変更し、何を維持するか）
• 完了の定義（受け入れ基準、例、エッジケース）
• 対象範囲の定義（対象に含める／含めないファイル、コンポーネント、ユーザー）
• 制約の定義（互換性、パフォーマンス、スタイル、依存関係、時間）
• 環境の特定（言語／ランタイムのバージョン、OS、ビルド／テストランナー）
• 安全性／可逆性の確認（データ移行、ロールアウト／ロールバック、リスク）

複数の妥当な解釈がある場合は、要件が不明確だと判断してください。

2) 必須の質問を先に尋ねる（数は少なく）

最初の段階では、1～5個の質問をしてください。作業の進め方を大きく左右する選択肢を絞り込める質問を優先してください。

回答しやすい質問にしてください。

• 一目で確認できるようにする（短く番号を付け、段落は避ける）
• 可能であれば複数選択式にする
• 適切な場合は妥当なデフォルトを提案する（デフォルト／推奨であることを明示し、リストでは推奨案を太字にするか、コードブロックで選択肢を提示する場合は、その直前に「推奨」を太字で記し、コードブロック内でもデフォルトを示してください）
• 手早く回答できる方法を示す（例：すべての推奨案に同意する場合は defaults と返信）
• 役立つ場合は、負担の少ない「わからない」という選択肢を用意する（例：「わからない場合はデフォルトを使用」）
• 作業の負担を減らせる場合は、「必須」と「任意」を分ける
• 簡潔に選択肢を回答できる形式にする（例：1b 2a 3c）。選択された項目を平易な言葉で言い換えて確認する

1) Scope?
a) Minimal change (default)
b) Refactor while touching the area
c) Not sure - use default
2) Compatibility target?
a) Current project defaults (default)
b) Also support older versions: <specify>
c) Not sure - use default

Reply with: defaults (or 1a 2a)

3) 作業を始める前に待つ

必須の回答が届くまで、以下を行わないでください。

• コマンドの実行、ファイルの編集、不明点に依存する詳細な計画の提示
• 作業の方向性を決めつけない、明確にラベル付けされた低リスクの調査ステップのみ実行しても構いません（例：リポジトリの構成を調べる、関連する設定ファイルを読む）

ユーザーが回答を待たずに進めるよう明示的に依頼した場合：

• 前提を簡潔な番号付きリストで提示する
• 確認または修正を依頼し、確認を受けてから作業を進める

4) 解釈を確認してから進める

回答を受け取ったら、要件を1～3文で言い換えて確認してください（重要な制約と、成功の基準を含めます）。その後、作業を開始してください。

質問のテンプレート

• 「開始する前に、次の点を確認する必要があります。（1）…、（2）…、（3）…。 （2）を特に指定しない場合は、…を前提とします。」
• 「どれがよいですか？ A）… B）… C）…（1つ選んでください）」
• 「何をもって完了としますか？ 例：…」
• 「遵守すべき制約（バージョン、パフォーマンス、スタイル、依存関係）はありますか？ なければ、既存プロジェクトのデフォルト設定に従います。」
• 番号付きの質問にアルファベット付きの選択肢を添え、明確な回答形式を示す

アンチパターン

• すぐに確認できる低リスクの調査（例：設定ファイル、既存のパターン、ドキュメント）で判明することを質問しないでください。
• 曖昧な自由回答式の質問は避けてください。選択式やはい／いいえで、より迅速に曖昧さを解消できないか検討してください。

---

@thsottiaux によって最初に作成されました