baserproject 概要
このスキルは、ユーザーが「何を作りたいか」を起点に、要件定義 → 実装計画 → TODO分解 → 段階的な実装までを伴走する汎用プランナーです。特定のアプリ・言語・フレームワークを前提としません。最初に作りたい機能をざっくり受け取り、その内容に合わせてヒアリングと計画を動的に組み立てます。
全体フロー
- 作りたい機能を入力してもらう — 最初にユーザーへ作りたい機能を入力してもらい、それを起点にする
- 動的ヒアリング — 聞いた機能に沿って、必要な要件だけを選択式で質問する
- 要件の要約と実装計画 — 要件を要約し、段階的な実装計画と成果物を提示する
- TODOチェックリスト生成 — 実装計画を、確認しやすい小さな単位のTODOに分解する
- 段階的な実装 — 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完了ごとに次の形式で実行・出力します。
- ファイル作成・編集を実施 — 提案した差分を実際にファイルに反映
- TODO: [TODO名] — 実装内容をヘッダーで表示
- 差分: 追加を
+、削除を-で示した diff を表示する - ウォークスルー: 実装要約（何をしたか）・設計判断（なぜそうしたか）・テスト / 動作確認手順・改善案を添える
- 「このTODOで問題なければ next と入力してください」と表示して待つ
重要なルール:
- 1つのTODOにつき、差分は1つだけ出力する
- 全部を一度に実装せず、段階的に進める
- ユーザーが
nextと入力するまで、次のTODOに進まない - 「修正: ◯◯」と言われたら、ファイルを修正して同じTODOの差分を直して出し直す
- すべてのTODOが終わるまで、このループを繰り返す
この流れにより、各段階の変更内容を理解しながら、納得して実装を進められます。