ask-questions-if-underspecified

仕様が不明確な場合は質問する

使用するタイミング

リクエストに複数の妥当な解釈がある場合や、重要な詳細（目的、範囲、制約、環境、安全性）が不明確な場合に、このスキルを使用します。

使用しないタイミング

リクエストがすでに明確な場合、または手早く低リスクな調査を行えば不足している詳細を把握できる場合は、このスキルを使用しないでください。

目標

誤った作業を避けるために必要な最小限の確認質問を行います。必須の質問に回答が得られるまで（またはユーザーが明示した前提で進めることを承認するまで）、実装を開始しないでください。

ワークフロー

1）リクエストの仕様が不明確かどうかを判断する

作業の進め方を調べた後も、次のいずれか、またはすべてが不明確な場合、リクエストの仕様は不明確だと判断します。

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

複数の妥当な解釈がある場合は、仕様が不明確だと判断します。

2）必須の質問を先にする（少数に絞る）

最初の質問は1～5個にします。作業の進め方を大きく分ける選択肢を絞り込める質問を優先します。

回答しやすい質問にします。

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

3）作業に着手する前に待つ

必須の質問への回答が届くまで、次のことを行わないでください。

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

ユーザーが回答なしでの続行を明示的に求めた場合：

• 前提を短い番号付きリストで示します
• 確認を求め、ユーザーが承認するか修正するまで作業を進めません

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

回答が得られたら、要件（重要な制約と、成功とみなす条件を含む）を1～3文で言い換えて確認してから、作業を開始します。

質問のテンプレート

• 「着手する前に確認したい点があります。（1）…、（2）…、（3）…。なお、（2）について特に希望がなければ、…と想定します」
• 「次のどれにしますか？ A）… B）… C）…（1つ選択）」
• 「何をもって『完了』としますか？ 例：…」
• 「守るべき制約（バージョン、パフォーマンス、スタイル、依存関係）はありますか？ なければ、既存プロジェクトのデフォルトを適用します」
• 番号付きの質問、アルファベット付きの選択肢、明確な回答形式を使用します

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)

アンチパターン

• 手早く低リスクな調査（例：設定、既存のパターン、ドキュメントの確認）で把握できることを質問しないでください。
• 曖昧さをより効率よく解消できる、簡潔な選択式やはい／いいえの質問がある場合は、自由回答形式の質問を避けてください。