idea-to-plan

アイデアから計画へ

曖昧な依頼を、（1）1段落の問題提起、（2）範囲を定めた仕様書、（3）段階的な実装計画に変換します。それぞれの段階でユーザーに提示し、承認を得てから次に進みます。曖昧なプロンプトから、いきなりコードに進んではいけません。

使用するタイミング

• 依頼が仕様ではなく目標である場合（「ダッシュボードを作る」「認証を追加する」など）。
• 要件、制約、成功基準が不足している、または暗黙のものになっている場合。
• 何かを作る価値があるか、ユーザーが検討している場合。

仕様が十分に明確なタスク、再現手順が明確なバグ修正、機械的な変更には使用しないでください。これらはそのまま実装に進みます。

手順

1. 問題を言い換える（質問する前に）

誰がどのような問題を抱えていて、なぜ今なのか、何をもって「解決」とするのかを、1段落で書きます。ユーザーに提示してください。書けない場合は、依頼を理解できていません。そのギャップが最初に尋ねるべき質問です。

2. 意思決定を変える質問だけをする

回答によって設計が変わる質問を3〜6個まとめて尋ねます。安全な既定値があるものは省略し、既定値を明示して先に進みます。質問する内容の例：

• スコープの境界（明確に対象外とするもの）
• 厳しい制約（技術スタック、期限、データ、コンプライアンス）
• 成功基準（どうすれば機能していると判断できるか）
• 間違っていた場合に最も手戻りが大きくなる前提を1つ

3. 仕様書を書く

## Problem
## Goals / Non-goals
## Constraints
## Approach (1–3 sentences)
## Open questions

1画面以内に収めます。提示し、計画を立てる前に目標／対象外について明示的な「はい」を得てください。

4. 段階的な計画を書く

それぞれに検証可能な成果物があるフェーズに分けます。

Phase 1: <smallest end-to-end slice that proves the approach> — verify by <X>
Phase 2: ...

各フェーズには、具体的な成果物、変更するファイルや領域、検証方法を記載します。依存関係と最もリスクの高いフェーズを明示し、リスクの高い作業を前倒しします。

5. 引き継ぐ

仕様書と計画を最終成果物として出力します。最初に着手するフェーズを推奨したら、そこで止めてください。実装は別のステップであり、ユーザーが開始を指示します。

品質基準

• 問題提起は1段落に収め、実在するユーザーを明示します。
• 対象外を明確にします（対象外のない仕様書では範囲が定まりません）。
• すべてのフェーズを個別に検証できます。
• 明らかな既定値がある質問をしません。
• 仕様書の承認前にコードを書きません。

アンチパターン

• 設計を決めるのに4つの質問で足りるところを、15個も質問する。
• 検証可能な成果がない「フェーズ1：プロジェクトをセットアップする」。
• ユーザーのプロンプトを仕様書であるかのように言い換える。
• 最初の一歩について合意する前に、豪華すぎるバージョンを設計する。