msw-planning

MSW 新規ゲーム企画モード（msw-planning）

目的

ユーザーが「こんなゲームを作りたい」と考えている段階で、MSWで何を作るか、どう作るかに落とし込みます。ガイド付きのセッションでGDD／ロードマップを作成し、その後、このスキルが段階的な制作をガイドします。詳細なPhase計画、進捗管理、計画の改訂を行い、各マイルストーンの制作準備が整い、本格的な実装に進めるようになるまで支援します。ゲームデザインに詳しくない人は質問に答えていくだけでよく、経験者にとっては決定事項をすばやく記録する手段になります。

基本原則（このように機能する理由）

• カタログに基づく計画：MSWは2D・mLua（Lua拡張スクリプト言語）・クロスプラットフォームであるため、「作れるもの」の範囲には限りがあります。漠然としたアイデアを、references/genre-catalog.mdにある実際のジャンル／マップタイプ／メカニクスに当てはめて、実現可能な計画を立てます。汎用的なゲームの知識だけで計画すると、MSWでは実現できないデザインにつながります。
• 規模に見合った制作計画：カタログには、ジャンルごとに制作の労力の目安（Low／Medium／High）が示されています。これは判断材料であり、最終判定ではありません（基準は1～5マップ・10～20ユニット／アイテム・初級～中級のmLua。無理なく一人で作れる範囲の最上位はタワーディフェンスです）。ジャンルを拒否するためではなく、期待値を設定するために使います。最初の制作規模は、制作の労力＋範囲（マップ／コンテンツ）によって決め、カレンダー上の期間／開発日数の見積もりでは決して決めないでください。このスキルはユーザーのスキルレベルや作業可能時間がわからないため、「N日／週間かかります」と約束できません。ユーザーの目標が大規模な場合（制作の労力がHighのジャンル、システム／マップが多い、「全部作りたい」など）は、すべてを一度に計画せず、最初の制作範囲を小さなプレイ可能なコア（MVP）に絞り、残りは後のPhaseに回します。これはどのジャンルにも当てはまります。
• 一度で進める（やり取りを往復させない）＋方向性の確認を1回行う：ユーザーとのやり取りは**STEP 1（まとめて質問）とSTEP 3（方向性の確認）**に限定し、途中で何度も質問を返さないでください。ただし、GDDを書く前にSTEP 3（方向性の確認）を決して省略しないでください。カタログに基づく結果を見せるだけで、すぐにGDDへ進んではいけません。方向性が確認できたら、ただちに成果物を作成します。
• 成果物の標準化：結果を固定のGDD構成（references/gdd-template.md）に沿ってMarkdownで出力し、実装スキルが引き継いでMVPまで進められるようにします。
• 「後で」の記録場所を一本化：GDDが扱うのは、対象のマイルストーンのみです。対象外の内容、つまり削除した機能、後のマイルストーンに関するアイデア、議論の途中で出た「いつかやろう」という要望は、出てきた時点で、継続的に管理するマイルストーンロードマップ（Docs/<game>-Roadmap.md：将来のマイルストーンの枠、時期が不明ならバックログ）に記録し、GDDには決して残しません。記録場所は一つにし、重複させません。現在のマイルストーン以降の内容はロードマップに、現在のマイルストーン内の内容はGDDに記録します。
• プロジェクトを前に進める：成果物を作成するたびに、次のステップをまず提案します（例：「次にPhase 1の詳細計画を作成しますか？」）。ユーザーが希望すれば続行し、中止を求めたら止めます。提案であり、押し付けではありません。（文書の途中で延々とやり取りを繰り返すこととは異なり、成果物と成果物の間をつなぐものです。）
• 意思決定の場では自由入力ではなく選択肢を提示する：ユーザーが判断する各段階、すなわちSTEP 3の方向性確認、Phaseの引き継ぎ（今すぐ実装するか、次のPhaseの計画を書くか）、ソフトPhaseゲートでは、エージェントの複数選択UI（利用できる場合。例：Claude CodeのAskUserQuestion）を使い、構造化された選択肢を提示してください。ユーザーが自由入力で回答するのではなく、選択肢をクリックできるようにします。推奨する選択肢には印を付けますが、強制はしません。そのようなUIがない場合は、番号を付けた選択肢を明確に文章で提示します。さらに、デザインに影響する意思決定の場ではWeb意思決定シート（STEP 5のWebビュー）も開き、選択前に各選択肢で実際に何を作るのかユーザーが確認できるようにします。

起動時 — 既存のGDDを確認する（再開／新規／ブロック中）

ビルドは複数のセッションとマイルストーンにまたがります。各マイルストーンは1つのGDDです。各ファイルの保存場所（すべてプロジェクトルート直下で、RootDeskの外。refresh_workspace後も保持されます）：

• 進行中のGDDとフェーズ計画 → Docs/。
• Docs/<game>-Roadmap.md → ゲームの継続的なマイルストーンロードマップ（ビジョン・リリース基準・マイルストーンごとに1つの枠・バックログ）：マイルストーンをまたぐ方向性を示すもので、M1のGDDとともに作成し、恒久的に保持します（アーカイブしません）。これはGDDではありません。進行中のマイルストーンの契約は、引き続きそのマイルストーンの-M<n>-GDD.mdに記載します。
• 完了したGDD → Archive/（マイルストーン完了時）。
• Archive/As-built.md → 世界の実装記録：スキルが管理する、厳選された現状のマップです。ユーザー向けの計画文書ではなく、AI／引き継ぎ用のリファレンスです（references/build-management.mdのクリーンアップで維持し、以下のブラウンフィールドで初期作成します）。

以下のフローを実行する前に、計画ファイルを検出します — Docs/とArchive/の両方で<game>-M<n>-GDD.mdを確認してください：

• これらのディレクトリ（大文字のDocs/／Archive/）の全内容を一覧表示します。ディレクトリ内のすべてを返すディレクトリ単位の一覧表示（例：エージェントのファイル一覧機能、またはDocs/*を指定したGlob）を使い、その一覧から-GDD.md／-Phase<N>.mdで終わる名前を自分で照合してください。絞り込んだパターンや内容検索で検出してはいけません（*-GDD.mdのglobやgrepは、大文字と小文字を区別し、対象範囲も不安定です。*.mdはトップレベルのみで、docs/はDocs/と異なるため、見落としが「GDDなし」と誤認されるおそれがあります）。また、記憶に頼ってはいけません。
• 「GDDがどこにもない」と結論づけられるのは、Docs/とArchive/の一覧が実際に空の場合のみです。
• **Archive/As-built.mdが存在する場合は、現状のマップとして最初に読みます。Docs/<game>-Roadmap.md**が存在する場合は、マイルストーンをまたぐ方向性を確認するため、併せて読みます（進行中のGDDと取り違えないでください）。
• 通常、進行中のGDDは最大1つです。複数ある場合は、まずどのゲームについてなのかを尋ねてから、以下のルールを適用してください。

ゲート条件 — 「続けて」／「次のタスク」／再開の依頼は、Docs/またはArchive/に計画が存在する場合にのみ有効です（<game>-M<n>-GDD.md／<game>-M<n>-Phase<k>.md、または以前のマイルストーンとArchive/As-built.mdの組み合わせ）。どちらにも何も存在しない場合、依頼を再開として扱ってはならず、STEP 1の質問を自動的に開始してもいけません。依頼が続行／「次に何をするか」の意図である場合、またはユーザーが既存の作業を土台にしていると述べている場合（新規テンプレートから始める場合ではない）は、以下のブラウンフィールドに進みます。それ以外（新しいゲームの開始、または意図が不明確な場合）は、保存済みの計画がないことを伝え、新しいゲームを始めるか尋ねてください（その後STEP 1へ）。ワークスペース内のファイルからブラウンフィールドだと推測してはいけません。テンプレートにはサンプルが含まれるため、ワークスペースが空でないことは、以前の作業がある証拠にはなりません。

GDDが存在する場合、どこまで実際に完了しているかは、ワークスペース内のファイルではなく、GDD／フェーズ文書のタスク状態（⬜/🟡/✅）から判断してください（テンプレートには.mlua／.model／.uiが含まれるため、ファイルの存在は進捗を判断する確実な根拠ではありません）。その後、分岐します：

• ユーザーが明示的に続行／再開を希望した場合 → 状態にかかわらず 再開（以下の手順に従います）。
• すべてのロードマップとフェーズ項目が ⬜（進捗がまったくない計画）であり、かつゲームの最初のマイルストーンである場合 — Archive/ に同じ <game> の GDD がなく、GDD の番号が M1 の場合です。（提案する前に確認してください。過去のマイルストーンがアーカイブされている場合、または現在の GDD の番号が M2+ の場合、それだけで、このワールドにはすでに構築済みのものがあることの証拠になります。進捗ゼロの計画はその上にあるだけなので、以下の 🟡/✅ のケースに該当し、こちらには該当しません。）→ 選択可能な選択肢（コア原則を参照）を提示します。① この計画（[game]）を続行する／② 破棄して新しいゲームを計画する。破棄を選択した場合は、最初に削除するファイルを正確に示してください — Docs/<game>-M<n>-GDD.md、そのゲームの Docs/<game>-M<n>-Phase<k>.md、およびそのゲームの Docs/<game>-Roadmap.md（これは M1 GDD とともに作成されているため、GDD と一緒に破棄します。残しておくと、破棄したゲームの方向性が次の計画セッションに持ち込まれてしまいます）— これらのみを削除し、STEP 1 から新たに開始します。
• いずれかの項目が 🟡 または ✅ の場合、または GDD の項目がすべて ⬜ でも、このゲームの過去のマイルストーンが存在する場合（Archive/ に同じ <game> の GDD がある、または番号が M2+）— つまり、このワールドに実装中または実装済みのものがある場合 → ここでは破棄も新しいゲームの計画も行いません。このワールドではすでにプロトタイプの作成が進んでいること、そして本当に新しいゲームを作るには新しいワールドで作業する必要があることをユーザーに伝えて、その後停止します。このスキルではワールドを作成できないため、ユーザーが新しいワールドを作成し、そこでスキルを実行します。（実際にはこのゲームの続行を希望していた場合は、代わりに再開します。進捗ゼロの次のマイルストーンの計画を見直すのは Archive/As-built.md に基づく計画の改訂であり、依然として同じゲームです。新しいゲームではありません。）
• 状態が不明確な場合（Phase ドキュメントがない、または整合性がない、進捗が曖昧など）→ 🟡/✅ のケースとして扱います（破棄せず、上書きで作成しません）。 既存の計画を再開するには：

1. まず既存のドキュメントを読むこと — Docs/<game>-M<n>-GDD.md（加えて、存在する すべての Docs/<game>-M<n>-Phase<k>.md。前の Phase がユーザーテスト待ちの間は複数が共存することがあり、そのチェックリストには §6 にまだ記載されていない状態が含まれる可能性があります。さらに、マイルストーンをまたぐ文脈を把握するため Docs/<game>-Roadmap.md も読みます）。STEP 1～4 を再実行しないでください。計画はすでに存在します。
2. 状態を再構成する：GDD の Stage 行とロードマップの ⬜/🟡/✅、🟡 Implemented (untested) 項目（再テスト／ユーザー確認が必要なものとして印を付けます）、および最近の §9 Plan changes を確認します。
3. 再開した作業で実装またはチェックリストの状態に触れる場合は、今すぐ references/build-management.md を最後まで読んでください（STEP 6 の必須ゲートを参照）。再開時は読書チェーンが最も弱くなります。ドキュメントは過去のセッションで書かれたものだからです。ドキュメントを読む際に、古くなった AI 向け注記も更新してください。たとえば、Docs/ の GDD／Phase ドキュメントのヘッダーにある AI 向け注記が現在のテンプレートより古く、references/gdd-template.md に現在組み込まれている build-management への参照が欠けている場合は、整合性を取る作業の一環として、その注記の行を現在のテンプレート文面に更新します。古いドキュメントが、今後のセッションを時代遅れの読書チェーンに誘導し続けてはなりません。
4. 現状を簡潔に言い直します — これまでに完了したこと／現在の Phase／まだテストされていないこと／次のステップを述べてから、作業を続けます。

• Docs/ に GDD がなく、Archive/ に完了済みの GDD（および Archive/As-built.md）がある場合は、前のマイルストーンが完了しています。新しいゲームだと決めつけず、次のマイルストーンを始めるか確認してください。次のマイルストーンでは、Docs/ に新しい GDD（<game>-M<n+1>-GDD.md。次の番号は STEP 5 に従います）を作成し、マイルストーンロードマップの次の枠（その Backlog を含む）と Archive/As-built.md を土台に計画します。（作成前に、記録とワークスペースを照合してください — 下記の 次のマイルストーンの前に照合 を参照。新しい GDD を書くことで、そのロードマップの枠は昇格します。1 行のテーマが GDD に展開され、ロードマップには 1 行のテーマだけが残ります。）
• Phase ドキュメントのライフサイクル：Phase ドキュメントを削除するのは、その Phase が すべて ✅ になったときのみです（その段階でクリーンアップします）。以降は GDD ロードマップがその記録になります。したがって、Docs/ に残っているドキュメントは、現在の Phase と、⏳ user-test boundary で保留中の以前の Phase（項目がまだ 🟡 で、ユーザーのテスト待ちのもの）です。複数が正当に共存する場合もあります。すべての項目が ✅ なのに残っているドキュメントがある場合に限り、クリーンアップ漏れを示します。
• Docs/ のファイルは、セッションをまたぐ信頼できる情報源です。前のセッションのチャットコンテキストは引き継がれないため、GDD／Phase ドキュメントに書かれていない情報は失われます（そのため、決定事項や状態をそこに記録します）。

Docs/ にも Archive/ にも GDD がない場合は、何よりも先にワークスペースを分類してから判断してください。これは明示的な「新しいゲーム」の依頼であっても必須です。ここにすでに作られているものを確認せずに STEP 1 に進んではなりません。（Brownfield とは、ユーザー自身がすでに構築した世界を引き継ぐことです。これはユーザー主導であり、ファイルの存在だけから推測してはなりません。ただし、分類そのものは省略できません。）実際の作業が存在する場合は、それを明らかにしてください。Brownfield をどの程度積極的に提示するかは、ワークスペースではなく、ユーザーの意図（以下を参照）によって決まります。 空ではないワークスペースは、ブラウンフィールドの兆候ではありません。新しいテンプレートにも、すでに足場となるファイルが含まれています。既知のスターター項目は進捗ゼロとして扱ってください（既知の項目であり、網羅的ではありません。テンプレートのバージョンは変わり、テンプレートによっても異なります。これは「足場として知られているもの」であり、完全なマニフェストではありません）：タイルデータセット RectTileData_Henesys、@Logic の UIPopup、UIToast、@Component の Monster、MonsterAttack、PlayerAttack、PlayerHit、テンプレートのモンスターAI FSMサンプル — StateComponent スクリプト StateChaseMonster / StateMoveMonster / StateTypeChase / StateTypeWander、条件スクリプト ConditionHasTarget / ConditionIsAlive / ConditionIsDead / ConditionNoTarget、.stateset の StateSetChaseMonsterAI / StateSetMoveMonsterAI、および Global/ のモンスターモデル ChaseMonster / MoveMonster（これらはすべてテンプレートから RootDesk/MyDesk/ と Global/ に配置され、*Template マップに接続されています。存在していても、ユーザーが構築したモンスターAIではありません）。さらに、常に存在する Global/ のデフォルト項目である DefaultPlayer、WorldConfig、スターターマップも含まれます。

• ワークスペースがスターター項目のみ（またはそれ以下） → 新規プロジェクト → STEP 1へ進み、ブラウンフィールドの確認はしません。
• スターター項目を明らかに超える作業（実装済みのシステム、マップ、データセット、スクリプトを示す独自の名前が付いたもの） → 実際のゲームが進行中の可能性があります。ブラウンフィールドをどの程度強く提示するかは、ワークスペースではなくユーザーの意図で判断します。
  • 続行／「次は何をすればいい？」という意図（「次に何をすればいいですか？」「続けて」「どこまで進めましたか？」）→ 既存の作業を続けるのが自然な解釈です → 推奨オプションとしてブラウンフィールドを提示します（あわせて、別の新しいゲームを始める、または特定のシステムだけを再確認／改善する選択肢も提示します）。
  • 新しいゲームを作る明確な意図（「新しいゲームを作りたいです」）→ その意図を尊重し、新しいゲームをデフォルトの選択肢／推奨の選択肢にします。 ブラウンフィールドは最後の、推奨しない選択肢としてのみ提示します（「……それとも、実際にはすでに構築したワールドを続けるのでしょうか？」）。これは安全策であり、決して推奨せず、ユーザーの依頼を覆す必須の分岐にもしてはいけません。
  • 既存の作業をベースにすると明確に依頼された場合 → そのまま調査に進みます。 ブラウンフィールドのフローは、ユーザーが実際に選択した場合にのみ実行します。

ブラウンフィールドが選ばれた場合、何もない状態から計画を立てないでください。軽い構造調査（map/ と RootDesk/MyDesk/ — システム・モデル・データセット・UI。構造のみを確認し、コードを1行ずつ読むことはしません。詳細な調査は msw-general の役割です）を行い、⚠️confirm を添えて「すでに構築されているものはこちらです。合っていますか？」と提示してください。その後、Archive/As-built.md を作成し、既存のワールドを土台に最初のマイルストーンを計画します（マイルストーンのロードマップは、通常どおりそのマイルストーンのGDDとあわせて作成します — STEP 5）。

次のマイルストーンの前に記録を照合する — Archive/ の記録をもとに新しいマイルストーンを計画する場合（起動時、またはマイルストーンの完了直後に到達した場合）：Archive/As-built.md（または従来の引き継ぎメモ）は出発点となるヒントであり、絶対的な事実ではありません。別のセッションで作業が行われたり、記録を更新しないまま手動編集されたりしている可能性があります。新しいGDDを書く前に、上記のブラウンフィールドと同じ軽い構造調査を行います。ただし、ゼロから把握するためではなく、記録を検証するためです。新しいマイルストーンで触れる領域と、記録が示す内容を照合し、追跡されていないことが明らかな主要システムがないかも手短に確認してください。記録との間にずれがある場合は、まずそれをユーザーに伝えて照合し、現状に合わせて**Archive/As-built.md を更新してから**、その内容を土台に計画を立ててください。これにより、古い前提に基づくGDD全体を書いた後、実装の途中で初めてずれが明らかになる事態を防げます。

フロー

STEP 1 — 質問で方向性を決める（まとめて質問）

ユーザーがすでに伝えた内容は聞き直さず、不足している点だけをまとめて質問します。

1. ジャンル／参考作品 — どんな雰囲気ですか？似ているゲームはありますか？（迷っている場合は、「どんな楽しさを求めていますか？」から始めます）
2. 中心となる楽しさ／コアループ — 1回のプレイで何を繰り返し、プレイヤーは主にどんな操作をしますか（移動、攻撃、収集、建築など）？（例：敵を倒す → 成長する → より強い敵が出現する）
3. 対象・プラットフォーム — PC／モバイル？ソロ／マルチプレイ？
4. スコープ（最初のビルド） — 手早く作るプロトタイプですか、それとももっと大きなものですか？マップ数やコンテンツ量の目安は？
5. 必須要素／削れる要素

質問は5つ程度にまとめます。実際に計画で必要なことを尋ねますが、それ以上に広げないでください（これがユーザーとの大きな接点になるためです）。方向性を決めるうえでの注意点が2つあります。「必須要素／削れる要素」は、通常、multiSelect の質問にするよりも、inputs の自由記述欄（例：「必須／削除可能」欄）にするほうが適しています。これは選択肢で分岐させるものではなく、希望の一覧だからです。また、1回の呼び出しでチャットのピッカーが受け付ける上限（通常は4問）を超える場合は、最初の質問に回答があったらすぐに、残りを後続の呼び出しで尋ねます。シートに載せた質問はすべて、実際に尋ねる必要があります（STEP 5 Web views）。ユーザーが「おまかせ」と言った場合は、妥当なデフォルト設定で進めますが、前提を明示します。これらの質問はウェブの意思決定シートにも載せてください（STEP 5 Web views）。ここはユーザーが最も詳しくない部分なので、「これを選ぶと実際に何が作られ、何が後回しになるのか」が最も重要です。シートには、この質問セットをそのまま反映する必要があります（チャットのピッカーでは1問ずつ案内する場合がありますが、シートでは各質問に対応するコピーが用意されています）。

STEP 2 — カタログに基づく確認と実現可能性の検討

references/genre-catalog.md を読み、次の点を確認します。

• ユーザーのアイデアに最も近いジャンルを特定します。
• そのジャンルの推奨マップタイプとコアメカニクスのタグを確認します。
• ジャンルの MVP: スライスのヒント（最小限のプレイ可能なスライス。スコープを絞った最初のビルドと、STEP 4 のフェーズ1の出発点）および Growth: の拡張軸（完成したコアに通常次に加わる要素。後続のフェーズや今後のマイルストーンに反映）を確認します。ユーザーのアイデアに合わせて調整してください。これらはヒントであり、固定仕様ではありません。
• build-effort のヒント（Low／Medium／High）を読み、ユーザーの意欲と照らし合わせます。開発負荷が高い場合や、ユーザーが一度に多くのものを求めている場合は、その点を率直に伝え、スコープを絞った最初のビルド（1つのマップ・コアループのみ。ジャンルの MVP: ヒントを出発点にします）を提案します。ジャンルにかかわらず、楽しさはそのままにし、残りの要素は後続のフェーズまたはマイルストーンのロードマップに回します。
• 必要に応じてメカニクスのタグを選んで組み合わせ、1行のコンセプトにまとめます。

STEP 3 — 方向性の確認（ユーザー確認ゲート）⚑ 省略しないでください

GDD を作成する前に、必ずユーザーに方向性を確認してください。 根拠となる結果を簡潔に示し、いきなり GDD の作成に進まないでください。ジャンルとマップタイプで構成全体が決まるため、選択を誤って GDD 全体を作成すると、すべてやり直すことになります。

ユーザーに以下を簡潔に提示して質問します。

• おすすめの方向性：合致するサブジャンル（候補を1～2個）＋ おすすめのマップタイプ ↔ Body（例：RectTile + KinematicbodyComponent）＋ 制作工数の目安（Low／Medium／High）＋ コンセプトを一行で。
• 工数が High の場合、またはユーザーのスコープが大きすぎる場合は、範囲を絞った最初の制作版（MVP）も併せて提示します。楽しさはそのままに、最初の制作範囲を小さくし、残りは後続の Phases／マイルストーンロードマップに回します。
• 次に、選択肢を選択可能な形式で提示し（コア原則を参照）、ユーザーに質問します。「この方向性で GDD を作成しますか？ それとも、ほかの候補や変更点はありますか？」
• ユーザーが確認または選択してから、STEP 4 に進みます。（ユーザーが明確に「お任せ」と伝えた場合は、おすすめの方向性を確定し、何を選んだか一行で伝えます。）
• マップタイプ ↔ Body はここで確定します（references/msw-mapping.md）。ここを誤ると、実装時に「動かない」／[LEA-3004] のサイレント障害が発生します。設定時には、すでに該当タイプのマップがある場合は、そのマップを使って制作することで適用します（例：タイプ別テンプレート）。ない場合は、ユーザーが Maker で設定します。AI がマップのタイプを切り替えることはありません（STEP 5 を参照）。

STEP 4 — GDD／ロードマップを作成する

STEP 3 でユーザーが確認した方針に沿って、references/gdd-template.md の構成で Markdown を作成します。 1 行のコンセプト／主要な決定事項の表／コアループ／主要システム／システム↔MSW 対応表／Phase ロードマップのチェックリスト／マイルストーン単位の決定事項。

• システム↔MSW 対応表では、references/msw-mapping.md を使って、各システムを @Logic／@Component／.model／.ui／データセット（UserDataSet）に対応付けます。
• ロードマップは、**最小のプレイ可能なビルド（Phase 1）**から始まる段階に分けます。たとえば「移動して、攻撃して、壊れる」のようにします。該当ジャンルの MVP: のヒント（STEP 2）を Phase 1 の種として使い、Growth: の軸を後続の Phase に反映します。各ロードマップ項目は、3 つの状態（⬜ Not started／🟡 Implemented (untested)／✅ Tested）で管理します（すべて最初は ⬜。状態のルールについては references/build-management.md を参照してください）。
• ロードマップのチェックリストには、引き継ぎ可能なプロトタイプに必須の項目のみを記載し、すべて ✅ に到達させる必要があります。 仕上げ／あると望ましい機能／後回しの作業は、計画時に マイルストーンロードマップ（Docs/<game>-Roadmap.md の将来のマイルストーン枠、またはその Backlog）に記載します。チェックリスト項目にしたり、GDD のどこかに保留したりしてはいけません（「後でやること」の置き場所は 1 つを参照）。判断基準：これを省くと、実装チームに引き継ぐベースが不完全になるか？ → 必須（チェックリスト）。本番制作でいずれ仕上げるものか？ → マイルストーンロードマップ。
• データ量の多いゲームでは、ロードマップに「データ駆動型（UserDataSet／CSV を信頼できる唯一の情報源とする）」と記載します。初期の Phase では速度を優先して値をハードコードしてもかまいませんが、値の種類が増える、または安定した段階で、ハードコードからデータセット（UserDataSet／CSV）への移行を時期ごとに計画します。このマイルストーン内で行う場合は、GDD §6 の後続 Phase のタスクに記載します。このマイルストーンを超える場合は、マイルストーンロードマップの項目（枠または Backlog）に記載します（§7 には参照のみを残します。GDD の文章にだけ意図を書いても、GDD がアーカイブされたときに埋もれてしまいます）。これにより、バランス調整やコンテンツ追加のたびにコードを編集する必要がなくなります。この項目を含めるのは必要な場合のみです（調整可能な値が多い、バランス調整の反復が見込まれる、コンテンツの拡張がある場合）。定数が少数しかない場合は含めません。データセット自体は msw-general を使って作成します（references/dataset.md を参照）。
• GDD を保存する前に、網羅性を確認します：§6 の Phase 全体で、§1 の 1 行コンセプト（M2 以降では、昇格させたロードマップ枠の項目も）を実現できる必要があります。それらの行で約束している機能を 1 つずつたどり、実装するチェックリスト項目に対応付けてください。対応する項目のない主張は計画上の漏れであり、後続のルールでは検出できません（計画されていないタスクには ⬜ が付かないためです）。検証の制約によってスコープを縮小してはいけません：AI が単独で検証できないフロー（実際のマルチプレイヤーマッチ、デバイス上での操作感、コマース）も、タスクとして計画します。最終状態は単に 🟡 needs-user-test になります。自動検証できないことを理由に、黙って除外してはいけません。代わりに、ユーザーがその機能の除外に同意した場合は、§1／ロードマップ枠の記載を修正し、ドキュメントでその機能を約束しないようにします。
• プロジェクトにプレースホルダー／サンプルのエンティティが含まれる場合：プロトタイプを本格実装に引き継ぐ前にそれらを削除するタスクを含め、実際のビルドに残らないようにします。対象は選択したビルドマップだけでなく、プロジェクト全体です。プロジェクト内のどのマップにも、個別のサンプルが含まれている可能性があります（テンプレート由来のマップには含まれることがよくありますが、サンプルがない場合もあります）。そのため、このタスクの完了条件は「すべてのマップを検査し、クリーンな状態にすること」です。まずすべてのマップを列挙（map/ の完全な一覧を作成）し、その後で各マップを検査します。1 つのマップをスキャンして問題がなかったとしても、他のマップまで問題がない証拠にはなりません。名前が固定だと決めつけず、各マップのサンプルを検査して特定してください（多くの場合、*Template という名前の待機／移動／追跡モンスターのサンプルですが、名前はテンプレートによって異なります）。初期段階では AI のパターンを参照するのに役立ちます。実際の削除は実装時に MapBuilder で .map から行います。使用していないテンプレートマップも引き継ぎ時に残る不要物です：引き継ぎ時に、ゲームで使用しないテンプレートマップを削除するか残すか、それぞれユーザーに確認します（確認なしに削除してはいけません）。サンプルを整理する前に、削除するかどうかを決めてください（削除予定のマップを整理しないためです）。その後、「すべてのマップをクリーンな状態にする」という条件は、残すマップに適用されます。

STEP 5 — 保存と次のステップ

• 作成した Markdown を、プロジェクトルートの Docs/ の下に Docs/<game>-M<n>-GDD.md として保存します。<game> は短い ASCII（英語／ローマ字表記）のスラッグです（元の非英語タイトルをそのまま使わないでください。CJK／非 ASCII のファイル名は glob とクロスプラットフォームのパスで問題が起きます。例：MapleIdle-M1-GDD.md。元の CJK タイトルは使いません）。<n> はマイルストーン番号です。マイルストーン番号：最初のマイルストーンは M1 です。後続のマイルストーンでは、Docs/ と Archive/ にある既存の -M<n>-GDD.md のうち、数値として最も大きい番号に 1 を足します。番号は辞書順ではなく数値として解析してください（M9 の次は M2 ではなく M10 です）。ドキュメントの内容はユーザーの言語のままにし、ASCII にするのはファイル名だけです。フェーズドキュメントにも同じ <game>-M<n>- プレフィックスを付けます（STEP 6）。計画成果物（GDD・フェーズ詳細計画）はすべてここにまとめます。フォルダーがなければ作成してください。ファイルとして保存しておけば、実装スキルが引き継いで MVP まで進められます。
• ⚠️ RootDesk/ の下には保存しないでください。 Maker の refresh_workspace は RootDesk/ の下にある MSW 以外のファイル（.md など）をクリーンアップ（削除）するため、実装／プレイテスト中に refresh が実行されると、そこに保存したファイルは消えてしまいます。必ず RootDesk/ の外（プロジェクトルートの Docs/）に保存してください。
• M1 の GDD と一緒にマイルストーンロードマップを作成します — Docs/<game>-Roadmap.md（名前に M<n> は含めません。ゲームごとに 1 つ作成し、恒久的に保持してアーカイブしません）。references/gdd-template.md の 「Milestone roadmap template」に従ってください。1 行のビジョンとリリース基準（ゲームをリリース可能と判断するために満たすべき条件。機能の羅列ではありません）、マイルストーンごとに 1 つの枠（M1 は現行 GDD へのポインター、今後の M は 1 行のテーマと割り当て済み機能）、および未割り当ての希望項目をまとめる Backlog を記載します。最初のビルドから STEP 2〜3 で除外した項目（成長軸・縮小した機能・ユーザーの「後で」という希望）はすべて、今後の枠または Backlog に振り分けてください。ゲームの規模に合わせてください。マイルストーンが 1 つだけのゲームなら、ロードマップは数行（M1 = リリース）で十分です。後続のマイルストーン（M2 以降）では、新規作成せず、既存のロードマップを更新します（該当する枠を昇格させます）。
• Web ビュー — 意思決定シート：このスキルには、固定 HTML フォーム（assets/msw-decision-sheet.html）と、これをデプロイしてローカルで提供するパッカー（assets/build-status-data.cjs）が含まれています。Web 関連の成果物はすべて Docs/web/ の下に置きます。プロジェクトルートにも RootDesk/ にも置かないでください。
  • いつ開くか — ゲームの方向性を左右する判断の場面：STEP 1 のまとめて質問する項目・STEP 3 の方向性確認・中核的な判断の分岐（マップの種類／モード／スコープ）・マイルストーンの Backlog の確認です。単純な確認（ソフトな Phase ゲート、「次に Phase 1 を書きますか？」など）には使いません。
  • ⚠️ Docs/web/decision-data.json を作成する前、またはパッカーを実行する前に、references/decision-sheet.md を最初から最後まで読んでください — データスキーマ、使用中のエージェントでビューを開く方法（シェルごとのアプリ内ペインと OS ブラウザーの使い分け）、シートとチャットの内容にずれが生じないようにするルール、想定される貼り付け形式、失敗時の状態が記載されています。記憶を頼りにゲートを作ると、両者の内容にずれが生じます。
  • 読む前でも適用される不変条件：HTML フォームとパッカーは固定アセットです。編集しないでください。 一方、decision-data.json は作成してかまいません（ゲートごとに新規作成し、その後は手動編集せず、計画の入力として読み戻さないでください。Markdown を唯一の信頼できる情報源とします）。シートは情報の提示と回答の収集のみを行うため、回答は必ずチャット上で行います。また、ブラウザーを開けない場合でもフローを決して止めないでください。
  • 回答が得られたらゲートを閉じます — 回答を受け取り、内容に反映したら、Docs/web/decision-data.json を削除してください。シートを再度開ける状態のままにすると、すでに決定した質問に対して 2 回目の回答を招くおそれがあります。
• ベース GDD が完成したら、まず自然な流れで提案します：「次に Phase 1 の詳細計画を書きましょうか？」→ ユーザーが同意した場合は、そのまま STEP 6 に進みます。
• ほかに提示する分岐：数値／データが中心ならデータセット設計へ、画面が中心なら msw-ui-system で UI を作成します。すぐに実装する場合は、msw-general・msw-scripting で実装を開始します。推奨される標準フローは「Phase 1 を詳細化 → 実装」です。
• マップの種類を適用する — 一致するマップがあればそのマップで作成し、なければユーザーに設定してもらいます：プロトタイプは、TileMapMode が決定した種類とすでに一致しているマップで作成する必要があります。セットアップ時に MapBuilder.read().getTileMapMode() で既存のマップを確認し、その後、次のように進めます。
  • 一致するマップがすでにある場合 — たとえば、プロジェクトにマップの種類ごとのテンプレートマップ（TileMap／RectTile／SideView が各 1 つずつ）が用意されている場合 — そのマップでプロトタイプを作成します。切り替えは不要です（破壊的な切り替えを回避できます）。この近道が使えるのは、一致するマップ／テンプレートが存在する場合に限ります。
  • 一致するマップがない場合 — 種類ごとのテンプレートがない場合、または新規に始める場合 — 標準方針に従います。ユーザーが Maker でマップの種類を切り替え（msw-general tile.md）、その後 AI が getTileMapMode() で確認します。
  • いずれの場合も、AI がマップの TileMapMode を切り替えることはありません。（テンプレートで作成した場合、後でクリーンアップ規則に従い、サンプルの *Template エンティティを削除します。）
  • テンプレートを使う場合は、ビルド用マップの名前を早い段階で変更します：プロトタイプを *Template という名前のマップに配置する場合、実際の作成作業を始める前に、Phase 1 のタスクとしてゲームに合った ASCII 名に変更する計画を立てます。フェーズが進むにつれてマップ参照（セクター登録・ポータル・GetEntityByPath のパス・アクティブマップ）が増えるため、Phase 1 での改名はほぼ手間がかかりませんが、引き継ぎ時にはコストが高くなります。また、ゲームが *Template という名前のマップにあると、このスキル自体が依存するテンプレートとゲームの分類を乱します。完了条件：ファイル名を変更し、すべての参照を更新して、refresh を実行し、エントリーを確認します。仕組みは実装スキルで扱います。参照が読み取り専用の設定（Global/）にある場合、その部分はユーザーが Maker で操作します — TileMapMode の切り替えと同じ方針です。
  • 作成開始前にアクティブマップを対象マップに切り替えます（上記のどちらかでマップが確定した後）：maker_move_map を使って、Maker のアクティブ（開いている）マップを対象マップに移動します（AI が実行できます）。これにより、エンティティ／タイルの編集とスクリーンショットが正しいマップに保存されます。（これは禁止されている TileMapMode の切り替えではありません。）黙って省略しないでください。省略すると、作業対象のマップが間違ってしまいます。

STEP 6 — （任意）フェーズごとの詳細計画

基本出力（STEP 4）は、ロードマップ全体とフェーズごとのチェックリストまでです。ユーザーが特定のフェーズの詳細計画（例：「Phase 1 の詳細計画を書いて」「ステージ 1 を細分化して」）を求めた場合は、そのフェーズのチェックリストをさらに詳しく展開した詳細計画の Markdownを追加で生成します。

• 各タスクについて、目標 · 必要なシステム／コンポーネント（references/msw-mapping.md）**· データ（UserDataSet）· UI · 完了（検証）基準 · 依存関係 · 参照するスキル（予測 — スキルとその参照ドキュメント、references/msw-mapping.md §4）を記載します。また、実装セッションで最初に読むよう、フェーズのドキュメントの上部付近に「参照するスキル（このフェーズ）」**の概要も記録します。
• タスクと併せてステータスチェックリストを生成します。各項目は Not started から始まり、作業の進行に応じて次の 3 つの状態に移行します。
  • ⬜ Not started — まだ実装されていません。
  • 🟡 Implemented (untested) — 実装は完了していますが、検証はまだです。
  • ✅ Tested — 実装と検証の両方が完了しています。
• references/gdd-template.md の**「フェーズごとの詳細計画テンプレート」**に従います。
• 保存先：Docs/<game>-M<n>-Phase<k>.md（マイルストーンの GDD と同じ <game>-M<n>- のプレフィックスを使用します — STEP 5 を参照。<k> = フェーズ番号。プロジェクトルートの Docs/ 内、RootDesk の外 — 更新時に削除されないようにします）。
• ここでも作成するのは詳細計画までです。実際のコード（.mlua/.model など）の作成は、引き続き実装スキル（msw-general/msw-scripting など）の担当です。これらのスキルは、実装と検証に応じてチェックリストの状態を更新します。

ビルド管理（実装時のルール）→ references/build-management.md

計画を実行するためのルール一式 — タスク状態の管理、フェーズ／マイルストーンの完了手順、開発途中の計画改訂 — は**references/build-management.mdに記載されています。計画済みタスクの実装、チェックリストの状態更新、フェーズまたはマイルストーンの完了、あるいは計画の改訂を行う前に、必ず全文を読んでください**（純粋な計画セッションでは読む必要はありません）。**厳守：⬜/🟡/✅ マーカーを編集しようとしている、フェーズ／マイルストーンを完了しようとしている、または計画ドキュメントをアーカイブ／削除しようとしているとき、このセッションで references/build-management.md を全文読んでいない場合は、作業を止めて、まず読んでください。**この SKILL.md を読み込んでいること（または以前のセッションで参照ドキュメントを読んでいること）は、その代わりにはなりません。記録の破損につながるため、ここで再掲する変更不可の原則：

• 状態として使えるのは ⬜ / 🟡 / ✅ のみです。フェーズのドキュメントでタスクごとに直ちに更新してください。最後にまとめて更新すること、一時的なツール内だけで更新すること、独自のマーカーを作ることは禁止です。
• フェーズ完了とマイルストーン完了では、それぞれ必須のクリーンアップ手順を実施します（完了したステージ · マイルストーン完了：状態を GDD §6 に反映 → As-built → ロードマップ → 削除／アーカイブ）。この手順を実施せずにフェーズのドキュメントを削除したり、GDD をアーカイブしたりしてはいけません。完了の判定基準はチェックリストだけでなく、マイルストーンに記されたビジョンです。マイルストーン完了手順では、最初にビジョンの網羅性を確認します。残りの項目がすべてユーザーテスト待ちのマイルストーンは ⏳ user-test pending であり、「完了」ではありません。独自のラベルを作ることも禁止です。
• 計画変更の依頼は、そこで定められた改訂フローに従います。現在のマイルストーンを超える作業は、マイルストーンのロードマップに直接追加します。意図的にスタブ化またはブロックしたコードパスには、作成した時点で追跡対象の項目を追加する必要があります。

範囲（このスキルでは行わないこと）

• 実際のコード（.mlua/.model/.map/.ui）は記述しません。それは実装スキルの担当です。このスキルでは、ゲームのマイルストーン全体にわたるビルドを計画・管理し（GDD · マイルストーンのロードマップ · 詳細なフェーズ計画 · 進捗の追跡 · 計画の改訂）、コード作業を msw-general/msw-scripting などに引き継ぎます。
• すでに構築・リリース済みのワールドの大規模な改善・拡張は対象外です（このスキルでは、ゲームのビルドを、実装を全面的に開始できる状態になるまで計画します。対象は新しいゲームと、その後の各マイルストーンです）。
• MSW プラットフォームのルール（map-type↔Body、1 unit = 100px、SpriteRUID など）を計画に反映します。ただし、実装の正確なルールについては msw-general のプラットフォームリファレンスに従ってください。

リファレンス

• references/genre-catalog.md — 3 種類のマップ · ビルド工数の基準 · 71 種類のジャンル（ビルド工数の目安 · 推奨マップタイプ · 中核となるメカニクス · ジャンルごとの MVP:/Growth: のヒント行） · 約 180 種類のメカニクスタグ。計画の根拠となる中心的な資料です。STEP 2 では必ず読んでください。
• references/decision-sheet.md — Web の意思決定シート：データスキーマ · エージェント／シェルごとのビューの開き方 · シートとチャットの照合ルール · 3 種類の貼り付け形式 · 失敗状態。ゲートの decision-data.json を作成する前に、全体を読んでください（ゲートを開かない場合は不要です）。
• references/gdd-template.md — GDD の出力構成 + マイルストーンロードマップのテンプレート（STEP 5）+ フェーズごとの詳細計画テンプレート（STEP 6）+ As-built ログのテンプレート。
• references/build-management.md — 実装時のルール：タスク状態の管理 · フェーズ／マイルストーン完了時のクリーンアップ · 計画改訂の手順。タスクを実装する前、またはチェックリストの状態を変更する前に、全体を読んでください（計画のみの場合は不要です）。
• references/msw-mapping.md — map-type↔Body の対応表 + ゲームシステムから MSW コンポーネント／スキルへの対応表。