不十分な場合は質問を提示する

目的

間違った作業を避けるために必要な最小限の明確化質問を提示し、必須の質問に答えられるまで (またはユーザーが明示的に述べられた前提で進行することを承認するまで) 実装を開始しません。

ワークフロー

1) リクエストが不十分かどうかを判断する

作業方法を検討した後、以下の点の一部またはすべてが不明確な場合、リクエストを不十分として扱います:

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

複数の解釈が可能な場合は、不十分であると想定します。

2) 最初に必須質問をする (小規模に保つ)

最初のパスで1-5個の質問をします。作業の全体的なブランチを除外する質問を優先します。

question ツールを使用して構造化された選択肢を提示します:

• 明確なラベル付きの複数選択肢を提示する
• 推奨デフォルトをラベルに「(推奨)」でマークする
• ユーザーが複数のオプションを選択できる場合は multiple: true を使用する
• ユーザーはカスタム入力のため常に「その他」を選択できます

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

必須の回答が来るまで:

• コマンドを実行したり、ファイルを編集したり、不明な点に依存する詳細な計画を立てたりしないでください
• 方向性を確定しない明確にラベルされた低リスクな調査ステップ (例: リポジトリ構造の検査、関連する設定ファイルの読み取り) のみを実行してください

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

• あなたの前提を短い番号付きリストとして述べます
• 確認を求めます。確認または修正した後にのみ進行します

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

回答を得たら、要件を1-3文で言い換えます (主要な制約と成功がどのようなものかを含めて)、その後作業を開始します。

アンチパターン

• 簡単で低リスクな調査読みで答えられる質問をしないでください (例: 設定、既存のパターン、ドキュメント)。
• 厳密な複数選択またはyes/noが曖昧性をより迅速に除外できる場合は、オープンエンドの質問をしないでください。