fstack-plan

/fstack-plan

確認済みの理解を、短い文書化された計画に変換します。ユーザーは、実装が始まる前にそれを承認します。

使用するタイミング

• /fstack-nail がサマリーを確認した後。
• ユーザーが計画を求め、アイデアがすでに明確な場合。
• まだ計画がないため、/fstack がここにルーティングした場合。

手順

1. /fstack-nail が確認済みのサマリーを生成した場合は、それを計画の基礎として使用します。新しい証拠がそれと矛盾しない限り、決着済みの論点を再び開かないでください。
2. プロジェクトルートに PLAN.md を作成または更新します。
3. 正確に 4 つのセクションを使用します（下記参照）。それ以外の見出しは使用しません。
4. 計画をユーザーに提示します。
5. 停止して承認を求めます。承認されるまで実装しないでください。
6. いずれかのステップが大きすぎると感じたら、分割するか削除します。サブステップをネストしないでください。

PLAN.md のフォーマット

何をするか

2～4 文。平易な言葉で。何を、なぜ。

ステップ

番号付きリスト。最大 7 ステップ。各ステップは、一度に完了して検証できる程度に小さくします。

何をしないか

必須。決して空にしないでください。スコープ外となる誘惑的な追加要素を列挙します。

うまくいったかどうかをどうやって知るか

1～3 の平易な確認。実際に試せること、たとえば「スイッチを切り替えて、更新すると、テーマが保持される」など。

やってはいけないこと

• 1 ページを超えないこと。長くなる場合は、タスクを複数の計画に分割します。
• 4 つのセクション以外の見出しを追加しないこと。
• 実装を開始しないこと。計画は承認で終わります。

「何をしないか」の例

何をしないか

• ライト/ダーク以外のテーマカスタマイズは行わない
• ページごとのテーマ上書きは行わない
• 設定ページは作らない — ヘッダーのトグルのみ

やり取りの例

エージェント: （PLAN.md を作成して提示する）

「これが計画です。4 つのセクションがあります。何をするか、ステップ、何をしないか、うまくいったかどうかをどうやって知るかです。私が実装する前にこれを承認しますか？」

ユーザー: 「承認します。」

エージェント: （停止する。ユーザーは次に /fstack-build を呼び出せます。）