gsd-discuss-phase

後続エージェントが必要とする実装上の決定事項を抽出します。調査担当と計画担当は、何を調べるべきか、どの選択が確定しているかを CONTEXT.md で確認します。

仕組み：

1. フェーズを分析し、曖昧な点（UI、UX、動作など）を特定します
2. 曖昧な点を提示し、ユーザーが話し合う項目を選択します
3. 選択された各項目について、納得できるまで掘り下げます
4. 調査と計画の指針となる決定事項を記載した CONTEXT.md を作成します

出力： {phase_num}-CONTEXT.md — 後続エージェントがユーザーに再確認せず作業できるほど明確な決定事項

<execution_context> @{{PLATFORM_ROOT}}/get-shit-done/workflows/discuss-phase.md @{{PLATFORM_ROOT}}/get-shit-done/templates/context.md </execution_context>

フェーズ番号：$ARGUMENTS（必須）

コンテキストファイルは、init phase-op とロードマップ／状態ツールの呼び出しを使って、ワークフロー内で解決されます。

1. フェーズ番号を検証します（未指定、またはロードマップに存在しない場合はエラー） 2. CONTEXT.md が存在するか確認します（存在する場合は、更新／表示／スキップを提示） 3. **フェーズを分析** — 分野を特定し、フェーズ固有の曖昧な点を生成します 4. **曖昧な点を提示** — 複数選択で、話し合う項目を選んでもらいます（スキップ不可） 5. **各項目を掘り下げる** — 項目ごとに4つの質問を行い、その後、さらに質問するか次に進むかを提示します 6. **CONTEXT.md を作成** — 話し合った項目に合わせたセクションを設けます 7. 次のステップ（調査または計画）を提示します

重要：スコープのガードレール

• ROADMAP.md で定められたフェーズの範囲は固定です
• 話し合いでは実装方法を明確にします。追加するかどうかは扱いません
• ユーザーが新しい機能を提案した場合：「それは別のフェーズとして扱います。後で検討できるよう記録します。」
• 後回しにするアイデアを記録します。失わず、実行にも移しません

分野に応じた曖昧な点： 曖昧な点は、何を作るかによって異なります。フェーズの目標を分析してください。

• ユーザーが見るもの → レイアウト、情報密度、インタラクション、状態
• ユーザーが呼び出すもの → 応答、エラー、認証、バージョン管理
• ユーザーが実行するもの → 出力形式、フラグ、モード、エラー処理
• ユーザーが読むもの → 構成、トーン、詳細度、流れ
• 整理するもの → 基準、グループ分け、命名、例外

汎用的な分類ではなく、フェーズ固有の曖昧な点を3〜4個生成します。

掘り下げの深さ：

• 確認する前に、項目ごとに4つ質問します
• 「[項目]についてさらに質問しますか、それとも次に進みますか？」
• さらに質問する場合 → 4つ追加で質問し、再度確認します
• すべての項目が終わったら → 「コンテキストを作成してよいですか？」

質問しない項目（Claude が対応します）：

• 技術的な実装
• アーキテクチャの選択
• パフォーマンス上の懸念
• スコープの拡大

<success_criteria>

• 賢明な分析によって曖昧な点が特定されている
• ユーザーが話し合う項目を選んでいる
• 選択された各項目が、ユーザーの納得がいくまで掘り下げられている
• スコープの拡大につながる提案が、後回しにするアイデアとして整理されている
• CONTEXT.md に曖昧なビジョンではなく決定事項が記録されている
• ユーザーが次のステップを把握している </success_criteria>