plan-hearing

Plan Hearing Guide

Plan mode時に最小限の質問で要件を明確化し、堅牢なプランを構築するためのガイド。

基本原則

1. 質問前に分析: まずコードベースと文脈を読み、不明点を特定する
2. 最小限の質問: 1-5個の質問に絞る。全てのフェーズを必ず実施する必要はない
3. 回答まで待機: 質問への回答を得るまで、ファイル編集やコマンド実行は控える（読み取り・探索のみ可）
4. 解釈を確認: 回答を得たら、理解した内容を再述して確認する
5. 決定事項を記録: 重要な決定はプランに明記する

ヒアリングワークフロー

Step 1: 文脈分析（質問前に必須）

質問を作成する前に、以下を確認する：

• 関連するコードを読む（Glob, Grep, Read）
• 既存のパターンや規約を把握する
• 本当に確認が必要な不明点を特定する

確認すべき不明点の例:
- スコープ: どこまでやるか、どこからやらないか
- 制約条件: 時間、技術、互換性などの制限
- 完了条件: 何をもって完了とするか
- エッジケース: 境界条件や例外的なケース
- 優先度: 複数の要件がある場合の優先順位

Step 2: 最小限の質問を作成

質問数は1-5個に抑える。タスクが明確な場合は質問をスキップしてもよい。

質問カテゴリ（必要なものだけ選択）

Step 3: 質問の構造化

AskUserQuestionの使い方

効果的な選択肢の設計

{
  "question": "変更のスコープはどこまでにしますか？",
  "header": "スコープ",
  "options": [
    {
      "label": "最小限の変更 (推奨)",
      "description": "指定された問題のみ修正。副作用なし"
    },
    {
      "label": "関連箇所も改善",
      "description": "周辺コードの小さな改善も含める"
    },
    {
      "label": "リファクタリング込み",
      "description": "構造的な改善も行う。時間がかかる"
    }
  ],
  "multiSelect": false
}

Step 4: 回答を得たら解釈を確認

回答を受け取ったら、実装前に理解を再述する：

確認させてください：

- スコープ: ○○のみ対象、△△は対象外
- 技術: □□アプローチを採用
- 制約: ××との互換性を維持

この理解で正しいですか？

Step 5: 決定事項をプランに記録

ExitPlanMode時のプランに、ヒアリングで確定した内容を含める：

## 確定事項
- スコープ: ...
- 技術選択: ...
- 制約条件: ...

質問例テンプレート

シンプルなバグ修正の場合（1-2問）

{
  "questions": [
    {
      "question": "この修正のスコープはどこまでにしますか？",
      "header": "スコープ",
      "options": [
        {
          "label": "報告された問題のみ (推奨)",
          "description": "最小限の変更でリスクを抑える"
        },
        {
          "label": "関連する類似問題も含める",
          "description": "同じ原因の問題を一括修正"
        }
      ],
      "multiSelect": false
    }
  ]
}

新機能追加の場合（2-4問）

{
  "questions": [
    {
      "question": "この機能の優先度はどれですか？",
      "header": "スコープ",
      "options": [
        {
          "label": "MVP (推奨)",
          "description": "最小限の機能で素早くリリース"
        },
        { "label": "フル機能", "description": "すべての要件を実装" }
      ],
      "multiSelect": false
    },
    {
      "question": "どの技術アプローチを使用しますか？",
      "header": "技術選択",
      "options": [
        {
          "label": "既存パターンに従う (推奨)",
          "description": "学習コストなし、一貫性維持"
        },
        {
          "label": "新しいパターンを導入",
          "description": "より良い設計だが変更範囲が広い"
        }
      ],
      "multiSelect": false
    },
    {
      "question": "テストの範囲はどうしますか？",
      "header": "テスト",
      "options": [
        {
          "label": "ユニットテストのみ (推奨)",
          "description": "主要なロジックをカバー"
        },
        {
          "label": "E2Eテストも含める",
          "description": "より包括的だが時間がかかる"
        }
      ],
      "multiSelect": false
    }
  ]
}

アンチパターン

避けるべきこと

質問が不要なケース

以下の場合は質問をスキップしてよい：

• タスクが明確で具体的（「○○ファイルの△△行を修正」）
• ユーザーが詳細な仕様を既に提供している
• 単純な調査・情報提供のリクエスト
• 既存パターンに従うことが自明

このような場合は、確認のために簡潔に理解を述べてから進める：

理解しました。○○を△△に変更します。他に考慮すべき点があればお知らせください。