cs-build-plan-app

アイデアからアプリを計画する

まだコードはありません。cs-build-import-codebase が生成するものと同じ成果物、つまり コア機能 → サブ機能 → メモ → PRD → タスク を、リポジトリではなく人から引き出して作成します。

2 つのフェーズの間にゲートがあります。

A. 考える（§1–§6）	対話し、何も書き込みません	仕事、ユーザーの行程、あらゆる種類のユーザー、プラットフォームの判断、難所とその解決策、システムの確認、v1 の範囲
GATE	計画を読み返し、明確な承認を得る	§6a
B. 書き込む（§7）	CodeSpring を更新します	マップとメモ
C. 確認する（§7a）	cs-build-ui-mockup に引き継ぎます	最も低コストで意見の相違を確認できます。修正内容はメモに反映します
D. 指示する（§8–§9）	モックアップの合意が得られてから進めます	PRD、その後タスク

フェーズ A では CodeSpring に書き込まないでください。 マップを作成すると、あとから見直すのにコストがかかり、まだ議論の途中だった計画にコミットしたように感じさせてしまいます。フェーズ A では、意見をぶつけ合うことが想定されています。

これは まだコードがない場合の cs-build-import-codebase に相当するスキル であり、意図的に独自の書き込み処理を行います。このスキルのエンジンは リポジトリを読み取ること であり、ここにはリポジトリがないためです。2 つのスキルが共有するのはその先の到達点であり、すでに共通化されています。cs-build-import-codebase/references/target-map.md のノードモデルとマップのルール、mindmap-structure.md のスキーマ、commands.md の CLI を使ってください。再導出したり、分岐版を作ったりしないでください。

共有ナレッジとして、以下を読んでください。codespring スキルの references/project-state.md（どこからでも開始できる方法、3 つの段階）、references/mindmap-structure.md（正確なノード／エッジのスキーマ）、references/prd-management.md、references/pitfalls.md。そして cs-build-import-codebase/references/target-map.md も読んでください。 ノードモデル、1 文カードのルール、コア機能の上限 4～8 件はここでも同じです。言い換えたり、再導出したりしないでください。

続いて、このスキル固有のリファレンスを確認してください。これらは、何もないところから計画する際の違いを扱います。

リファレンス	読むタイミング
references/elicitation.md	常に。人の頭の中や録音から、実際に作りたいアプリを引き出す方法です。
references/platform-choice.md	技術スタックを決める前に。Mac、Web、iOS の選択は機能によって判断します。ただし、それを覆す制約があります。オーナーが実際に開発・保守できるものです。それぞれの選択にかかるコストも扱います。
references/hard-part-first.md	常に。どのアプリにも、本当に難しい部分が 1 つあります。それを見つけ、先行事例を探し、実証してください。
references/data-and-shape.md	常に。また、機能リストを確定する前にユーザーの種類を確認してください。誰も尋ねない 5 つのシステム確認事項：他者が公開している数値とその更新方法、複数の製品で共有されるロジック、あらゆる種類のユーザーとオーナー向け管理画面、データベースの所有者、データがどれくらい最新かを示す方法です。
references/v1-scope.md	マップを書く前に。1 つのループへの絞り込みと、収益化のゲートを扱います。

すべてを左右する違い

コードベースのインポートには確かな根拠があります。アイデアの計画にはありません。

リポジトリがあれば、間違えても確かめられます。ファイルを読めばよいのです。アイデアの場合は、本人の頭の中にあるものと一致しない自信満々の計画でも、実際に形にして見せるまでは、まさに良い計画のように見えてしまいます。以下のルールはすべて、それを防ぐためにあります。

もうひとつ、こちらのほうが難しいことがあります。

本人は、自分が何を知らないのかも、何が必要なのかもわかっていません。

技術に詳しくない人は、これまで目にしたものをもとにアプリを説明します。Instagram で見たものを求めてくるでしょう。あなたの仕事は、依頼をそのまま書き起こすことでも、自分のプロダクトに対する好みを押しつけることでもありません。本人が達成しようとしていることを突き止め、本人にはできない技術的な判断を加えることです。何が可能か、何に費用がかかるか、すでに何が存在するか、そして本当に難しい部分は何かを見極めます。何を作るかは本人が決めます。どうやって作るかはあなたが決め、何を作るかによって本人の想定以上の費用がかかる場合は、それを伝えるのもあなたの役目です。

本人の言葉だけで計画セッションを終えてはいけません。 計画に本人が自分で書けなかったことが何も含まれていないなら、あなたは計画を立てたのではなく、口述筆記をしただけです。

---

0. プロジェクトがすでにどの段階にあるかを確認する

このパックの他のスキルと同じ開始手順です。コードがなくても、ゼロから始めるとは限りません。

bash ../codespring/scripts/fetch-project.sh --out /tmp/cs-state   # read-only snapshot; prints the projectId
node ../codespring/scripts/state.mjs       /tmp/cs-state          # summary line + booleans and counts
node ../codespring/scripts/check-map.mjs   /tmp/cs-state          # map faults, before you add to them

ローカルの .codespring/config.json から projectId を読み取り、書き込みを行う前に表示してください。

• マップがすでに存在する → 計画の開始ではなく、既存の計画を拡張します。target-map.md のマップ品質の段階的手順を実行し、タイトルで照合してください。作り直してはいけません。
• 実はコードが存在する → スキルが違います。cs-build-import-codebase に引き継いでください（project-state.md にある5つの質問のいずれかに当てはまらない場合は cs-build-audit-codebase に引き継ぎます）。Lovable／Base44／v0 で作られた未完成のプロトタイプも、ユーザーが「ただのモックアップ」と呼んでいてもコードです。「まだ何もありません」という言葉を鵜呑みにする前に、実際に確認してください。
• 未リンク → リンクします。チームワークスペースのプロジェクトは、最初にウェブアプリで作成する必要があります（pitfalls.md）。

⚠️ 新しいプロジェクトには専用ディレクトリを用意してください — このスキル特有の落とし穴

このパックの他のスキルは、マッピング対象のリポジトリ内で実行されます。このスキルにはリポジトリがありません。そのため、自然な保存場所がなく、今いるディレクトリがユーザーの別のプロジェクトの親フォルダであることもよくあります。そのフォルダには、すでに .codespring/config.json があり、別のプロジェクトを指していることがあります。

そこで codespring init を実行すると、その設定が新しいプロジェクトを指すようにひそかに変更され、次回、隣接するプロジェクトで作業する際に、間違った場所へ書き込まれてしまいます。実際に、設定が稼働中の Mac アプリのプロジェクトを指しているフォルダで計画作業を開始したケースがありました。新しいプロジェクトを新規サブフォルダに作成したことで、乗っ取りを防げました。

codespring status                       # ALWAYS run first — whose project is this directory linked to?
mkdir -p "<AppName>" && cd "<AppName>"  # a new directory for the new project, even with no code in it
codespring project create --name "..." --description "..."
codespring init --project <newId> --force
codespring status                       # confirm the new id
cat ../.codespring/config.json          # confirm the PARENT's link is untouched

このフォルダは後にリポジトリになります。そのため、使い捨ての足場ではありません。すでに別のものにリンクされているディレクトリで init を実行してはいけません。また、空に見えるフォルダが未リンクだと思い込まず、必ず確認してください。

1. 素材をすべて集める

入力となる素材は、電話の録音や文字起こし、ボイスメモ、Loom、気に入っているアプリのスクリーンショット、とりとめのない段落、または対面での会話など、どんなものでもかまいません。

質問を一つでもする前に、すべてに目を通してください。 録音ですでに答えが出ている質問を携えてインタビューに臨むのは、技術に詳しくない人の信頼を失う最も手っ取り早い方法です。

要約するのではなく、抜き出してください。 本人の言葉で、次のことを拾い出します。

• 誰が使い、何を実現しようとしているのか
• 説明された画面、ボタン、場面、動作のすべて
• 明示された制約（プラットフォーム、オフライン対応、価格、期限、対象年齢、アクセシビリティ）
• 参考にしたアプリやスクリーンショットのすべてと、特にどこを気に入ったのか
• 2回以上口にしたこと — 繰り返しは、本当に重要なことを示しています
• 拒否したことと、その理由

本人の言い回しを残してください。 *「5分が最低ラインで、それより短いなら時間をかける価値はない」という言葉はメモに残り、最終的には PRD にも反映されますが、「セッション時間を設定可能にする」*という表現ではそうはなりません。本人の言葉には、こちらが言い換えるとひそかに抜け落ちてしまう制約や理由が含まれています。

営業通話から情報を引き出す方法や、素材がとりとめのないボイスメモしかない場合の進め方を含む全手順については、references/elicitation.md をご覧ください。

1a. 何で作ると決めているかを、まず最初に確認する

計画全体が成り立たなくなる可能性があるため、早い段階で一つだけ質問します。

「特定のツールで作ると決めていますか？ Base44、Lovable、v0、Replit、Bubble などでしょうか？」

技術に詳しくない人は、すでにサブスクリプションを契約し、使い方を少し覚えたツールを持っていることがよくあります。しかし、本人にとっては要件ではなく、単なる細かいことに感じられるため、聞かれない限り話してくれません。これは絶対に無視できない制約です。 AI ウェブアプリビルダーが作れるのはウェブアプリであり、ネイティブのデスクトップアプリやモバイルアプリは作れません。そのため、「Mac アプリ」を作る計画では、本人は実現できません。

プラットフォームを選ぶ§4ではなく、ここ、§1で質問してください。§4で聞く頃には、本人のツールでは実現できない答えに向けて、すでに検討を進めてしまっています。

追加で聞くこと：そのツールで作ると決めているのか、それともすでに料金を払っているだけなのか？、1年後には誰が保守するのか？ その答えを§4に引き継ぎ、食い違いがあれば率直に解決します（references/platform-choice.md — 「実現可能性より優先される制約」）。

2. 機能を探す前に、解決すべき課題を見つける

まず、次の内容を一段落にまとめ、声に出して合意します。

誰がこれを開き、何を実現しようとしていて、現在はこれなしでどうしていて、うまくいったことをどう確認するのか？

この段落を書けないなら、計画を立てるための情報が足りていません。機能について話し合っても解決にはつながりません。§1に戻ってください。

最後の部分は飾りではありません。*「彼女は週3回のセッションをこなす」は検証可能な成果ですが、「彼女は支えられていると感じる」*はそうではなく、アプリが目指す目標にもできません。

3. 画面を一緒にたどります

これは要件を引き出すためのエンジンで、ソフトウェアについて説明できない人にも効果があります。

目を閉じて、これを使っているところを想像してください。目の前に開いています。最初に目に入るのは何ですか？何をクリックしますか？その次に何が起きますか？

機能一覧ではなく、ひと続きの体験としてたどります：開く → 最初の画面 → 最初のクリック → やりたかった主なこと → 完了 → 翌日また戻ってくるきっかけ。技術に詳しくない人はこの方法なら優れていますが、「中核となる機能は何ですか？」という質問には答えるのが苦手です。

まずはサイドバーから。 デスクトップアプリやウェブアプリでは、*「サイドバーには何がありますか？」*と聞くと、ユーザー自身が見てわかる形で、中核となる機能の一覧がほぼそのまま得られます。まさにその言葉で聞いてください。

サイドバーは中核機能を見つけるための手がかりであり、中核機能の定義ではありません。 中核機能とは、ユーザーが行う大きなことです。多くの場合、その一覧はサイドバーに表示されています。そのためこの質問が有効なのです。ただし、アプリによってはナビゲーションをクリックするのではなく、ボタンを押して開く重要な画面もあります。それも中核機能です。ユーザーがそこへたどり着く方法は、メモに記すナビゲーション上の詳細であり、マップに載せるかどうかを決める要素ではありません。

本当に重要な判断基準は、**これはユーザーが行う大きなことであり、これを省くと開発内容の大部分が見えなくなるか？**です。両方とも「はい」なら、サイドバーにあるかどうかにかかわらず、中核機能です。

引き続き、4～8個を目指してください（target-map.md）。この方法で10個になった場合、リストの粒度が細かすぎるのであって、正直に捉えすぎているわけではありません。

次に、コンテンツを用意する「2人目」のユーザーの利用の流れをたどります。 人はアプリを使う人の視点から説明し、エクササイズ、レッスン、テンプレート、プログラムを誰が入力するのかには触れないことがあります。コンテンツ作成ツールは2つ目のアプリであり、機能一覧には載らないまま、開発の30～50％を占めることもよくあります。初日にコンテンツを誰が用意するのか、誰が追加するのか、ユーザーごとに異なるのか、順番を誰が決めるのか、そして2日目には何が起きるのかを尋ねてください。これはアプリの計画で最も見落とされがちな質問です。references/elicitation.md。

スクリプト、追加質問、尋ねてはいけない質問については、references/elicitation.mdを参照してください。

3a. オーナーを含む、あらゆる種類のユーザーを洗い出します

回答によって機能が追加されるため、機能一覧を確定する前に、次の質問をしてください。

「これを使う人にはどのような種類の人がいて、それぞれ何を見たり、何をしたりできますか？また、誰が管理しますか？」

相手は1種類のユーザーについて説明するでしょう。しかし、通常は4～5種類います。エンドユーザー、ログインすることなく成果物を受け取ることが多いエンドユーザーの顧客、スタッフ、パートナー、そしてアプリを運用する事業のオーナーです。

ほぼすべてのアプリで、オーナー向けの管理画面が必要です。誰が登録したかの確認、プランやアクセス権の管理、アプリが依存するデータの編集などを行います。計画段階ではほぼすべてのプロジェクトで見落とされ、後から追加するには費用がかかります。画面を追加するだけでなく、権限モデルを変更する必要があるためです。どのようなプランやティアがあり、それぞれ何が利用可能になるのかを尋ねてください。これによって、権利情報を1つの列で扱うのか、システム全体を構築するのかが決まります。また、セキュリティのルールを明確に伝えてください。権限はデータベースとサーバーで適用し、インターフェースだけで適用してはいけません。ボタンを非表示にするだけでは、アクセス制御になりません。

忘れられがちなアクターの全一覧と、オーナー専用データの問題については、references/data-and-shape.md §3を参照してください。

4. アプリに必要な機能からプラットフォームを選ぶ

機能リストが確定する前に決めてください。実現できることが変わるためです。

好みや流行ではなく、必要な機能を基準に決めてください。

必要な機能	適したプラットフォーム
カメラ＋リアルタイムのローカル ML、ファイルシステムへのアクセス、バックグラウンド実行／メニューバー、完全なオフライン対応、負荷の高いローカル処理	デスクトップ（Mac）
リンクで共有、サインアップへの誘導、SEO、「相手に送るだけ」、初日からのクロスプラットフォーム対応	ウェブ
真にモバイルファースト（ジムや現場、外出先で使う）	モバイル

v1 で iOS が適切なケースは、ほとんどありません。審査に時間がかかり、Apple の取り分があり、年齢層が高めのユーザーは大画面を好む傾向があるためです。率直にそう伝え、理由も説明してください。

次に、選択による影響を明確に伝えてください。後から問題になりやすいのは、署名と公証、配布方法、支払い方法、「オフライン」が本当にオフラインなのかどうかです。決定事項とそれぞれの影響を網羅した表は references/platform-choice.md にあります。

次に、これらすべてを覆す可能性のある質問をしてください。実際には何を使って開発し、あなたが離れた後は誰がメンテナンスするのか？ 必要な機能からアプリに必要なものが分かります。この質問からは、その人が維持できるものが分かります。使うと決めているツールでは、必要なプラットフォーム機能を実現できない場合（AI ウェブアプリビルダーではネイティブのデスクトップアプリを出力できないなど）は、真の相反が生じています。どちらかを黙って押し通すのではなく、対話を通じて解決してください。相手が開発できないプラットフォームを黙って計画してはいけません。また、相手のツールのほうが簡単だからといって、必要な機能を黙って諦めてもいけません。両方のコストを提示し、選択してもらってください。references/platform-choice.md — 「機能の必要性を覆す制約」。

4a. すでに所有しているアプリから技術スタックを引き継ぐ

プラットフォームを選んだら、そのプラットフォームで動作するアプリをすでに持っているか（本人が所有するもの、またはあなたが開発したもの）を尋ねてください。尋ねてください。探し回ってはいけません。 隣のフォルダーにあるコードベースが、自動的に参考になるわけではありません。社内用だったり、放棄されていたり、今回のプロジェクトで対象外になったプラットフォーム向けだったりする可能性があります。意図的なテンプレートとして使うことを確認してから、コードを読むようにしてください。プラットフォームの決定が変わったら、すぐに候補から外してください。

確認できた場合は、マニフェストを読み、その構成を踏襲してください。同じ言語バージョン、依存関係、データベースレイヤー、デザインシステムの対象、ビルドスクリプトとリリーススクリプトを使います。

これは手抜きではありません。最も低コストで実現できる品質向上の判断です。

• その技術スタックが、そのプラットフォームで出荷できることがすでに実証済みです。署名、公証、自動アップデート、クラッシュレポートといった面倒な部分も含みます。
• デザインシステムがすでにあるため、一貫したビジュアル表現を追加コストなしで実現できます。
• 仕様を決めようとしていたコンポーネントが、すでに実装されていることがあります。 実際の事例では、クライアントがガラスのようにぼかしたパネルと、内側に白いカードを求めていました。参考アプリのデザインシステムには、その2つのコンポーネントがすでに含まれていました。確認したおかげで、作業がまるごと不要になったのです。
• 両方のアプリをメンテナンスする人が、覚える技術スタックは1つだけで済みます。

そのため、参考アプリの Package.swift ／ package.json ／同等のファイル、デザインシステムのフォルダー、scripts/ を確認してください。引き継ぐ技術スタックをマップの技術スタックノードに記録し、メモに参考アプリの名前を記載して、ビルダーが一から考案せずにどこからパターンを流用できるか分かるようにしてください。

参考アプリがない場合は、実績のある定番の技術スタックを選び、その理由を説明してください。

5. 難所を見極め、それをすでに解決した人を探す

どんなアプリにも、本当に難しいことは必ず1つだけあります。 あとは画面、フォーム、リストです。難所を特定していない計画は計画ではなく、願望にすぎません。そして、開発を始めて3週目にその難所が明らかになります。

どこが難所なのかを、声に出して伝えてから、次のことを行います。

1. 独自のものを設計する前に、先行事例を探します。 ほぼ間違いなく、誰かがすでに解決しています。WebSearch/WebFetchを使い、メンテナンスされているライブラリ、プラットフォーム標準のフレームワーク（多くの場合、最善の選択肢でありながら、最も見過ごされています）、オープンソースのリポジトリを探します。
2. 毎回、ライセンスを確認します。 その分野で最も検索されやすいライブラリは、商用利用できないことがよくあります。この見落としは、プロジェクトを後になって大きなコストとともに頓挫させます。
3. 存在する場合は、プラットフォーム標準のフレームワークを優先します。 依存関係がなく、ライセンスの問題もなく、パフォーマンスに優れ、OS の更新にも対応できます。
4. 難所を最初のタスクにします。 実際の入力で動作することを、画面を1つでも設計する前に検証するための、使い捨てのスパイクとして取り組みます。

手順、実例を交えたライセンスの落とし穴、スパイクの書き方については、references/hard-part-first.md を参照してください。

5a. システム面の確認を行う — 誰も尋ねない質問

Think フェーズで、v1 の範囲を決める前、ゲートの前に、もう4つの質問を声に出して確認します。誰もこれらを求めませんし、ユーザーも説明できません。しかし、それぞれ判断するだけなら簡単で、後から変更するにはコストがかかります。5つ目の質問 — ユーザーが誰か — は機能リストを変えるため、§3a で確認しました。

1. 「このアプリが依存する数値のうち、ほかの誰かが公表しているものは何ですか。それが変更された日に、何が起きますか？」 税率や関税率、法定基準値、金利や給付率、関税、郵便料金、為替レート、コンプライアンス上の制限、ライセンス料、最低賃金などです。該当するものがあれば、コードではなくデータベースに格納します。各行には適用期間の日付を持たせ、アプリはモデル化対象の日付に適用されていた値を解決します — すでに発表されている将来の変更についても同様です。保存したものにはすべて、どのバージョンで生成されたかを記録します。アプリはデータの有効期限が切れたことを把握し、その旨を表示します。API があると決めつけないでください — 多くの公開データセットには API がありません。また、公表元のサイトをスクレイピングする方法は、処理を止めるのではなく誤った数値を出荷してしまうため、メンテナンスされているテーブルよりも脆弱です。誠実に運用できる方法を計画してください。つまり、テーブル、インポートスクリプト、日付を定めたレビュー、情報源の記録です。そして、管理者が編集できる画面を用意してください。更新版を出荷できるようになる前に、発表済みだがまだ法制化されていない変更を反映してモデル化する必要があるからです。
2. 「このアプリは、同じコアロジックを共有する複数の製品のうちの1つですか？」 そうであれば、共有部分はすべての製品がインポートする1つのパッケージにします。コピーや再実装はしません。純粋でなければなりません。データベース、ネットワーク、フレームワーク、時計、乱数に依存せず、必要なものはすべて外部から渡します。バージョン番号を付け、トピックごとに小さなファイルに分割します。巨大なファイルは、関数をインポートせずにコピーする原因になるからです。コピーされたコードは必ず、気付かれないまま乖離していき、最終的には同じ事柄について社内の2つの部署が異なる数値を提示することになります。
3. 「組織にはすでにデータベースがありますか。また、ほかの製品や別の担当者がすでにその中で作業していますか？」 製品ごとに別のデータベースを用意することを基本とし、後から統合できるように、どちらも同じ所有権の境界を設けます。適切に構成された2つのデータベースを統合するのはマイグレーションです。絡み合った1つのデータベースをほどくには再構築が必要です。
4. 「ユーザーはデータがどれほど最新かを知る必要がありますか。または、数値の出所を証明する必要がありますか？」 金融、法務、医療に関する意思決定に使われる出力には、使用したデータと、そのデータがいつ時点のものかを表示する必要があります。アプリが検証できない最新性を断言してはいけません。推定値や前提は表示箇所で明示し、ユーザーが上書きできるようにします。

考え方、詳細なルール、各ルールの実例については、references/data-and-shape.md を参照してください。

6. 実際にリリースできる v1 に絞る

完成した製品について説明してもらいます。あなたの役割は、§2 で定義した仕事を最初から最後までこなせる初版を作ることです。つまり、完全に動作し、販売できる一連の流れをひとつ実現します。

• 一連の流れを、最初から最後まで完成させます。 ユーザーが開いて、主な操作を行い、結果を得られるようにします。中途半端な状態のものは残しません。
• 深さを犠牲にせず、範囲を絞ります。 60％の完成度の機能が5つあるアプリは、壊れたアプリです。100％の完成度の機能がひとつあれば、それは製品です。
• 記録機能は v1 の機能ではありません。 「ユーザーが自分のやったことを入力する」ことに価値がある機能は、ユーザーを惹きつける力がほぼなく、2週目には使われなくなります。ユーザーのためにアプリが何かをしてくれる機能こそ、ユーザーが戻ってくる理由になります。references/v1-scope.md を参照してください。アイデアを計画に落とし込む際に最もよく起こる失敗です。
• 収益化の関門： お金を稼ぐために必要な人がいるなら、「どうやって支払ってもらうのか？」と問い、その答えが v1 に含まれていることを確認します。支払いを受け付ける手段がない v1 は、どれほど優れていても収益を生み出せません。誰もわくわくしない機能なので、ほぼすべての計画で見落とされます。
• 実際のコストを確認します。多くの場合、コストの中心はコードではなくコンテンツです。 メディアライブラリ、データセット、エクササイズのカタログ、文書コーパスが必要なアプリでは、ソフトウェア開発は全体の20％で、コンテンツの調達が80％を占めることがよくあります。そうであれば、今のうちに明確にし、調達のプロセスを計画してください。そこがスケジュール上のリスクになります。references/v1-scope.md。

v1 に含まれないものも、含まれるものと同じくらい明確に示してください。明言されていない削減は、後になって約束が破られたと受け取られます。

6a. 関門 — 計画を読み返し、合意を得る

まだ何も書かれていません。明確な承認を得るまで先に進まないでください。

§3 で説明されたとおりに計画を説明し直します。「開くと X が表示され、Y をクリックすると、Z が起こる」という流れです。そのうえで、本人だけでは提示できなかった情報を加えます。

1. プラットフォームの選択とその理由（繰り返し説明できる一文）。
2. 難しい部分と、それを解決するものの名称（ライセンスを含む）。
3. ユーザーの種類すべてと、オーナーが得られるもの（管理画面、プラン、オーナーだけが編集できる内容）（§3a）。
4. 第三者が公開する数値があれば、その保存場所、更新担当者、更新頻度（§5a）。あわせて、必要であればデータベースの選択についても説明します。
5. v1 に含まれるものと、明確に含まれないもの。
6. 収益が必要な場合は、支払い方法。

続けて、次の言葉で尋ねます。「何か間違って理解した点や、足りない点はありますか？」

人はストーリーなら訂正しますが、機能一覧にはそのまま承認を出します。間違いを見つけるなら、ここが最後の、まだ修正コストが安いタイミングです。§7 以降は、計画が地図、メモ、タスクとして形になり、変更には実作業が伴います。

必要な回数だけ、ここで調整します。本人が承認した場合に限り、先に進みます。

7. マップを書く

仕組みは cs-build-import-codebase §4 と同じです。ノードモデル、1文でまとめるカードのルール、ノートはルートのみという制約は、すべて target-map.md に記載されています。これらを改めて導き出さないでください。

codespring mindmap set-info --title "..." --description "..."
codespring mindmap tech-stack --replace --add '[{"id":"tech-...","title":"...","description":"Frontend"}, ...]'
codespring mindmap features --add '[{"title":"Today","description":"..."}, ...]'   # CORE features; keep the returned ids
codespring feature create --parent <coreId> --title "..." --description "..."       # sub-features
codespring mindmap note <coreId> --title "How it works — X" --text "$(cat note.txt)"

codespring mindmap features --replace は置き換えません。追記して重複を作ります（pitfalls.md）。タイトルで差分を確認し、不足しているものだけ追加してください。復旧するには、codespring feature delete <id> --yes を実行します。

この手順では、ノートが成果物のすべてです。 読み取るコードがないため、PRD 生成ツールが得るコンテキストはノートだけです。ここで内容の薄いノートを作ると、PRD も内容の薄いものになり、参照できるリポジトリもありません。各コア機能のノートには、次の内容を記載します。

1. この機能が何をするか。可能な限り、ユーザー自身の言葉で記載します。
2. 画面と操作の流れ — ユーザーに何が表示され、何をクリックし、何を得るか。
3. 決定事項とその理由 — プラットフォーム、選択したライブラリとそのライセンス、平易な言葉で説明したデータモデル、理由とともに意図的に先送りした事項。
4. この機能に関する §5a の回答 — 使用する公開済み数値とその保存場所、別の製品と共有する内容、各項目の閲覧・編集が許可されるユーザー、データがどれだけ最新かをインターフェイスでどう表示する必要があるか。これらは機能リストからは分かりませんが、適切な構成を構築するうえで PRD とタスクに必要です。
5. v1 に明示的に含めない内容。気付かないうちに実装されることを防ぎます。

PRD を生成する前にノートを書いてください。

7a. cs-build-ui-mockup に引き継ぐ — PRD の作成前に

誰も確認していない計画から PRD を生成しないでください。 マップとノートは文章で合意されていますが、文章だけでは不十分です。文章では双方が異なる形で不足部分を補ってしまい、どちらもその違いに気付かないため、本人が実際には理解していない計画に承認を与えてしまうことがあります。

cs-build-ui-mockup を実行してください。 このツールは、これらのノートから使い捨てのクリック可能なモックアップを作成し、計画では表現できなかった点 — 画面の順序、階層、配置、不完全だと判明した選択肢 — を明らかにするレビューを実施して、すべての修正をノートとタスクに反映します。

実際の実行では、ゲートをすでに通過し、完成しているように見えた計画から、10 分で 11 件の修正が見つかりました。文章によるレビューでは、どれも明らかになっていませんでした。

レビューによって機能セットが変更された場合にのみ、ここに戻ってください。それ以外の場合は、モックアップ → cs-build-create-prd → cs-build-create-tasks と進みます。

8. 検証する

目視で判断せず、チェックを実行します。

bash ../codespring/scripts/fetch-project.sh --out /tmp/cs-verify
node ../codespring/scripts/check-map.mjs   /tmp/cs-verify --expect-core <the count you intended>

コア機能の数が一致していること、サブ機能がトップレベルにフラット化されていないこと（codespring feature update <subId> --parent <coreId> で親を設定し直します）、タイトルが重複していないこと、コア機能ごとにノートが 1 つあることを確認します。終了コードが 0 以外の場合は実際の失敗です。報告する前に修正してください。その後、プロジェクトのリンク https://v2.codespring.app/project/<projectId> を提示します。

9. 引き継ぐ

PRD → cs-build-create-prd（コア機能ごとに Both）。ノートのない機能の PRD は決して生成しないでください。 タスク → cs-build-create-tasks。§5 のスパイクをタスク #1 にします。 その後 → cs-build-feature。

10. できあがったものを報告する

担当する内容を把握できるよう、締めくくりは短くします。プロジェクトのリンク、コア機能の名前、それぞれにノートがあること、そして次に行うことを 1 つだけ伝えます。通常は、*「タスク #1 は難所を実証するスパイクです。何よりも先に実施してください」*と伝えます。

---

良い計画の条件

• 目的を説明する段落があり、機能の名称を挙げる前に合意されています。
• 機能リストはブレインストーミングではなく、一連のユーザー体験をたどって作られており、ユーザーがサイドバーの項目として認識できる中核機能が4〜8個に収まっています。
• プラットフォームは機能面を基準に選ばれ、その選択による影響も明示されています。既定の選択肢だから、あるいは流行だからという理由で選ばれていません。
• 難所が明示されており、ライセンスを確認済みの実績ある先行事例があり、そのライセンス上の義務が1行で説明され、スパイクのタスク#1になっています。
• 機能リストを確定する前に、あらゆる種類のユーザーが列挙され、オーナー向けの管理画面があり、権限はサーバーとデータベースの両方で強制されると明記されています。
• 他者が公開している数値はすべて明示され、コードではなく日付付きの行に保存され、モデル化する日付に基づいて解決され、更新を続けるための現実的な計画があります。APIが存在するという前提も置かれていません。
• 同じロジックが複数の場所で実行される場合は、別のコピーを作らず、純粋でバージョン管理された単一のパッケージになっており、データベースの選択も意図的に行われ、既存のものをそのまま引き継いでいません。
• 新しいプロジェクトには専用のディレクトリが用意され、兄弟プロジェクトのリンクが上書きされていません。
• 同じプラットフォームですでに実績あるアプリが存在する場合、その技術スタックとデザインシステムを引き継ぎ、再発明していません。
• v1は完結したひとつのループであり、そのプロジェクトで収益を得る必要がある人には、v1の段階で支払いを受け付ける方法があります。
• 実際のコストがコードではなくコンテンツにある場合、それが明言され、制作パイプラインが用意されています。
• メモは十分に充実しています。このプロセスでPRDが得られるコンテキストは、メモだけです。
• ゲートを通過する前にCodeSpringには何も書き込まれておらず、計画はストーリーとして読み返され、その場で「何か間違っているところはありますか？」と尋ねられています。
• 計画には、**本人だけでは提示できなかった技術的判断が含まれています。**本人の言葉を整えただけなら、それは口述筆記です。