msw-planning

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

MSW New-Game Planning Mode (msw-planning)

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

Purpose

目标

When the user is at the "I want to make a game like this" stage, turn it into what to build + how to build it in MSW: a guided session produces a GDD/roadmap, then the skill guides the phased build — detailed Phase plans, progress tracking, and plan revisions — until each milestone's build is ready to enter full implementation. Someone who doesn't know game design can just follow the questions; for those who do, it documents decisions fast.

当用户处于“我想做一款这样的游戏”阶段时，将其转化为在MSW中开发什么以及如何开发：通过引导式会话生成GDD/路线图，之后该技能会引导分阶段开发——包括详细的阶段计划、进度追踪和方案修订——直到每个里程碑的开发准备就绪，可进入完整实现阶段。不懂游戏设计的用户只需跟随问题操作；懂设计的用户则可以快速记录决策。

Core principles (why it works this way)

核心原则（为何采用这种运作方式）

Catalog grounding: MSW is 2D · mLua (a Lua-extension scripting language) · cross-platform, so the space of "what you can build" is bounded. Map a vague idea onto the real genres/map-types/mechanics in
```
references/genre-catalog.md
```
to get a feasible plan. Planning from generic game knowledge alone leads to designs MSW can't realize.
Right-size the build: the catalog gives a build-effort hint (Low / Medium / High) per genre — a signal, not a verdict (baseline 1–5 maps · 10–20 units/items · basic-to-intermediate mLua; tower defense sits at the top of comfortably-solo). Use it to set expectations, not to refuse a genre. Size the first build by build-effort + scope (maps/content), never by a calendar/development-time estimate — the skill can't know the user's skill level or available hours, so it doesn't promise 'this takes N days/weeks.' When the user's ambition is large (a High-effort genre, or many systems/maps, or "I want everything"), don't plan it all at once — scope the first build down to a small playable core (MVP) and push the rest to later Phases. This applies to any genre.
Single pass (no ping-pong) + one direction check: limit user touchpoints to STEP 1 (batched questions) and STEP 3 (direction check) — don't keep asking back in between. But never skip STEP 3 (direction check) before writing the GDD: don't just flash the grounding result and jump straight to the GDD. Once the direction is confirmed, produce the deliverable immediately.
Standardized deliverable: drop the result into the fixed GDD structure (
```
references/gdd-template.md
```
) as markdown, so the implementation skills can pick it up and carry it to an MVP.
Carry the project forward: after each deliverable, propose the next step first (e.g., "Shall I write the Phase 1 detailed plan next?"). Proceed if the user wants it, stop if they say stop — it's a suggestion, not a push. (This differs from endless mid-document ping-pong — it connects the flow between deliverables.)
Decision gates = selectable choices, not free text: at each user decision gate — STEP 3 direction check, the Phase handoff (implement now vs write the next-Phase plan), and the soft Phase gate — present the options as a structured selectable choice via the agent's multiple-choice UI when available (e.g., Claude Code's
```
AskUserQuestion
```
), so the user clicks an option instead of typing a free-text reply. Mark the recommended option but don't force it; if the agent has no such UI, fall back to a clearly enumerated prose choice.

依托目录锚定方向：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阶段。
推进项目向前：每次交付完成后，首先提议下一步操作（例如：“接下来我要编写第一阶段的详细计划吗？”）。用户同意则继续，拒绝则停止——这是建议而非强制。（这与文档内的无休止反复沟通不同，它连接了交付物之间的流程。）
决策节点=可选选项，而非自由文本：在每个用户决策节点——步骤3方向确认、阶段交接（立即实现还是编写下一阶段计划）、软阶段节点——当有可用的Agent多选UI时（例如Claude Code的
```
AskUserQuestion
```
），将选项以结构化可选形式呈现，让用户点击选项而非输入自由文本回复。标记推荐选项但不强制；如果Agent没有此类UI，则回退到清晰枚举的文本选项。

On startup — check for an existing GDD (resume / new / blocked)

启动时——检查现有GDD（恢复/新建/受阻）

A build spans multiple sessions and milestones — each milestone is one GDD. Where things live (all project-root, outside RootDesk, to survive

refresh_workspace

Active GDD + Phase plan →
```
Docs/
```
.
Completed GDD →
```
Archive/
```
(on milestone completion).
Archive/As-built.md
→ the world's running implementation record: a curated current-state map kept by the skill, an AI / handoff reference, not a user-facing planning doc (see STEP 6 + Brownfield below).

Before running the flow below, detect the plan files — check both

Docs/

and

Archive/

for a

<game>-GDD.md

List those directories (capital
```
Docs/
```
/
```
Archive/
```
) and match files ending in
```
-GDD.md
```
/
```
-Phase<N>.md
```
— not by glob/grep (case-sensitive + scope-fragile:
```
*.md
```
is top-level only,
```
docs/
```
≠
```
Docs/
```
) and not from memory.
Conclude "no GDD anywhere" only from genuinely empty
Docs/
+
Archive/
listings.
If Archive/As-built.md
exists, read it first for the current-state map.
Normally there's at most one active GDD; if several exist, ask which game this is about first, then apply the rules below.

Gating rule — a "continue" / "next task" / resume request only acts when a plan exists in
Docs/
or
Archive/
(a

<game>-GDD.md

<game>-Phase<N>.md

, or a prior milestone +

Archive/As-built.md

). If nothing exists in either, the request must not be treated as a resume and must not auto-start the STEP 1 questionnaire — instead: if the request is a continue / "what next" intent, or the user says they're building on their own existing work (not a fresh template start), go to Brownfield below; otherwise (a new-game or unclear intent) tell the user there's no saved plan and ask whether to start a new game (then STEP 1). Don't infer brownfield from workspace files — templates ship samples, so a non-empty workspace is not evidence of prior work.

If a GDD exists, judge how much is actually done from the GDD / Phase-doc task states (
⬜/🟡/✅
) — NOT from workspace files (templates ship with

.mlua

.model

.ui

, so file presence is not a reliable progress signal). Then branch:

The user explicitly asked to continue/resume → resume (steps below), regardless of state.
Every roadmap & Phase item is
⬜
(a plan with zero progress) → offer a selectable choice (see Core principles): ① continue this plan ([game]) / ② discard it and plan a new game. If they choose discard, first state exactly which files will be removed —
```
Docs/<game>-GDD.md
```
+ that game's
```
Docs/<game>-Phase<N>.md
```
(only those) — delete them, then start fresh from STEP 1.
Any item is
🟡
or
✅
(real progress — there is in-progress implementation in this world) → do NOT discard and do NOT plan a new game here. Inform the user that this world already has a prototype underway, and that a genuinely new game must be built in a new world — this skill cannot create a world, so the user creates one and runs the skill there — then stop. (If they actually meant to continue this one, resume instead.)
When the state is unclear (missing or inconsistent Phase doc, ambiguous progress) → treat it as the
```
🟡/✅
```
case (don't discard, don't build over).

To resume an existing plan:

Read the existing docs FIRST —
```
Docs/<game>-GDD.md
```
(+ the current
```
Docs/<game>-Phase<N>.md
```
if present). Do not re-run STEP 1–4; the plan already exists.
Reconstruct state: the GDD's
```
Stage
```
line + roadmap
```
⬜/🟡/✅
```
, any
```
🟡 Implemented (untested)
```
items (flag these for re-test / user confirmation), and recent
```
§9 Plan changes
```
.
Briefly restate where things stand — done so far / current Phase / what's still untested / next step — then continue from there.

If
```
Docs/
```
has no GDD but
```
Archive/
```
has a completed one (+
```
Archive/As-built.md
```
), the previous milestone finished. Confirm whether to start a next milestone — a new GDD in
```
Docs/
```
(
```
<game>-M<n+1>-GDD.md
```
, next number per STEP 5), planned on top of
Archive/As-built.md
— rather than assuming a brand-new game. (Before writing it, reconcile the record against the workspace — see Reconcile before a next milestone below.)
Completed Phases have no detail doc (deleted on completion by rule) — the GDD roadmap is their record; only the in-progress Phase has a
```
Docs/<game>-Phase<N>.md
```
.
The
```
Docs/
```
files are the source of truth across sessions: the previous session's chat context does not carry over, so anything not written into the GDD/Phase docs is lost (which is why decisions and states are recorded there).

No GDD in
Docs/
nor
Archive/
→ before anything else, classify the workspace, then decide — mandatory, including for an explicit "new game" request: never jump straight to STEP 1 without first checking what's already built here. (Brownfield = continuing the user's own already-built world; it is user-driven, never inferred from raw file presence — but the classification itself is not optional.) When real work exists, surface it; how prominently to offer brownfield is then decided by the user's intent (below), not the workspace.

A non-empty workspace is not a brownfield signal — a fresh template already ships scaffolding. Treat known starter items as zero progress (a known set, not exhaustive — template versions change and other templates differ; this is "things known to be scaffolding," not a complete manifest): tile dataset

RectTileData_Henesys

;

@Logic

UIPopup

UIToast

;

@Component

Monster

MonsterAttack

PlayerAttack

PlayerHit

(plus the always-present

Global/

defaults — DefaultPlayer, WorldConfig, the starter map).

Workspace ≈ only starter items (or less) → fresh project → proceed to STEP 1, no brownfield prompt.
Work clearly beyond the starter items (custom-named systems / maps / datasets / scripts suggesting real implementation) → a real game may be in progress. How prominently to offer brownfield is decided by the user's intent, not the workspace:
- Continue / "what next" intent ("what should I do next?", "continue", "where were we?") → continuing the existing work is the natural reading → offer brownfield as the recommended option (alongside: start a separate new game; or just re-check / improve one specific system).
- Explicit new-game intent ("I want to make a new game") → honor it: the new game is the default / recommended choice. Offer brownfield only as the last, non-recommended option ("…or are you actually continuing a world you've already built?") — a safety-net, never recommended, never a mandatory fork that overrides what the user asked.
- An explicit "build on my existing work" request → straight to the survey. Brownfield runs only if the user actually picks it.

When brownfield is chosen, don't plan in a vacuum — light structural survey (

map/

RootDesk/MyDesk/

— systems · models · datasets · UI; structure only, not a line-by-line code read; deep inspection is msw-general's job), present "here's what I see already built — correct?" with

⚠️confirm

, then seed
Archive/As-built.md
and plan the first milestone on top of the existing world.

Reconcile before a next milestone — when planning a new milestone on top of

Archive/

records (arrived from startup, or just after completing one):

Archive/As-built.md

(or a legacy handoff note) is a starting hint, not ground truth — work may have happened in other sessions / manual edits without updating it. Before writing the new GDD, run the same light structural survey as Brownfield above, but to verify the record (not discover from scratch): check the area the new milestone will touch — plus a quick scan for obviously-untracked major systems — against what the record claims. If it has drifted, surface it and reconcile with the user first, update
Archive/As-built.md
to match reality, then plan on top. This stops a whole GDD being written on a stale premise and the drift only surfacing mid-implementation.

一个开发项目会跨越多个会话和里程碑——每个里程碑对应一份GDD。文件存储位置（均在项目根目录，RootDesk之外，以避免

refresh_workspace

清理）：

活跃的GDD+阶段计划 →
```
Docs/
```
目录。
已完成的GDD →
```
Archive/
```
目录（里程碑完成时移入）。
Archive/As-built.md
→ 游戏运行实现记录：由该技能维护的当前状态汇总表，是AI/交接参考文档，而非面向用户的规划文档（见步骤6 + 下文“遗留项目”部分）。

在执行以下流程前，检测计划文件——检查**

Docs/

和

Archive/

两个目录**中是否存在

<game>-GDD.md

文件：

列出这些目录（注意大小写：
```
Docs/
```
/
```
Archive/
```
），匹配以
```
-GDD.md
```
/
```
-Phase<N>.md
```
结尾的文件——不要使用glob/grep（区分大小写且范围脆弱：
```
*.md
```
仅匹配顶层文件，
```
docs/
```
≠
```
Docs/
```
），也不要依赖记忆。
只有当
```
Docs/
```
和
```
Archive/
```
列表均为空时，才能得出“无任何GDD”的结论。
如果**
```
Archive/As-built.md
```
**存在，先读取该文件获取当前状态汇总。
通常最多存在一份活跃GDD；如果存在多份，先询问用户针对哪款游戏操作，再应用以下规则。

准入规则——“继续”/“下一步任务”/恢复请求仅在
Docs/
或
Archive/
中存在计划文件时生效（即存在

<game>-GDD.md

<game>-Phase<N>.md

，或之前的里程碑记录+

Archive/As-built.md

）。如果两个目录中均无文件，则该请求不能被视为恢复操作，也不能自动启动步骤1的问卷：如果请求是继续/“下一步”意图，或用户表示要基于自己已有的工作开发（而非从全新模板开始），则进入下文“遗留项目”部分；否则（新建游戏或意图不明确）告知用户无保存的计划，并询问是否要开始新游戏（之后进入步骤1）。不要从工作区文件推断遗留项目——模板会附带示例文件，因此非空工作区不能作为已有工作的证据。

如果存在GDD，根据GDD/阶段文档的任务状态（
⬜/🟡/✅
）判断实际完成进度——而非工作区文件（模板会附带

.mlua

.model

.ui

文件，因此文件存在不是可靠的进度信号）。然后分支处理：

用户明确要求继续/恢复 → 执行恢复流程（见下文步骤），无论当前状态如何。
所有路线图和阶段项均为
⬜
（计划无任何进度） → 提供可选选项（见核心原则）：① 继续该计划（[游戏名称]） / ② 丢弃该计划并规划新游戏。如果用户选择丢弃，首先明确说明将删除哪些文件——
```
Docs/<game>-GDD.md
```
+ 该游戏的
```
Docs/<game>-Phase<N>.md
```
（仅这些文件）——删除后，从步骤1开始全新规划。
任何项为
🟡
或
✅
（有实际进度——当前世界中存在进行中的实现） → 不要丢弃，也不要在此处规划新游戏。告知用户当前世界已有原型在开发中，真正的新游戏必须在新的世界中创建——该技能无法创建世界，因此用户需自行创建世界并在其中运行该技能——然后停止操作。（如果用户实际想继续当前项目，则执行恢复流程。）
状态不明确（缺失或不一致的阶段文档、进度模糊） → 按
```
🟡/✅
```
情况处理（不丢弃，不覆盖开发）。

恢复现有计划的步骤：

先读取现有文档——
```
Docs/<game>-GDD.md
```
（+ 当前存在的
```
Docs/<game>-Phase<N>.md
```
）。不要重新执行步骤1-4；计划已存在。
重构状态：GDD的
```
Stage
```
行 + 路线图的
```
⬜/🟡/✅
```
状态、任何
```
🟡 已实现（未测试）
```
项（标记这些项需重新测试/用户确认），以及最近的
```
§9 计划变更
```
记录。
简要说明当前进度——已完成内容/当前阶段/未测试项/下一步操作，然后从该点继续。

如果
```
Docs/
```
中无GDD但
```
Archive/
```
中有已完成的GDD（+
```
Archive/As-built.md
```
），说明上一个里程碑已完成。确认用户是否要启动下一个里程碑——在
```
Docs/
```
中创建新的GDD（
```
<game>-M<n+1>-GDD.md
```
，编号按步骤5规则递增），基于
```
Archive/As-built.md
```
进行规划——而非默认创建全新游戏。（编写前，需将记录与工作区核对——见下文“下一里程碑前的核对”。）
已完成的阶段没有详细文档（按规则在完成时删除）——GDD路线图是其记录；只有进行中的阶段才有
```
Docs/<game>-Phase<N>.md
```
文件。
```
Docs/
```
中的文件是跨会话的唯一可信来源：上一会话的聊天上下文不会延续，因此未写入GDD/阶段文档的内容会丢失（这就是决策和状态需记录在其中的原因）。

Docs/
和
Archive/
中均无GDD → 首先对工作区进行分类，再做决策——这是强制步骤，包括明确的“新建游戏”请求：绝不要不检查已有的开发内容就直接进入步骤1。（“遗留项目”= 继续用户自己已开发的世界；它是用户驱动的，绝不能从原始文件存在情况推断——但分类本身是必须的。）当存在真实工作内容时，需告知用户；之后是否优先提供遗留项目选项由用户的意图（见下文）决定，而非工作区情况。

非空工作区不是遗留项目的信号——全新模板已附带脚手架。将已知的初始项视为零进度（已知集合，非 exhaustive——模板版本会变化，其他模板也不同；这是“已知为脚手架的内容”，而非完整清单）：瓦片数据集

RectTileData_Henesys

；

@Logic

下的

UIPopup

、

UIToast

；

@Component

下的

Monster

、

MonsterAttack

、

PlayerAttack

、

PlayerHit

（加上始终存在的

Global/

默认项——DefaultPlayer、WorldConfig、初始地图）。

工作区≈仅包含初始项（或更少） → 新项目 → 进入步骤1，不提示遗留项目选项。
工作内容明显超出初始项（自定义命名的系统/地图/数据集/脚本，表明存在真实实现） → 可能有真实游戏在开发中。是否优先提供遗留项目选项由用户的意图决定，而非工作区情况：
- 继续/“下一步”意图（“接下来我该做什么？”、“继续”、“我们之前做到哪了？”） → 继续现有工作是自然选择 → 将遗留项目作为推荐选项（同时提供：启动独立新游戏；或仅检查/改进特定系统）。
- 明确的新建游戏意图（“我想做一款新游戏”） → 尊重用户需求：新建游戏为默认/推荐选项。仅将遗留项目作为最后一个非推荐选项（“……或者你其实是要继续开发已有的世界？”）——作为安全兜底，绝不推荐，绝不强制覆盖用户的请求。
- 明确要求“基于我已有的工作开发” → 直接进入调查流程。只有当用户选择遗留项目时才执行对应流程。

当选择遗留项目时，不要凭空规划——进行轻量结构调查（

map/

RootDesk/MyDesk/

——系统·模型·数据集·UI；仅查看结构，不逐行读取代码；深度检查是msw-general的工作），向用户展示*“这是我发现的已开发内容——是否正确？”*并要求

⚠️确认

，然后初始化
Archive/As-built.md
，基于现有世界规划第一个里程碑。

下一里程碑前的核对——当基于

Archive/

记录规划新里程碑时（启动时进入，或刚完成一个里程碑后）：

Archive/As-built.md

（或遗留交接笔记）是起始参考，而非绝对事实——可能在其他会话中进行了工作或手动编辑，但未更新该记录。在编写新GDD前，执行与“遗留项目”相同的轻量结构调查，但目的是验证记录（而非从头发现）：检查新里程碑将涉及的区域——快速扫描明显未追踪的主要系统——与记录内容是否一致。如果记录已偏离实际情况，告知用户并先与用户核对，**更新

Archive/As-built.md

**使其与实际一致，然后再进行规划。这可以避免基于过时前提编写整个GDD，导致偏离情况在开发中途才暴露。

Flow

流程

STEP 1 — Guided questions (batched)

步骤1——引导式问题（批量）

Don't re-ask what the user already gave; batch only the gaps:

Genre / reference — what's the feel? Any similar game? (If unsure, start from "what kind of fun do you want?")
Core fun / core loop — what do you repeat in one session? (e.g., kill enemies → grow → stronger enemies)
Target · platform — PC/mobile? Solo/multi?
Scope (first build) — a quick prototype or something bigger? Roughly how many maps / how much content?
Must-haves / cuttable

Batch into ~5 questions. If the user says "you decide," proceed with reasonable defaults but state the assumptions.

不要重复询问用户已提供的信息；仅批量询问缺失的内容：

类型/参考——游戏风格是什么？有没有类似的游戏？（如果不确定，从“你想要什么样的乐趣？”开始。）
核心乐趣/核心循环——单会话中重复进行的操作是什么？（例如：击杀敌人→成长→挑战更强敌人）
目标·平台——PC/移动端？单人/多人？
范围（首次开发）——快速原型还是更完整的版本？大致有多少张地图/多少内容？
必备功能/可裁剪功能

批量约5个问题。如果用户说“你来决定”，则使用合理默认值，但需说明假设前提。

STEP 2 — Catalog grounding + feasibility check

步骤2——目录锚定+可行性检查

Read

references/genre-catalog.md

and:

Find the closest genre(s) to the user's idea.
Pull that genre's recommended map type and core mechanic tags.
Read the
build-effort
hint (Low/Medium/High) and gauge the user's ambition. If it's High-effort or the user is asking for a lot at once, say so plainly and propose a scoped-down first build (one map · core loop only) that keeps the same fun, with the rest deferred to later Phases — regardless of genre.
If needed, pick and combine mechanic tags into a one-line concept.

读取

references/genre-catalog.md

并：

找到与用户创意最匹配的类型。
获取该类型的推荐地图类型和核心机制标签。
读取
开发难度
提示（低/中/高）并评估用户的目标。如果是高难度或用户要求一次性开发大量内容，需明确说明，并提议缩小首次开发范围（仅一张地图·核心循环），保留相同的乐趣，其余内容推迟到后续阶段——无论类型如何。
如有需要，挑选并组合机制标签，形成一句话概念。

STEP 3 — Direction check (user confirmation gate) ⚑ Do not skip

步骤3——方向确认（用户确认节点） ⚑ 不可跳过

Always get the direction confirmed by the user before writing the GDD. Briefly show the grounding result and don't jump straight to the GDD — genre and map type decide the whole stack, so if you write the entire GDD on a wrong choice you have to redo all of it.

Present briefly and ask the user:

Recommended direction: the matched sub-genre(s) (1–2 candidates) + recommended map type ↔ Body (e.g., RectTile +
```
KinematicbodyComponent
```
) + build-effort hint (Low/Medium/High) + one-line concept.
If it's High-effort or the user is over-scoping, present a scoped-down first-build (MVP) option alongside — the same fun in a smaller first slice, with the rest deferred.
Then ask, presenting the options as a selectable choice (see Core principles): "Shall I build the GDD in this direction? Or are there other candidates / changes?"
Only after the user confirms (or chooses) move to STEP 4. (If they explicitly say "you decide," lock in the recommendation but state in one line what you chose.)
Map type ↔ Body is nailed down here (
```
references/msw-mapping.md
```
). Getting it wrong causes "doesn't move" /
```
[LEA-3004]
```
silent failures in implementation. It is applied at setup by building in a map that already has this type if one exists (e.g., a per-type template); otherwise the user sets it in Maker. The AI never switches a map's type itself (see STEP 5).

在编写GDD前必须获得用户的方向确认。简要展示锚定结果，不要直接跳转到GDD编写——类型和地图类型决定了整个技术栈，如果基于错误选择编写完整GDD，就必须全部重写。

简要展示并询问用户：

推荐方向：匹配的子类型（1-2个候选） + 推荐地图类型 ↔ 实体组件（例如：RectTile +
```
KinematicbodyComponent
```
） + 开发难度提示（低/中/高） + 一句话概念。
如果是高难度或用户范围过大，同时提供缩小范围的首次开发（MVP）选项——以更小的初始版本保留相同乐趣，其余内容推迟。
然后询问用户，将选项以可选形式呈现（见核心原则）：“我是否按照这个方向编写GDD？还是有其他候选方向/修改需求？”
仅在用户确认（或选择）后进入步骤4。（如果用户明确说“你来决定”，则锁定推荐选项，但用一句话说明选择的内容。）
地图类型 ↔ 实体组件在此处确定（
```
references/msw-mapping.md
```
）。选择错误会导致开发中出现“无法移动”/
```
[LEA-3004]
```
静默失败。在设置阶段如果存在匹配类型的地图，则在该地图中开发（例如，每种类型的模板地图）；否则由用户在Maker中设置。AI绝不会自行切换地图类型（见步骤5）。

STEP 4 — Produce the GDD/roadmap

步骤4——生成GDD/路线图

In the direction the user confirmed in STEP 3, write markdown in the

references/gdd-template.md

structure: one-line concept / key-decisions table / core loop / core systems / system↔MSW mapping / Phase roadmap checklist / decided·deferred items.

For the system↔MSW mapping, use
```
references/msw-mapping.md
```
to connect each system to
```
@Logic
```
/
```
@Component
```
/
```
.model
```
/
```
.ui
```
/dataset (UserDataSet).
Split the roadmap into stages starting from the smallest playable build (Phase 1), like "move, hit, and it breaks." Track each roadmap item with three states —
```
⬜ Not started
```
/
```
🟡 Implemented (untested)
```
/
```
✅ Tested
```
(all start ⬜; see STEP 6).
The roadmap checklist holds only items required for a handoff-ready prototype — and all of them must reach
✅
. Polish / nice-to-have / later work goes in §8 (Deferred) at planning time, never as a checklist item. Discriminator: would dropping it leave the full-implementation team a more incomplete base? → required (checklist); does production polish it anyway? → §8.
For data-heavy games, state "data-driven (UserDataSet/CSV is the source of truth)" in the roadmap. Early Phases may hardcode values for speed, but add a later-Phase goal to migrate implementation data into a dataset (UserDataSet/CSV) once the value-set grows or stabilizes — so balancing/content no longer needs code edits. Include this only when warranted (many tunable values · balance iteration expected · content scaling), not for a handful of constants. The dataset itself is authored via
```
msw-general
```
(see its
```
references/dataset.md
```
).
If the chosen map ships placeholder/sample entities: include a task to remove them before the prototype hands off to full implementation so they don't carry into the real build. Don't assume fixed names — inspect the actual map and identify its sample/placeholder entities (often
```
*Template
```
-named idle/move/chase monster samples, but names vary by template). They're useful early as AI-pattern references; actual deletion happens during implementation, via MapBuilder removing them from the
```
.map
```
.

按照用户在步骤3中确认的方向，以

references/gdd-template.md

的结构编写Markdown文档：一句话概念/关键决策表/核心循环/核心系统/系统↔MSW映射/阶段路线图检查清单/已确定·推迟项。

对于系统↔MSW映射，使用
```
references/msw-mapping.md
```
将每个系统与
```
@Logic
```
/
```
@Component
```
/
```
.model
```
/
```
.ui
```
/数据集（UserDataSet）关联。
将路线图拆分为阶段，从最小可玩版本（第一阶段）开始，例如“移动、攻击、破坏目标”。用三种状态追踪每个路线图项——
```
⬜ 未开始
```
/
```
🟡 已实现（未测试）
```
/
```
✅ 已测试
```
（初始均为
```
⬜
```
；见步骤6）。
路线图检查清单仅包含交付原型所需的必要项——且所有项必须达到
✅
状态。优化/锦上添花/后续工作在规划时放入**§8（推迟项）**，绝不能作为检查清单项。判断标准：移除该项会让完整开发团队的基础更不完整吗？ → 必要项（检查清单）；生产阶段会进行优化吗？ → §8。
对于数据密集型游戏，在路线图中注明“数据驱动（UserDataSet/CSV为可信来源）”。早期阶段可能为了速度硬编码值，但需添加后续阶段目标：当值集增长或稳定后，将实现数据迁移到数据集（UserDataSet/CSV）——这样平衡/内容调整无需再修改代码。仅在有必要时添加此项（大量可调值·预期平衡迭代·内容扩展），而非针对少量常量。数据集本身由
```
msw-general
```
创建（见其
```
references/dataset.md
```
）。
如果所选地图包含占位/示例实体：添加任务，要求在原型交付给完整开发前移除这些实体，避免它们进入正式开发。不要假设固定名称——检查实际地图并识别其示例/占位实体（通常是
```
*Template
```
命名的 idle/move/chase 怪物示例，但名称因模板而异）。它们在早期可作为AI模式参考；实际删除在开发阶段进行，由MapBuilder从
```
.map
```
文件中移除。

STEP 5 — Save + next step

步骤5——保存+下一步操作

Save the produced markdown under the project-root
Docs/
as Docs/<game>-M<n>-GDD.md
— <game>
is a short ASCII (English/romanized) slug (never the raw non-English title; CJK/non-ASCII filenames break globbing and cross-platform paths — e.g.
```
MapleIdle-M1-GDD.md
```
, not the raw CJK title) and <n>
is the milestone number. Milestone number: the first milestone is M1; a later milestone takes (the numerically highest existing
-M<n>-GDD.md
across
Docs/
+
Archive/
) + 1 — parse the number, don't sort lexically (so M9 → M10, not M2). The doc's content stays in the user's language; only the filename is ASCII. Phase docs inherit the same <game>-M<n>-
prefix (STEP 6). Collect all planning deliverables (GDD · phase detail plans) here. Create the folder if missing. Kept as a file, the implementation skills can pick it up and carry it to an MVP.
⚠️ Do NOT save under
RootDesk/
. Maker's
```
refresh_workspace
```
cleans up (deletes) non-MSW files (.md etc.) under
```
RootDesk/
```
, so files there vanish when a refresh runs during implementation/playtesting. Always keep them outside RootDesk (project-root
```
Docs/
```
).
When the base GDD is done, propose naturally first: "Shall I write the Phase 1 detailed plan next?" → if the user agrees, go straight to STEP 6.
Other branches to offer: if numbers/data-heavy, go to dataset design; if screen-heavy, author UI with
```
msw-ui-system
```
; to build right away, start implementation with
```
msw-general
```
·
```
msw-scripting
```
. The default recommended flow is 'detail Phase 1 → implement.'
Apply the map type — build in a matching map if one exists, otherwise the user sets it: the prototype must be built in a map whose
```
TileMapMode
```
already equals the decided type. At setup, check existing maps with
```
MapBuilder.read().getTileMapMode()
```
, then:
- If a map already matches — e.g., the project keeps per-map-type template maps (one TileMap / RectTile / SideView each) — build the prototype in that map, no switch needed (the destructive switch is avoided). This shortcut applies only when such a matching map/template exists.
- If no map matches — no per-type template, or starting from scratch — fall back to the standard policy: the user switches a map's type in Maker (msw-general
```
tile.md
```
  ; the AI verifies with
```
getTileMapMode()
```
  afterward).
- Either way, the AI never switches a map's
  TileMapMode
  itself. (If built in a template, its sample
```
*Template
```
  entities are removed later per the cleanup rule.)

将生成的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等），因此保存在此处的文件会在开发/测试期间执行refresh时消失。始终将文件保存在RootDesk之外（项目根目录的
```
Docs/
```
）。
基础GDD完成后，首先自然提议：“接下来我要编写第一阶段的详细计划吗？” → 如果用户同意，直接进入步骤6。
还可提供其他分支选项：如果是数据密集型，进入数据集设计；如果是界面密集型，使用
```
msw-ui-system
```
创建UI；如果要立即开发，使用
```
msw-general
```
·
```
msw-scripting
```
启动实现。默认推荐流程为“细化第一阶段→实现”。
应用地图类型——如果存在匹配地图则在其中开发，否则由用户设置：原型必须在
```
TileMapMode
```
已匹配选定类型的地图中开发。设置阶段，使用
```
MapBuilder.read().getTileMapMode()
```
检查现有地图，然后：
- 如果存在匹配地图——例如，项目保留每种地图类型的模板地图（各有一个TileMap/RectTile/SideView地图）——在该地图中开发原型，无需切换（避免破坏性切换）。此捷径仅在存在此类匹配地图/模板时适用。
- 如果无匹配地图——无类型模板，或从零开始——回退到标准策略：用户在Maker中切换地图类型（msw-general的
```
tile.md
```
  ；AI之后用
```
getTileMapMode()
```
  验证）。
- 无论哪种情况，AI绝不会自行切换地图的
  TileMapMode
  。（如果在模板中开发，其示例
```
*Template
```
  实体会稍后按清理规则移除。）

STEP 6 — (Optional) Per-phase detailed plan

步骤6——（可选）阶段详细计划

The base output (STEP 4) goes up to the full roadmap + per-Phase checklist. If the user wants the detailed plan for a specific Phase (e.g., "write the Phase 1 detailed plan," "break down stage 1"), generate an additional detailed-plan markdown that expands that Phase's checklist items in more depth.

For each task, write: goal · required systems/components (
```
references/msw-mapping.md
```
) · data (UserDataSet) · UI · done (verification) criteria · dependencies · skills to reference (predicted — skill + its reference doc,
references/msw-mapping.md
§4). Also record, near the top of the Phase doc, a "Skills to reference (this Phase)" summary — the implementing session reads it first.
Generate a status checklist alongside the tasks — every item starts Not started and moves through three states as work proceeds:
- ```
⬜ Not started
```
  — not implemented yet.
- ```
🟡 Implemented (untested)
```
  — implementation done, not yet verified.
- ```
✅ Tested
```
  — implementation AND verification both done.
Follow the 'Per-phase detailed plan template' in
```
references/gdd-template.md
```
.
Save:
```
Docs/<game>-M<n>-Phase<k>.md
```
(same <game>-M<n>-
prefix as the milestone's GDD — see STEP 5;
```
<k>
```
= phase number; project-root
```
Docs/
```
, outside RootDesk — avoids refresh deletion).
This too goes only up to detailed planning — writing actual code (.mlua/.model etc.) is still the job of the implementation skills (msw-general/msw-scripting etc.); those skills update the checklist states as they implement and verify.

基础输出（步骤4）包含完整路线图+阶段检查清单。如果用户需要特定阶段的详细计划（例如：“编写第一阶段详细计划”、“拆分第一阶段”），生成额外的详细计划Markdown文档，深入扩展该阶段的检查清单项。

对于每个任务，编写：目标·所需系统/组件（
```
references/msw-mapping.md
```
）·数据（UserDataSet）·UI·完成（验证）标准·依赖项·参考技能（预测——技能+参考文档，
references/msw-mapping.md
第4节）。同时在阶段文档顶部记录**“本阶段参考技能”**摘要——开发会话会首先读取该内容。
生成状态检查清单与任务并列——所有项初始为未开始，随着工作推进切换三种状态：
- ```
⬜ 未开始
```
  ——尚未实现。
- ```
🟡 已实现（未测试）
```
  ——已完成实现，尚未验证。
- ```
✅ 已测试
```
  ——实现和验证均完成。
遵循
```
references/gdd-template.md
```
中的**“阶段详细计划模板”**。
保存：
```
Docs/<game>-M<n>-Phase<k>.md
```
（与里程碑GDD使用相同的**
```
<game>-M<n>-
```
前缀**——见步骤5；
```
<k>
```
为阶段编号；保存在项目根目录的
```
Docs/
```
，RootDesk之外——避免被refresh删除）。
此步骤仅到详细规划阶段——实际编写代码（.mlua/.model等）仍由开发技能负责（msw-general/msw-scripting等）；这些技能会在实现和验证时更新检查清单状态。

Checklist state rules (apply during implementation)

检查清单状态规则（开发阶段适用）

Implement by Phase unit (continuous), not task-by-task: when the user asks to implement a Phase, work through its tasks in dependency order, end to end — verify each inline, update its
```
⬜→🟡→✅
```
state, and keep going. Don't stop after one task to ask whether to continue. Pause only at: the Phase is complete (all
```
✅
```
, or only AI-unverifiable items left
```
🟡
```
); a genuine blocker (a decision or resource only the user can give, a user-test that gates the next task, or an unresolved failure); or a context/output limit (then do as much as possible, stop at a clean checkpoint, and state exactly what remains). At a pause, give one batched report, not a per-task check-in. ("Phase unit" means continuous progress to a natural checkpoint — not necessarily one turn; implement everything implementable first and collect visual/feel/on-device user-tests to surface together at the Phase boundary.)
Update each task's state immediately as you build it — mandatory, not deferrable. Per task, in order: write the code → right away mark that item
🟡 Implemented (untested)
in the Phase doc (before starting the next task and before verification) → verify → set
```
✅ Tested
```
(or send it back to fixing). Never leave an implemented task at
⬜
— if its files exist, it is at least
```
🟡
```
. Don't batch the state updates to the end (that's how a Phase doc ends up all-
```
⬜
```
while the workspace is full of code, which then blocks the next session from knowing what's done). Keep the Phase doc current as you go, and reflect Phase-level completion back into the GDD roadmap. Tracking state only in an in-session/ephemeral tool (e.g. the harness's own TaskCreate/TaskUpdate list) does not count as updating the checklist — it is discarded at session end; the
```
Docs/<game>-M<n>-Phase<k>.md
```
checklist is the single durable source of truth, so mirror every
```
⬜→🟡→✅
```
change into it in the same step (tracking only in the ephemeral tool leaves the doc all-
```
⬜
```
— the same failure as above).
Untestable-by-AI items — be honest: some items can't be verified by the AI alone (on-device feel, visual/audio judgment, real-player multiplayer, store/commerce — anything needing human eyes or a real client). Do NOT silently mark these
```
✅ Tested
```
. Tell the user plainly which items you couldn't test and why, leave them at
```
🟡 Implemented (untested)
```
, and ask the user to test; when they report back, reflect it into the checklist (
```
✅ Tested
```
, or send it back to fixing if it failed).
Phase gate (soft): if the user asks to start the next Phase while some items aren't yet
```
✅ Tested
```
, first tell them which items are still untested, then offer the choice as a selectable prompt (see Core principles): proceed to the next Phase anyway, or finish testing the untested items first. If the user still wants to proceed, proceed — it's a heads-up, not a block.
No silent deferral: every checklist item is required (it wouldn't be in the checklist otherwise), so don't drop one mid-build with a "the prototype doesn't need it" rationale. If an item genuinely turns out non-required, move it to §8 (Deferred) via a plan revision (user confirmation + GDD §9 log) — never leave it parked as "Deferred" inside the checklist.
Phase-detail handoff: after finishing a Phase detailed plan, offer the next step as a selectable choice (see Core principles) — implement this stage vs write the next Phase N+1 detailed plan.
Completed-stage cleanup (mandatory): once a Phase's items are all
✅ Tested
, in order — (1) record that Phase 'done' in the GDD roadmap; (2) distill its as-built facts into
Archive/As-built.md
(update the current-state map + log key components/files, deviations from plan, and gotchas — concise, not a code dump; git already logs raw changes); (3) delete that Phase's detailed-plan md (
Docs/<game>-Phase<N>.md
) — a transient artifact that must not linger. Nothing is lost: the roadmap keeps progress,
```
Archive/As-built.md
```
keeps the as-built record. (Always do 1+2 before deleting.)
Milestone-complete cleanup (mandatory): once every GDD roadmap item is
```
✅ Tested
```
— this milestone is implemented and verified — finish up: (1) set the GDD's
```
Stage
```
to complete; (2) finalize
Archive/As-built.md
so its current-state map reflects the whole milestone; (3) move
```
Docs/<game>-M<n>-GDD.md
```
into Archive/
(project root, outside RootDesk; create if missing) — archived, not deleted, as this milestone's record. ⚠️ Never overwrite an existing archived GDD: if that name already exists in
```
Archive/
```
(shouldn't, under the
```
M<n>
```
rule), it signals a numbering error — stop and flag it, don't silently rename. Leave
Docs/
in place (the next milestone reuses it for a new GDD). Verify all items are truly
```
✅
```
first, then tell the user the milestone is complete + where things are. A later milestone (the user wants to evolve further) starts a new GDD in
Docs/
(
```
<game>-M<n+1>-GDD.md
```
, next number per STEP 5), planned on top of
```
Archive/As-built.md
```
(reconcile it against the workspace first — see Reconcile before a next milestone).

按阶段单元连续实现，而非逐个任务：当用户要求实现一个阶段时，按依赖顺序从头到尾处理任务——逐个验证，更新
```
⬜→🟡→✅
```
状态，持续推进。不要完成一个任务后就停止询问是否继续。仅在以下情况暂停：阶段完成（所有项为
```
✅
```
，或仅剩AI无法验证的项为
```
🟡
```
）；真正的阻塞问题（仅用户能提供的决策或资源、用户测试作为下一任务的前置条件，或未解决的故障）；或上下文/输出限制（则尽可能完成工作，在清晰的检查点停止，并明确说明剩余内容）。暂停时，给出批量报告，而非逐个任务检查。（“阶段单元”指持续推进到自然检查点——不一定是一次会话；先完成所有可实现的内容，在阶段边界汇总视觉/体验/设备端用户测试结果。）
实现后立即更新任务状态——强制要求，不可推迟。每个任务按顺序：编写代码→立即在阶段文档中标记该项为
🟡 已实现（未测试）
（在开始下一任务和验证前）→验证→设置为
```
✅ 已测试
```
（或退回修复）。绝不能将已实现的任务留在
⬜
状态——如果文件存在，至少为
```
🟡
```
。不要将状态更新批量到最后（这会导致阶段文档全为
```
⬜
```
，但工作区充满代码，进而阻止下一会话了解已完成内容）。随时保持阶段文档更新，并将阶段完成情况反馈到GDD路线图。仅在会话内/临时工具（例如工具的TaskCreate/TaskUpdate列表）中追踪状态不算更新检查清单——会话结束后会被丢弃；
```
Docs/<game>-M<n>-Phase<k>.md
```
检查清单是唯一持久的可信来源，因此需在同一步骤中将每个
```
⬜→🟡→✅
```
的变更同步到其中（仅在临时工具中追踪会导致文档全为
```
⬜
```
——与上述问题相同）。
AI无法测试的项——如实说明：有些项无法仅由AI验证（设备端体验、视觉/音频判断、真实玩家多人模式、商店/交易——任何需要人眼或真实客户端的内容）。不要悄悄将这些项标记为
```
✅ 已测试
```
。明确告知用户哪些项无法测试及原因，将其留在
```
🟡 已实现（未测试）
```
状态，并请用户测试；用户反馈后，将结果更新到检查清单（
```
✅ 已测试
```
，或如果失败则退回修复）。
阶段节点（软）：如果用户要求启动下一阶段但有些项尚未
```
✅ 已测试
```
，首先告知用户哪些项仍未测试，然后提供可选选项（见核心原则）：无论如何进入下一阶段，还是先完成未测试项的测试。如果用户仍要继续，则继续——这是提醒而非阻塞。
不要悄悄推迟：每个检查清单项都是必要的（否则不会列入清单），因此不要中途以“原型不需要此项”为由丢弃。如果某项确实不再必要，通过方案修订将其移到§8（推迟项）（用户确认+GDD§9日志）——绝不能留在检查清单中标记为“推迟”。
阶段详细计划交接：完成阶段详细计划后，以可选选项形式（见核心原则）提议下一步操作——实现本阶段 vs 编写下一阶段N+1的详细计划。
完成阶段清理（强制）：一旦阶段所有项均为
✅ 已测试
，按顺序执行：(1) 在GDD路线图中记录该阶段“已完成”；(2) 将其实际实现情况提炼到
Archive/As-built.md
（更新当前状态汇总+记录关键组件/文件、与计划的偏差、注意事项——简洁，不要代码转储；git已记录原始变更）；(3) 删除该阶段的详细计划md文件（
Docs/<game>-Phase<N>.md
）——这是临时产物，不能保留。不会丢失任何内容：路线图记录进度，
```
Archive/As-built.md
```
记录实际实现情况。（删除前必须先完成1+2步骤。）
里程碑完成清理（强制）：一旦所有GDD路线图项均为
```
✅ 已测试
```
——该里程碑已实现并验证——完成以下操作：(1) 将GDD的
```
Stage
```
设置为已完成；(2) 最终确定
Archive/As-built.md
，使其当前状态汇总反映整个里程碑；(3) 将
Docs/<game>-M<n>-GDD.md
移动到
```
Archive/
```
目录（项目根目录，RootDesk之外；不存在则创建）——归档而非删除，作为该里程碑的记录。⚠️ 绝不要覆盖已归档的GDD：如果
```
Archive/
```
中已存在该名称（按
```
M<n>
```
规则不应存在），说明编号错误——停止操作并标记问题，不要悄悄重命名。保留
Docs/
目录（下一里程碑会在其中创建新GDD）。先验证所有项确实为
```
✅
```
，然后告知用户里程碑已完成及文件位置。后续里程碑（用户想要进一步扩展）会在
```
Docs/
```
中创建新GDD（
```
<game>-M<n+1>-GDD.md
```
，编号按步骤5规则递增），基于
```
Archive/As-built.md
```
规划（先与工作区核对——见“下一里程碑前的核对”）。

Revising the plan mid-development (add / remove / change a rule)

开发中途修订计划（添加/移除/修改规则）

Once the GDD exists and you're building phase by phase, the user may request changes to the plan. Handle the three kinds — add, remove, modify a planned rule/task — without breaking consistency with what's already built.

For any revision:

Classify it — add a new rule, remove an existing rule, or modify an existing rule.
Locate what it touches — which GDD section (key decisions / core systems / roadmap / data-driven) and/or which Phase doc + checklist item(s). A GDD prose item (§2/§4/§5/§7) has no state of its own; determine whether it's already built by tracing it to the roadmap/Phase checklist items that implement it, then apply the
```
🟡
```
/
```
✅
```
impact rules (step 3) to those.
Assess impact honestly before applying — especially when it touches work already built (
```
🟡
```
/
```
✅
```
):
- Add: the new item enters the checklist as
```
⬜ Not started
```
  . If it belongs to a Phase already marked done, say so and place it in the current/next Phase rather than silently re-opening the done one.
- Modify: if the target was
```
🟡
```
  /
```
✅
```
  , the built work likely needs redo → reset that item to
```
⬜
```
  (or
```
🟡
```
  if only re-testing is needed) and tell the user it must be re-implemented/re-verified.
- Remove: if the target was already built, the code must be removed too → flag a removal task for the implementation skill, then drop the item from the plan/checklist.
- Note any dependent rules/tasks the change ripples into.
- ⚠️ If it touches a core decision (key-decisions table — e.g., map type ↔ Body, solo/multi &
```
@Sync
```
  ), warn strongly: it cascades through the whole stack and can invalidate much of what's built. Confirm before proceeding.
Confirm scope when it affects built/tested work or a core decision — surface the impact (which states reset, what code to remove, which dependents) and get the user's go-ahead. A pure addition to not-yet-started work can proceed directly.
Apply to the docs — update the relevant GDD section and/or Phase doc; add/remove/modify the checklist item(s) with the correct states; and log the change in the GDD's "Plan changes" section (type / what / why / impact) so the plan's history stays visible.
Hand off code changes — writing/removing/altering actual code (.mlua/.model etc.) is the implementation skills' job; this skill updates the plan, checklist states, and flags the implementation/cleanup tasks.

GDD存在且分阶段开发后，用户可能要求修改计划。处理三种类型的修订——添加、移除、修改计划规则/任务——同时保持与已开发内容的一致性。

对于任何修订：

分类——添加新规则、移除现有规则，或修改现有规则。
定位影响范围——涉及GDD的哪个部分（关键决策/核心系统/路线图/数据驱动）和/或哪个阶段文档+检查清单项。GDD中的文字项（§2/§4/§5/§7）本身无状态；通过追踪到实现它的路线图/阶段检查清单项，判断是否已开发，然后对这些项应用
```
🟡
```
/
```
✅
```
影响规则（步骤3）。
在应用前如实评估影响——尤其是涉及已开发内容（
```
🟡
```
/
```
✅
```
）时：
- 添加：新项进入检查清单时为
```
⬜ 未开始
```
  。如果属于已标记完成的阶段，需说明并将其放入当前/下一阶段，而非悄悄重新打开已完成的阶段。
- 修改：如果目标项为
```
🟡
```
  /
```
✅
```
  ，已开发内容可能需要重做→将该项重置为
```
⬜
```
  （或
```
🟡
```
  如果仅需重新测试），并告知用户需重新实现/验证。
- 移除：如果目标项已开发，代码也需移除→为开发技能标记移除任务，然后从计划/检查清单中删除该项。
- 记录变更影响到的依赖规则/任务。
- ⚠️ 如果涉及核心决策（关键决策表——例如，地图类型↔实体组件、单人/多人&
```
@Sync
```
  ），需强烈警告：这会影响整个技术栈，可能使已开发内容失效。执行前需确认。
当影响已开发/测试内容或核心决策时，确认范围——说明影响（哪些状态重置、需移除哪些代码、哪些依赖项受影响）并获得用户批准。仅添加到未开始工作的修订可直接执行。
应用到文档——更新相关GDD部分和/或阶段文档；添加/移除/修改检查清单项并设置正确状态；并在GDD的“计划变更”部分记录变更（类型/内容/原因/影响），以便保留计划的历史记录。
交接代码变更——编写/移除/修改实际代码（.mlua/.model等）是开发技能的工作；本技能负责更新计划、检查清单状态，并标记实现/清理任务。

Boundaries (what this skill does NOT do)

边界（本技能不负责的内容）

It does not write the actual code (.mlua/.model/.map/.ui) — that's the implementation skills' job. This skill plans and manages the game's build across its milestones (GDD · detailed Phase plans · progress tracking · plan revisions) and hands the code work off to msw-general/msw-scripting etc.
A major improvement/expansion of an already-built, shipped world is out of scope (this skill plans the game's build — a new game and its successive milestones — up to readiness for full implementation).
Reflect MSW platform rules (map-type↔Body, 1 unit = 100px, SpriteRUID, etc.) in the plan, but follow msw-general's platform references for the exact implementation rules.

不负责编写实际代码（.mlua/.model/.map/.ui）——这是开发技能的工作。本技能负责规划并管理游戏开发的各个里程碑（GDD、阶段详细计划、进度追踪、方案修订），并将代码工作交接给msw-general/msw-scripting等技能。
对已开发完成并发布的世界进行重大改进/扩展超出本技能范围（本技能负责游戏开发规划——新游戏及其后续里程碑——直到准备好进入完整实现阶段）。
在计划中体现MSW平台规则（地图类型↔实体组件、1单位=100px、SpriteRUID等），但具体实现规则需遵循msw-general的平台参考文档。

References

参考文档

```
references/genre-catalog.md
```
— 3 map types · build-effort baseline · 62 genres (build-effort hint · recommended map type · core mechanics) · ~150 mechanic tags. The heart of grounding — always read it in STEP 2.
```
references/gdd-template.md
```
— the GDD/roadmap output structure + per-phase detailed-plan template (STEP 6).
```
references/msw-mapping.md
```
— map-type↔Body table + game-system → MSW component/skill mapping cheat sheet.

```
references/genre-catalog.md
```
——3种地图类型·开发难度基准·62种游戏类型（开发难度提示·推荐地图类型·核心机制）·约150个机制标签。锚定方向的核心——步骤2中必须读取。
```
references/gdd-template.md
```
——GDD/路线图输出结构+阶段详细计划模板（步骤6）。
```
references/msw-mapping.md
```
——地图类型↔实体组件表+游戏系统→MSW组件/技能映射速查表。