ask-questions-if-underspecified

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

要件が不明確な場合は質問するスキル — 要件が曖昧であったり、重要な詳細が不足していたりする場合は、実装に着手する前に必要最小限の確認質問をします - 正しい実装を妨げる曖昧な要件や不足している要件を特定します - 具体的な最善の推定デフォルトを添えて、実用最小限の確認質問を作成します - 範囲や制約に関する質問（質問する）と、実装詳細の判断（自分で決める）を区別します - 回答を待つ間も提示したデフォルトで作業を進め、並行作業を滞らせません

ステップ 1：要件の不明確さを評価する

不明確、または不足している要素を特定します。

• 範囲：具体的に何を含め、何を除外しますか？
• 制約：パフォーマンス目標、プラットフォーム要件、セキュリティルールはありますか？
• 受け入れ基準：ユーザーはどのように成功を判断しますか？
• 優先順位：選択肢が競合する場合、どれを優先しますか？

既存のコードや慣例を確認すれば判断できることは質問しないでください。

ステップ 2：質問を選別する

候補となる各質問を分類します。

種類	質問するか、判断するか
範囲の境界（何を含めるか）	質問する
非機能要件（パフォーマンス／セキュリティ目標）	質問する
受け入れ基準	質問する
実装方法	自分で決める
コードスタイル／命名規則	自分で決める（既存のパターンに従う）
あれば望ましい仕上げ	自分で決める（妥当なデフォルトで進める）

ステップ 3：簡潔に質問する（最大 3 問）

ブロッキングとなる質問ごとに、次のようにします。

1. 想定する内容（最善の推定デフォルト）を伝えます
2. 具体的な質問を 1 文で尋ねます
3. 該当する場合は、具体的な選択肢を 2～3 個提示します

形式：

I'll [proceed with X default assumption]. Quick questions before I start:
1. [Specific question]? (default: [assumption])
2. [Specific question]? (default: [assumption])

</execution_process>

<best_practices>

1. すべての質問にデフォルトを添える：最善の推定を必ず示し、ユーザーが一から考えずに確認できるようにします
2. 実装方法ではなく、成果について質問する：「オフラインでの利用に対応する必要がありますか？」と尋ね、「IndexedDB と localStorage のどちらを使いますか？」とは尋ねません
3. 質問する前にコードベースを確認する：既存のパターンで曖昧さが解消されることは多いため、確認してから質問します
4. 質問を 1 回のメッセージにまとめる：1 つ質問して回答を待ち、その後で次の質問をすることは避けます

</best_practices>

**例 — 要件が不明確な機能リクエスト：**

ユーザー：「ダッシュボードに検索機能を追加して」

良い回答：

I'll implement client-side search with debouncing and case-insensitive matching. Quick questions before I start:
1. Should search cover all columns or just the name/title column? (default: name/title only)
2. Should results filter in place or open in a new panel? (default: filter in place)

悪い回答：

Before I start, I need to know:
1. What search algorithm should I use?
2. Should it be case sensitive?
3. What debounce delay?
4. Should I use a library?
5. How many results to show?

</usage_example>

絶対原則

1. 一度に 3 問を超えて質問しないでください — 3 問を超えると判断に迷う原因になります。質問を厳選し、それ以外は自分で判断してください。
2. すべての質問に必ず最善の推定デフォルトを添えてください — デフォルトのない質問ではユーザーが一から考える必要があります。デフォルトがあれば、一言で確認できます。
3. 自分で判断できる実装の詳細について質問しないでください — アルゴリズムの選択、コードの構成、命名規則、ライブラリの選定はユーザーではなく、あなたが決めることです。
4. あれば望ましい要件を理由に決して作業を止めないでください — 本当に作業を止める要件と、妥当なデフォルトで決められる要件を見極め、前提を示してデフォルトで進めてください。
5. 質問する前に必ず既存のコードを読んでください — 既存のパターン、慣例、関連コードを確認してください。既存コードを確認すれば、見かけ上の曖昧さの大半は解消されます。

アンチパターン

アンチパターン	失敗する理由	正しいアプローチ
作業を始める前に5つ以上質問する	ユーザーを立ち往生させ、尋問されているように感じさせます	優先順位を付け、作業を妨げる質問は最大3つに絞り、残りは判断します
実装方法について質問する	それはエージェントの役割であり、ユーザーの役割ではありません	スコープ、制約、受け入れ条件についてのみ質問します
デフォルト値を示さずに質問する	ユーザーはゼロから考える必要があり、フィードバックサイクルが遅くなります	必ず「デフォルト：X — これでよいですか？」と伝えます
1つずつ順番に質問する	ゆっくりとしたやり取りの連鎖が生まれます	すべての質問を1つのメッセージにまとめます
コードベースを見れば分かることを質問する	調査が不十分だと思われます	質問する前に既存の規約を確認します

メモリプロトコル（必須）

開始前：

cat .claude/context/memory/learnings.md

完了後：

• 新しいパターン -> .claude/context/memory/learnings.md
• 発見した問題 -> .claude/context/memory/issues.md
• 決定事項 -> .claude/context/memory/decisions.md

中断を想定してください。コンテキストがリセットされる場合があります。メモリに記録されていなければ、起きていないのと同じです。