Plan builder

概要

このスキルは、ユーザーが「何を作りたいか」を起点に、要件定義 → 実装計画 → TODO分解 → 段階的な実装までを伴走する汎用プランナーです。特定のアプリ・言語・フレームワークを前提としません。最初に作りたい機能をざっくり受け取り、その内容に合わせてヒアリングと計画を動的に組み立てます。

全体フロー

1. 作りたい機能を入力してもらう — 最初にユーザーへ作りたい機能を入力してもらい、それを起点にする
2. 動的ヒアリング — 聞いた機能に沿って、必要な要件だけを選択式で質問する
3. 要件の要約と実装計画 — 要件を要約し、段階的な実装計画と成果物を提示する
4. TODOチェックリスト生成 — 実装計画を、確認しやすい小さな単位のTODOに分解する
5. 段階的な実装 — TODOを1つずつ実装し、差分（diff）とウォークスルーを出力。next で次のTODOへ進む

トリガー（推奨）

• キーワード: "plan-builder", "実装計画", "todo 生成", "generate plan"

権限

このスキルの出力は基本的に Markdown（計画・差分・ウォークスルー）です。差分を提案した時点で、自動的にファイルの作成・編集を実施します。 ユーザーは差分内容とウォークスルーで変更を確認してから next で次のTODOに進みます。

例（ユーザーに投げるプロンプト例）

"plan-builder で、◯◯ を作るための実装計画を立てて、1つずつ実装していって下さい。"

---

Step 1: 作りたい機能を入力してもらう（ここから開始）

スキル発動後、最初に必ずユーザーへ「作りたい機能」を入力してもらう ところから始めます。スキルが対象（例: TODOアプリ）を決め打ちすることはありません。ユーザーが自分の言葉で入力した内容を起点に、実装計画を組み立てます。

• 発動直後の最初のアクションとして、ask_user で「どんな機能を作りたいですか？ 自由に説明してください」と尋ねる（allow_freeform: true、自由記述を主とする）
• ユーザーが入力するまで、Step 2 以降（ヒアリング・計画）には進まない
• 入力された機能の説明を、以降のヒアリング・計画の起点（コンテキスト）として保持する
• 受け取った内容を1〜2文で復唱し、「この理解で合っていますか」と認識合わせをする
• 内容が抽象的すぎて計画に落とせない場合のみ、「もう少し具体的に（何を / 誰のために / どんな動き）」と 1回だけ 確認する

Step 2: 動的ヒアリング（選択式・機能に合わせて生成）

Step 1 で受け取った機能をもとに、その機能に必要な質問だけ を動的に組み立ててヒアリングします。固定の質問リストは持ちません。

質問を組み立てるときの観点候補（機能に関係するものだけ選ぶ。すべて聞く必要はない）:

• 目的・解決したい課題
• 中核となる機能 / やらないこと（スコープ）
• 対象ユーザー・利用環境
• 技術スタック（言語・フレームワーク・既存コードの有無）※不明なら確認する
• データの扱い（保存先・永続化の要否）
• 入出力・画面 / インターフェース
• エラー処理・例外・バリデーション
• 制約・コーディング規約・成果物の単位

上記は チェックリストではなく引き出し です。機能に無関係な観点は質問しないこと。

各質問の進め方:

• 1問ずつ ask_user で提示し、必ず応答（選択または自由記述）を待つ
• 各質問は choices を提示し、推奨回答を先頭に置く。自由記述が要る場合は allow_freeform: true
• 各質問に既定値を明示し、ユーザーが「スキップ / 任意」を選んだら既定値で進める
• 未回答の場合はフォローアップを1回だけ行う
• 質問数は機能の複雑さに応じて調整する（目安: 3〜7問程度。単純なものは少なく）
• ヒアリング途中でも、ユーザーの要望が変われば項目を追加・修正してよい

Step 3: 要件の要約と実装計画

全質問が終わったら、まず要件を確定させてから計画を出します。

• 要件の要約: ヒアリング結果を箇条書きで要約し、認識合わせをする
• 実装計画: 段階的な手順（マイルストーン）を提示する
• 成果物: 作成・変更するファイルや構成を提示する
• ここで一度ユーザーに確認を取り、ズレがあれば修正してから次へ進む

Step 4: TODOチェックリストの生成

実装計画を、1つずつ確認しながら進められる小さな単位 のTODOに分解します。中身は機能によって変わるため、これも動的に生成します。

• マイルストーン / セクションごとにグルーピングする
• 各TODOは「1回の差分で完結する粒度」にする（大きすぎる項目は分割）
• 依存関係のある順番（基盤 → 中核機能 → 周辺 → 仕上げ）に並べる

構造の例（プレースホルダ。実際の項目は機能に合わせて生成する）:

セクションA: 基盤・骨組み

• ...

セクションB: 中核機能

• ...

セクションC: 周辺機能・エラー処理

• ...

セクションD: 仕上げ・ドキュメント

• ...

Step 5: 1つずつ実装 → ファイル作成・編集 → 差分 → next

TODOを 1つずつ 実装し、各TODO完了ごとに次の形式で実行・出力します。

1. ファイル作成・編集を実施 — 提案した差分を実際にファイルに反映
2. TODO: [TODO名] — 実装内容をヘッダーで表示
3. 差分: 追加を +、削除を - で示した diff を表示する
4. ウォークスルー: 実装要約（何をしたか）・設計判断（なぜそうしたか）・テスト / 動作確認手順・改善案を添える
5. 「このTODOで問題なければ next と入力してください」と表示して待つ

重要なルール:

• 1つのTODOにつき、差分は1つだけ出力する
• 全部を一度に実装せず、段階的に進める
• ユーザーが next と入力するまで、次のTODOに進まない
• 「修正: ◯◯」と言われたら、ファイルを修正して同じTODOの差分を直して出し直す
• すべてのTODOが終わるまで、このループを繰り返す

この流れにより、各段階の変更内容を理解しながら、納得して実装を進められます。