不明確な場合は質問する

目的

間違った作業を避けるために必要最小限の明確化質問を行い、必須質問に回答が得られるか、ユーザーが明示的に仮定での進行を承認するまで実装を開始しません。

ワークフロー

1) リクエストが不明確かどうか判断する

以下の項目の一部またはすべてが明確でない場合、リクエストを不明確なものとして扱います:

• 目的を定義する(何が変わるべきか、何が同じままであるべきか)
• 「完了」を定義する(受け入れ基準、例、エッジケース)
• スコープを定義する(対象内/外のファイル/コンポーネント/ユーザー)
• 制約を定義する(互換性、パフォーマンス、スタイル、依存関係、時間)
• 環境を特定する(言語/ランタイムバージョン、OS、ビルド/テストランナー)
• 安全性/可逆性を明確にする(データ移行、ロールアウト/ロールバック、リスク)

複数の妥当な解釈が存在する場合は、不明確なものと想定します。

2) 必須質問を最初に聞く(最小限に)

最初のパスで1〜5個の質問を行います。作業全体を排除できる質問を優先します。

質問を答えやすくします:

• スキャンしやすさを最適化する(短い番号付き質問、段落は避ける)
• 可能な限り複数選択肢オプションを提供する
• 適切な場合は合理的なデフォルトを提案します(デフォルト/推奨選択肢として明確にマーク; リスト内で推奨選択肢を太字にするか、コードブロックでオプションを提示する場合はブロックの直上に太字の「推奨」行を配置し、ブロック内のデフォルトもタグ付けします)
• 高速パス応答を含める(例:defaults ですべての推奨/デフォルト選択肢を受け入れる)
• 役に立つ場合は低摩擦の「不明」オプションを含める(例:「Not sure - use default」)
• 摩擦を減らせる場合は「知る必要がある」と「知るとよい」を分ける
• 選択肢を正当化する(例:特定のオプションが推奨される理由を平文で説明)
• ユーザーがコンパクトな決定で応答できるようにオプションを構成します(例:1b 2a 3c); 選択したオプションを平文で再度述べて確認します

3) 行動する前に一時停止

必須回答が得られるまで:

• コマンド実行、ファイル編集、未知の要素に依存する詳細な計画を生成しない
• 方向を確定しない明確にラベル付けされた低リスク調査ステップのみ実行します(例:リポジトリ構造の検査、関連設定ファイルの読み取り)

ユーザーが回答なしで進行を明示的に求める場合:

• 短い番号付きリストとして仮定を述べる
• 確認を求め、確認または修正後のみ進行します

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

回答が得られたら、要件を1〜3文で再度述べます(主な制約と成功の定義を含む)。その後、作業を開始します。

質問テンプレート

• 「開始する前に必要な情報:(1) ...、(2) ...、(3) ....。(2) が気にならない場合は ... と仮定します。」
• 「これらのどちらにすべきですか? A) ... B) ... C) ...(1つ選択)」
• 「『完了』とは何と考えますか?例えば:...」
• 「従うべき制約(バージョン、パフォーマンス、スタイル、依存関係)はありますか?なければ、既存プロジェクトのデフォルトをターゲットにします。」
• 番号付き質問と文字付きオプション、明確な応答形式を使用します

1) スコープ?
a) 最小限の変更(デフォルト)
b) 該当領域を編集しながらリファクタリング
c) 不明 - デフォルトを使用
2) 互換性ターゲット?
a) 現在のプロジェクトデフォルト(デフォルト)
b) より古いバージョンもサポート:<指定>
c) 不明 - デフォルトを使用

応答: defaults (または 1a 2a)

アンチパターン

• クイック低リスク調査読み取りで答えられる質問をしない(例:設定、既存パターン、ドキュメント)。
• 厳密な複数選択またはイエス/ノーで曖昧さを素早く排除できる場合は、オープンエンドの質問をしない