msw-planning

MSW 新游戏规划模式（msw-planning）

用途

当用户处于“我想做一款这样的游戏”的阶段时，将想法转化为要构建什么 + 如何在 MSW 中构建：通过引导式会话产出一份GDD/路线图，然后此技能会引导分阶段构建——制定详细的阶段计划、跟踪进度并修订计划——直至每个里程碑的构建准备好进入完整实现阶段。不了解游戏设计的用户只需跟着问题回答；有经验的用户则可以借此快速记录决策。

核心原则（这样设计的原因）

• 以目录为依据：MSW 是 2D、使用 mLua（一种 Lua 扩展脚本语言）且支持跨平台，因此“可以构建什么”的范围是有限的。将模糊的想法对应到 references/genre-catalog.md 中真实存在的游戏类型、地图类型和机制，以制定可行的计划。仅凭通用游戏知识进行规划，可能会设计出 MSW 无法实现的内容。
• 合理确定构建规模：目录为每种游戏类型提供了构建工作量提示（低 / 中 / 高）——这只是参考信号，不是最终结论（基准为 1–5 张地图、10–20 个单位/物品、基础到中级 mLua；塔防是最适合单人舒适开发的类型中工作量最高的）。用它设定预期，而不是拒绝某种游戏类型。首次构建的规模应根据**构建工作量 + 范围（地图/内容）**确定，绝不能依据日历或开发时间估算——此技能无法了解用户的技能水平或可投入时间，因此不会承诺“需要 N 天/周”。当用户的目标较大时（高工作量类型、系统/地图众多，或用户表示“我什么都想要”），不要一次性规划全部内容——将首次构建的范围缩小为一个小型可玩核心（MVP），其余内容留到后续阶段。这适用于任何游戏类型。
• 一次完成（避免反复拉扯）+ 一次方向确认：将用户需要参与的环节限制在步骤 1（批量提问）和步骤 3（方向确认）——中间不要反复追问。但编写 GDD 前绝不能跳过步骤 3（方向确认）：不要只展示依据目录得出的结果就直接开始写 GDD。方向确认后，立即产出交付物。
• 标准化交付物：按照固定的 GDD 结构（references/gdd-template.md）以 Markdown 形式记录结果，让实现技能能够接手并将其推进至 MVP。
• “以后再做”的唯一归属：GDD 只涵盖其自身里程碑。任何超出范围的内容——删减的功能、后续里程碑的想法，或讨论中途提出的“以后再做”请求——都要在出现时立即记录到现有的里程碑路线图（Docs/<game>-Roadmap.md：时间已定时放入未来里程碑栏，时间未知时放入 Backlog），绝不放进 GDD。各有归属，互不重复：路线图负责当前里程碑以外的一切；GDD 负责当前里程碑范围内的一切。
• 推动项目继续前进：每份交付物完成后，先提出下一步建议（例如：“接下来要我编写 Phase 1 的详细计划吗？”）。用户愿意就继续，用户要求停止就停下——这是建议，不是催促。（这不同于在文档编写过程中无休止地反复确认；它负责衔接不同交付物之间的流程。）
• 决策关卡 = 可选选项，而非自由文本：在每个用户决策关卡——步骤 3 的方向确认、阶段交接（立即实现还是编写下一阶段计划）以及软性阶段关卡——都应在可用时通过 Agent 的多选 UI（例如 Claude Code 的 AskUserQuestion）提供结构化可选项，让用户点击选项，而不是输入自由文本。标明推荐选项，但不要强迫用户选择；如果 Agent 没有此类 UI，则改用清晰编号的文字选项。会影响设计的决策关卡还要打开网页决策页（步骤 5 Web 视图），让用户在选择前了解各个选项实际会构建什么。

启动时 — 检查是否存在 GDD（恢复 / 新建 / 受阻）

一次构建会跨越多个会话和里程碑 — 每个里程碑对应一个 GDD。文件位置（均在项目根目录下、RootDesk 之外，以便在 refresh_workspace 后保留）：

• 当前 GDD + 阶段计划 → Docs/。
• Docs/<game>-Roadmap.md → 游戏的常设里程碑路线图（愿景 · 发布标准 · 每个里程碑一个位置 · 待办事项）：确定跨里程碑的方向，与 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/）— 获取目录级列表，返回其中的所有内容（例如，使用 Agent 的文件列表工具 / Glob 和 Docs/*）— 然后根据该列表自行匹配以 -GDD.md / -Phase<N>.md 结尾的名称。不要通过缩小范围的模式或内容搜索来检测（*-GDD.md glob 或 grep 会区分大小写且范围脆弱：*.md 只匹配顶层文件，docs/ ≠ Docs/ — 漏检会被悄悄当作“没有 GDD”），也不要凭记忆判断。
• 只有在 Docs/ + Archive/ 的列表确实为空时，才能得出**“任何地方都没有 GDD”**的结论。
• 如果存在 Archive/As-built.md，先读取它以了解当前状态图；如果存在 Docs/<game>-Roadmap.md，则一并读取以了解跨里程碑方向（切勿将其误认为当前 GDD）。
• 通常最多只有一个当前 GDD；如果存在多个，先询问用户当前讨论的是哪个游戏，然后再应用以下规则。

门控规则 — 只有 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 一同创建，因此会随之放弃——若将其留存，它会把已放弃游戏的方向带入下一次规划会话）——仅限这些文件——删除它们，然后从第 1 步重新开始。
• 任何项为 🟡 或 ✅——或者 GDD 中所有项都是 ⬜，但该游戏存在先前里程碑（Archive/ 中有同一 <game> 的 GDD，或编号为 M2+）——也就是说，这个世界中已经有正在进行或已构建的实现 → 不要在此处放弃计划，也不要规划新游戏。告知用户这个世界中已经有一个正在制作的原型；真正的新游戏必须在新世界中构建——此技能无法创建世界，因此用户需创建一个世界并在其中运行此技能——然后停止。（如果用户实际想继续当前游戏，则恢复即可。在 Archive/As-built.md 的基础上修改一个零进展的下一里程碑计划，属于计划修订——仍然是这款游戏，绝不是新游戏。）
• 状态不明确时（缺少阶段文档、阶段文档不一致、进度含糊）→ 按 🟡/✅ 情况处理（不要放弃计划，也不要在其基础上构建）。 恢复现有计划：

1. 先阅读现有文档——Docs/<game>-M<n>-GDD.md（以及所有现存的 Docs/<game>-M<n>-Phase<k>.md；由于较早的阶段可能在等待用户测试，因此可以同时存在多个阶段文档，而且它们的检查清单可能包含 §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 现在内置的构建管理指引），请在协调文档时将该说明行更新为当前模板文本；不要让旧文档继续引导未来会话走过时的阅读链。
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 会提升该路线图槽位：其中的一行主题会扩展为 GDD；路线图中仍只保留这一行。）
• Phase 文档的生命周期：只有当某个 Phase 的所有条目都为 ✅ 时，才删除该 Phase 文档（这是该阶段的清理工作）；此后由 GDD 路线图记录该阶段。因此，Docs/ 中仍存在的文档包括当前 Phase，以及任何处于**⏳ user-test boundary**（条目仍为 🟡，正在等待用户测试）的较早 Phase；多个文档同时存在是正常的。如果某个遗留文档的所有条目都已是 ✅，这是唯一表明遗漏了清理工作的情况。
• Docs/ 文件是跨会话的事实来源：上一个会话的聊天上下文不会延续，因此任何未写入 GDD／Phase 文档的内容都会丢失（因此决策和状态都要记录在其中）。

Docs/ 和 Archive/ 中都没有 GDD → 在做任何其他事情之前，先对工作区分类，再作决定——这是强制要求，包括用户明确要求“新游戏”时：务必先检查这里已经构建了什么，绝不能直接跳到 STEP 1。（既有项目 = 继续用户自己已经构建的世界；这由用户驱动，绝不能仅凭文件存在就推断——但分类本身不是可选项。）如果确实已有成果，要明确指出；之后是否以及多大程度上提供既有项目选项，则根据用户的意图（见下文）决定，而不是根据工作区决定。 非空工作区并不代表这是棕地项目——新建模板本身就包含脚手架。将已知的初始项目视为零进展（已知集合，并不完整——模板版本会变化，其他模板也有所不同；这里列出的是“已知的脚手架内容”，并非完整清单）：瓦片数据集 RectTileData_Henesys；@Logic 下的 UIPopup、UIToast；@Component 下的 Monster、MonsterAttack、PlayerAttack、PlayerHit；模板中的怪物 AI 状态机示例——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；只检查结构，不逐行阅读代码；深入检查由 msw-general 负责），然后展示*“这是我看到的已构建内容——对吗？”*，并要求⚠️confirm，接着填充 Archive/As-built.md，并在现有世界的基础上规划第一个里程碑（照常在该里程碑的 GDD 中创建里程碑路线图——STEP 5）。

规划下一个里程碑前先核对——在基于 Archive/ 记录规划新里程碑时（无论是启动时读取，还是刚完成一个里程碑后）：Archive/As-built.md（或旧版交接说明）是起始参考，而非事实依据——其他会话中或手动编辑时可能已经有进展，却没有更新记录。编写新 GDD 前，执行与上文棕地流程相同的轻量结构调查，但目的是核实记录（而非从头发现）：检查新里程碑涉及的区域，并快速扫描是否存在明显未记录的重要系统，对照记录中的描述。如果记录已经过时，先向用户说明并核对，更新 Archive/As-built.md 以符合实际情况，然后再基于现状规划。这样可避免基于过时前提编写整份 GDD，却直到实施中途才发现偏差。

流程

步骤 1 — 引导式提问（分批）

不要重复询问用户已经提供的信息；只针对尚缺的信息分批提问：

1. 类型 / 参考作品 — 想要什么感觉？有没有类似的游戏？（如果不确定，可以先问“想要哪种乐趣？”）
2. 核心乐趣 / 核心循环 — 一次游戏过程中会反复做什么？玩家的主要操作是什么（移动、攻击、收集、建造……）？（例如，击败敌人 → 成长 → 遭遇更强的敌人）
3. 目标平台 · 游玩方式 — PC / 移动端？单人 / 多人？
4. 范围（首个版本） — 快速原型还是更大型的项目？大致需要多少张地图 / 多少内容？
5. 必备项 / 可删减项

将问题控制在约 5 个以内——询问计划实际需要的信息，但别把问题批次拉得太长（这是用户唯一一次集中参与的机会）。有两点需要注意：“必备项 / 可删减项”通常更适合作为 inputs 自由文本字段（例如“必须有 / 可以舍弃”输入框），而不是 multiSelect 问题——它是一份愿望清单，而非二选一；如果这一批的问题超过聊天选择器单次调用可处理的数量（通常是 4 个），请在用户回答第一批问题后，立即通过后续调用询问剩余问题——表单上的每个问题都必须实际问到（步骤 5 Web 视图）。如果用户说“你来决定”，就采用合理的默认设置，但要说明这些假设。也要在 Web 决策表中提出这些问题（步骤 5 Web 视图）——用户对此最不了解，因此“选择这个实际上会构建什么，又会推迟什么”最为重要；表单必须与这一批问题完全一致（聊天选择器之后可以一次引导用户回答一个问题——表单会为此提供每个问题对应的副本）。

步骤 2 — 基于目录核实方向 + 可行性检查

阅读 references/genre-catalog.md，并：

• 找出与用户想法最接近的类型。
• 提取该类型的推荐地图类型和核心机制标签。
• 提取该类型的 MVP: 切片提示（最小可玩切片——作为缩小范围后的首个版本和步骤 4 阶段 1 的起点），以及 Growth: 发展方向（成熟核心通常会接下来加入什么——为后续阶段和未来里程碑提供参考）。根据用户的想法调整这些提示；它们只是参考，并非固定规格。
• 查看 build-effort 工作量提示（Low / Medium / High），并评估用户的目标。如果工作量为 High，或用户一次提出了很多要求，请直言说明，并提议缩小首个版本的范围（一张地图 · 仅包含核心循环——从该类型的 MVP: 提示开始），保留相同的乐趣，其余内容安排到后续阶段或里程碑路线图中——不论游戏类型如何。
• 如有需要，挑选并组合机制标签，概括为一行创意描述。

步骤 3 —— 确认方向（用户确认关卡）⚑ 不要跳过

编写 GDD 前，务必先让用户确认方向。 简要展示依据分析结果，不要直接开始编写 GDD——类型和地图类型会决定整个方案；如果方向选错后写完了整份 GDD，就得全部重做。

简要介绍并询问用户：

• 推荐方向：匹配的 子类型（1–2 个候选）+ 推荐地图类型 ↔ Body（例如，RectTile + KinematicbodyComponent）+ 构建工作量提示（低/中/高）+ 一句话概念。
• 如果工作量较高或用户的范围定得过大，同时提供一个缩小范围的首个构建版本（MVP）选项——保留相同的乐趣，但缩小首个阶段的内容，其余部分安排到后续阶段／里程碑路线图中。
• 然后询问，并将选项作为可选项列出（参见核心原则）："要我按这个方向编写 GDD 吗？还是你有其他候选方案／想做哪些调整？"
• 只有在用户确认（或选择）后才能进入步骤 4。（如果用户明确表示“由你决定”，就确定采用推荐方案，并用一句话说明你的选择。）
• 在此确定地图类型 ↔ Body（references/msw-mapping.md）。选错会导致实现时出现“无法移动”／[LEA-3004] 静默故障。设置时，应在已有此类型地图的情况下，基于该地图进行构建（例如，按类型提供的模板）；否则由用户在 Maker 中设置。AI 绝不会自行更改地图类型（参见步骤 5）。

步骤 4 — 编写 GDD/路线图

按照用户在步骤 3 中确认的方向，按 references/gdd-template.md 的结构编写 Markdown： 一句话概念 / 关键决策表 / 核心循环 / 核心系统 / 系统↔MSW 映射 / Phase 路线图检查清单 / 按里程碑划分的决策。

• 对于系统↔MSW 映射，请使用 references/msw-mapping.md，将每个系统关联到 @Logic/@Component/.model/.ui/数据集（UserDataSet）。
• 将路线图拆分为多个阶段，从最小可玩版本（Phase 1）开始，例如“移动、攻击，并摧毁目标”。匹配类型的 MVP: 提示（步骤 2）是自然的 Phase 1 起点；其 Growth: 方向则可作为后续 Phase 的参考。每个路线图项目均使用三种状态进行跟踪——⬜ Not started / 🟡 Implemented (untested) / ✅ Tested（初始状态均为 ⬜；状态规则 → references/build-management.md）。
• 路线图检查清单只包含交接给完整实现团队所需的原型必备项目——并且所有项目都必须达到 ✅。 润色 / 可有可无 / 后续工作应在规划时放入里程碑路线图（Docs/<game>-Roadmap.md — 未来里程碑条目或 Backlog），绝不能作为检查清单项目，也绝不能放在 GDD 的任何位置（参见 “后续工作”的唯一归属位置）。判断标准：移除它会让完整实现团队拿到的基础版本更不完整吗？ → 必需（检查清单）；制作过程中本来就会完善它吗？ → 里程碑路线图。
• 对于数据量大的游戏，请在路线图中注明“数据驱动（UserDataSet/CSV 是事实来源）”。早期 Phase 可为提高速度而硬编码数值；但数值集增长或稳定后，应按时间范围规划从硬编码迁移到数据集（UserDataSet/CSV）：在本里程碑内完成 → 作为 GDD §6 中后续 Phase 的任务；超出本里程碑 → 作为里程碑路线图条目（条目或 Backlog；§7 仅保留指针——只写在 GDD 正文中的意图会在 GDD 归档时被埋没），这样调整平衡/内容时就不再需要修改代码。仅在确有必要时纳入此项（有许多可调数值 · 预计需要反复调整平衡 · 内容规模会扩大），少量常量无需如此。数据集本身通过 msw-general 编写（参见其 references/dataset.md）。
• 保存 GDD 前进行覆盖检查：§6 的各个 Phase 合起来必须实现 §1 中的一句话概念（对于 M2+，还要实现已纳入计划的路线图条目）；将这些内容声称具备的每项能力追溯到负责实现它的检查清单项目。没有对应项目的承诺就是规划漏洞，后续规则无法发现（未规划的任务不会留下 ⬜）。验证限制不能缩小范围：AI 无法独自验证的流程（真实多人对局、设备上的操作手感、商业化）仍须规划为任务——它们最终只会标记为 🟡 needs-user-test——绝不能因为无法自动验证就悄悄省略。如果用户同意排除某项已承诺的能力，则应改写 §1 / 路线图条目，让文档不再承诺该能力。
• 如果项目包含占位/示例实体：请加入一项任务，在原型移交给完整实现团队之前将它们移除，以免进入正式构建。范围 = 整个项目，而不只是选定的构建地图——项目中的任何地图都可能带有自己的示例（基于模板创建的地图通常如此；有些则没有），因此任务的完成标准是“检查并清理每一张地图”：先列出所有地图（完整的 map/ 目录列表），再逐一检查；扫描一张地图后确认无示例，不能作为其他地图也无示例的依据。不要假定名称固定——通过检查识别每张地图中的示例（通常是以 *Template 命名的待机/移动/追逐怪物示例，但名称因模板而异）。这些示例在早期可用作 AI 模式参考；实际删除应在实现期间由 MapBuilder 从 .map 中移除。未使用的模板地图也属于交接残留：移交时，询问用户是否删除或保留游戏未使用的每张模板地图（未经确认绝不删除）——并且应在清理示例之前做出决定（不要清理即将删除的地图）；“每张地图都已清理”的要求仅适用于最终保留的地图。

步骤 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 → M10，而不是 M2）。文档内容保持用户使用的语言；只有文件名使用 ASCII。阶段文档沿用相同的 <game>-M<n>- 前缀（步骤 6）。将所有规划交付物（GDD · 阶段详细计划）收集到这里。若文件夹不存在，则创建它。将其保留为文件后，实现技能便可读取并推进到 MVP。
• ⚠️ 不要保存在 RootDesk/ 下。 Maker 的 refresh_workspace 会清理（删除）RootDesk/ 下非 MSW 文件（如 .md），因此在实现／游戏测试期间运行刷新时，这些文件会消失。始终将它们保存在 RootDesk 之外（项目根目录下的 Docs/）。
• 创建 M1 GDD 时，同时创建里程碑路线图——Docs/<game>-Roadmap.md（名称中不含 M<n>；每个游戏一份；永久保留，绝不归档）。遵循 references/gdd-template.md 中的**“里程碑路线图模板”：一行愿景** + 发布标准（要满足什么条件才能称游戏可发布——写标准，而不是罗列功能）、每个里程碑占一栏（M1 = 指向当前 GDD；未来的 M = 一行主题 + 已分配的功能），以及一个用于收录想做但尚未分配项目的待办事项。将步骤 2–3 从首个版本中删去的所有内容（成长维度 · 精简掉的功能 · 用户提出的“以后再做”需求）整理到未来里程碑或待办事项中。根据游戏规模调整：只有一个里程碑的游戏，路线图只需几行（M1 = 发布）。后续里程碑（M2+）不要重新创建路线图——更新现有路线图（将对应栏位升级）。
• 网页视图——决策表单：该技能附带固定的 HTML 表单（assets/msw-decision-sheet.html）以及打包脚本（assets/build-status-data.cjs），用于部署该表单并在本地提供服务。所有网页产物都放在 Docs/web/ 下——绝不放在项目根目录或 RootDesk/ 中。
  • 何时打开——会影响游戏方向的决策关口：步骤 1 的批量提问 · 步骤 3 的方向确认 · 核心决策分支（地图类型／模式／范围）· 里程碑待办事项审查。简单确认则不需要（例如轻量的阶段关口、“接下来要写阶段 1 吗？”）。
  • ⚠️ 在编写 Docs/web/decision-data.json 或运行打包脚本之前，请完整阅读 references/decision-sheet.md——其中包含数据架构、如何在你的 Agent 中打开视图（应用内窗格或 OS 浏览器，按 shell 区分）、避免表单与聊天内容脱节的规则、预期的粘贴格式，以及故障状态。凭记忆创建决策关口，会导致两者脱节。
  • 即使尚未阅读该文件，也必须遵守以下不变规则：HTML 表单和打包脚本都是固定资源——绝不编辑；decision-data.json 由你编写（每个决策关口都要重新生成，之后不得手动编辑，且绝不能将其读回作为规划输入——Markdown 始终是唯一事实来源）；表单只负责说明和收集，因此答案始终在聊天中给出；如果浏览器无法打开，流程也绝不能因此受阻。
  • 回答后关闭决策关口——收到并落实答案后，删除 Docs/web/decision-data.json，否则再次打开的表单可能会让用户对已决定的问题再次作答。
• 基础 GDD 完成后，先自然地提出建议：“接下来要写 阶段 1 详细计划吗？”→ 如果用户同意，直接进入步骤 6。
• 还可以提供其他分支：如果内容涉及大量数字／数据，则转向数据集设计；如果涉及大量屏幕，则使用 msw-ui-system 编写 UI；如果要立即构建，则使用 msw-general·msw-scripting 开始实现。默认推荐流程是“细化阶段 1 → 实现”。
• 应用地图类型——如果存在匹配地图，则在该地图中构建，否则由用户设置：原型必须在 TileMapMode 已与确定类型相同的地图中构建。设置时，使用 MapBuilder.read().getTileMapMode() 检查现有地图，然后：
  • 如果已有匹配的地图——例如项目为每种地图类型都保留模板地图（各有一个 TileMap / RectTile / SideView）——就在该地图中构建原型，无需切换（避免执行具有破坏性的切换）。仅当存在此类匹配地图／模板时，才适用此捷径。
  • 如果没有匹配的地图——不存在每种类型对应的模板，或从零开始——则采用标准策略：由用户在 Maker 中切换地图类型（msw-general tile.md；之后由 AI 使用 getTileMapMode() 验证）。
  • 无论哪种情况，AI 都绝不自行切换地图的 TileMapMode。（如果在模板中构建，之后会按照清理规则移除其中的示例 *Template 实体。）
  • 如果构建地图是模板地图，则尽早重命名：若原型将放在名称中含 *Template 的地图中，则规划一个阶段 1 任务，在正式开始构建前将其重命名为适合游戏的 ASCII 名称——随着各阶段推进，地图引用（区域注册 · 传送门 · GetEntityByPath 路径 · 当前地图）会逐渐增多，因此在阶段 1 重命名几乎不费力，交接时再改则代价很高；而让游戏保留在名称含 *Template 的地图中，也会干扰本技能自身所依赖的模板与游戏分类。完成标准：文件已重命名 + 所有引用均已更新 + 已刷新 + 已验证条目。具体操作属于实现技能的职责；如果某个引用位于只读配置（Global/）中，则该部分须由用户在 Maker 中操作——与切换 TileMapMode 的策略相同。
  • 开始构建前，将当前地图切换到目标地图（无论上述哪种情况，都必须先确定目标地图）：使用 maker_move_map 将 Maker 的当前（已打开）地图切换到目标地图（AI 可执行），这样实体／图块编辑和截图才会落在正确的地图中。（这不是被禁止的 TileMapMode 切换。）不要悄悄跳过这一步——否则工作会针对错误的地图进行。

第 6 步 —（可选）按阶段制定详细计划

基础输出（第 4 步）包含完整路线图和各阶段检查清单。如果用户想要某个特定阶段的详细计划（例如“编写第 1 阶段的详细计划”“拆解阶段 1”），则生成一份额外的详细计划 Markdown 文档，更深入地展开该阶段的检查清单项目。

• 对于每项任务，写明：目标 · 所需系统/组件（references/msw-mapping.md）· 数据（UserDataSet）· UI · 完成（验证）标准 · 依赖项 · 要参考的技能（预测 — 技能及其参考文档，references/msw-mapping.md §4）。此外，在阶段文档靠前位置记录一份 **“要参考的技能（本阶段）”**摘要，供实施会话首先阅读。
• 在任务旁生成状态检查清单 — 每项初始状态均为 Not started，并在工作推进时经过以下三种状态：
  • ⬜ Not started — 尚未实现。
  • 🟡 Implemented (untested) — 已完成实现，尚未验证。
  • ✅ Tested — 已完成实现和验证。
• 遵循 references/gdd-template.md 中的 “各阶段详细计划模板”。
• 保存为：Docs/<game>-M<n>-Phase<k>.md（使用与里程碑 GDD 相同的 <game>-M<n>- 前缀 — 参见第 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 平台规则（地图类型↔Body、1 单位 = 100px、SpriteRUID 等），但具体实现规则请遵循 msw-general 的平台参考资料。

参考资料

• references/genre-catalog.md — 3 种地图类型 · 构建工作量基准 · 71 种类型（构建工作量提示 · 推荐地图类型 · 核心机制 · 每种类型的 MVP:/Growth: 提示行）· 约 180 个机制标签。这是制定计划的核心依据——务必在步骤 2 中阅读。
• references/decision-sheet.md — Web 决策表：数据架构 · 如何通过各 Agent/命令行打开视图 · 表格↔聊天匹配规则 · 三种粘贴形式 · 失败状态。编写关卡的 decision-data.json 前，务必完整阅读（不打开关卡时无需阅读）。
• references/gdd-template.md — GDD 输出结构 + 里程碑路线图模板（步骤 5）+ 各阶段详细计划模板（步骤 6）+ 已构建内容日志模板。
• references/build-management.md — 实现阶段规则：任务状态处理 · 阶段/里程碑完成后的清理工作 · 计划修订流程。实现任务或更改清单状态前，务必完整阅读（纯规划时无需阅读）。
• references/msw-mapping.md — 地图类型↔Body 对照表 + 游戏系统 → MSW 组件/技能映射速查表。