ask-questions

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

目標

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

ワークフロー

1) 依頼の仕様が不明確かどうかを判断する

作業の進め方を検討した後も、次の項目の一部またはすべてが不明確な場合、その依頼の仕様は不明確だと判断してください。

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

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

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

最初の確認では、質問を1～5個にしてください。作業の大きな分岐を解消できる質問を優先してください。

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

• ぱっと見て答えやすい形式にする（短く、番号付きにする。段落は避ける）
• 可能であれば選択肢を提示する
• 適切な場合は妥当なデフォルトを提案する（デフォルト／推奨であることを明記し、選択肢では推奨案を太字にする。コードブロックで選択肢を示す場合は、その直前の行に「Recommended」を太字で記載し、コードブロック内でもデフォルトを明記する）
• すぐに回答できる方法を用意する（例：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)

避けるべきこと

• 簡単かつ低リスクな調査（例：設定、既存のパターン、ドキュメントの確認）で答えられる質問はしないでください。
• 曖昧さをより迅速に解消できる選択式やはい／いいえ形式の質問がある場合は、自由回答式の質問をしないでください。