make-game

制作游戏

与用户合作创建电子游戏时，请参考提供的技能／流水线／命令，帮助用户为游戏开发打造完善的流水线。

根据用户请求的进展、当前代码库和开发阶段，选择合适的步骤，与用户一起完成请求。

使用时机

在以下情况下使用此技能：

• 用户正在构思或描述游戏创意（无需项目目录——创意阶段本身就是为此而设）
• 当前工作目录是一个游戏项目（包含 docs/、源文件，或引擎配置文件，例如使用 Phaser／Three.js 的 package.json、Unity 的 Assets/、Godot 的 project.godot 等）
• 用户想要添加游戏玩法功能、修复游戏玩法 Bug、处理资源，或迭代游戏设计

在以下情况下不要使用此技能：

• 用户的请求与游戏开发无关（例如通用 Web 应用、CLI 工具、库、基础设施、数据工作等）
• 用户明确要求制作非游戏类产物（例如“帮我构建一个聊天应用”）
• 用户想根据一条推文、一则新闻或简短提示，制作一款一炮而红的游戏——无需里程碑规划，在单次会话中端到端完成并发布。请改用 /viral-game。该流水线立场鲜明（Phaser／Three.js、here.now、Play.fun），以牺牲此技能严谨的规划流程为代价，将部署时间缩短至约 10 分钟。如果 /viral-game 会话的范围不断扩大（用户开始要求里程碑、ADR 或长期迭代），则应切回此技能。

目录

1. 规则
2. 阶段
3. 里程碑
4. 重要文件
5. 模板
6. 子流水线
7. 其他技能

1. 规则

• 计划完成前不得编写代码。 如果 docs/gameplan.md 不存在，你必须完整执行构思阶段流程——编写 gameplan、docs/tech.md 和 ADR-0001，并获得用户确认——然后才能创建任何源文件、运行引擎脚手架工具、安装依赖或以其他方式接触代码。用户的提示即使听起来很详细，也不能替代构思阶段的问题：即使用户说“带像素艺术着色器的 3D 赛车游戏”，你也还不知道玩法循环、获胜条件、控制方式、范围或目标单局时长；擅自决定这些内容，是导致后续返工的最大原因。请将此视为严格的触发条件——如果你正要在没有用户签字认可的书面 gameplan 时搭建项目，请停下来，先执行构思阶段。idea.md 中的澄清问题清单是最低要求；不要因为提示“看起来很清楚”就跳过任何项目。
• 进入现有项目目录中的会话时，始终先运行会话开始子流程。 此流程会恢复上下文（docs/STATE.md、docs/gameplan.md、docs/tech.md、里程碑），确定当前阶段，并与用户确认下一步。仅当项目目录尚不存在（从零开始的新构思阶段对话）时才跳过。
• 向用户提问时，使用 AskUserQuestion 工具。如果能提供多选形式的建议答案，并允许用户自行回答，那就最好不过了。
  • 提问时，要聚焦、清晰且具体。如果你能想到一些合理的答案，就将它们作为可能的选项提供给用户。如果用户也想自行构思解决方案，这会有所帮助；他们可以根据你提供的不同选项，组合出最合适的答案。
  • 如果你对用户有过往记忆或经验，请评估他们的技术能力和专业水平，并据此调整问题。如果用户看起来不太熟悉技术，提问时要确保他们能理解。对于较高级的主题，提问时应附上解释，避免用户在不了解的情况下作答。
• 根据代码库当前状态、用户请求，以及游戏引擎、美术风格等架构决策，判断游戏处于哪个开发阶段，并从该阶段对应的流程开始。各阶段流程详见下一节。
• 搭建新项目时，不要依赖你对项目设置方式的内置知识——自你接受训练以来，很多内容可能已经变了。请查找最新版本的文档，或请用户提供文档链接。阅读所用框架和库最新的安装说明，并根据技术栈以及项目已有的设置执行。
• 始终优先使用引擎或框架的官方脚手架命令，而不是手动创建文件。 示例：Phaser 使用 npm create @phaserjs/game@latest；Three.js 使用 npm create vite@latest（然后运行 npm install three）；Unity 使用 -createProject CLI（Windows 上运行 "C:\Program Files\Unity\Hub\Editor\<version>\Editor\Unity.exe" -createProject "<path>" -quit，macOS 上运行 /Applications/Unity/Hub/Editor/<version>/Unity.app/Contents/MacOS/Unity -createProject <path> -quit），或使用 Unity Hub 的“新建项目”对话框。对于 Godot/Unreal，请让用户从编辑器创建项目。手写 package.json、打包器配置或引擎入口文件，在添加第二个库时就会导致版本不匹配——不要这样做。如果找不到官方脚手架工具，用户也无法提供相关信息，请让用户自行初始化项目，待项目准备就绪后再继续会话，不要自行拼凑设置。完整指南和各引擎示例见 scaffold.md 第 3 步。
• 如果用户对核心玩法循环、架构等内容提出重大更改，请确保更新 docs/ 文件夹中的相关文档，准确反映这些更改。对于重大的架构决策，应记录到 docs/architectural-decisions，以便日后在变更日志中引用。这些变更日志必须详细说明变更原因。做出这些决策时，还必须更新 docs/gameplan.md，并在其中引用相关 AD 文档。
• 开发阶段的每次代码更改后，都要运行实时迭代子流程。 这是标准的实时验证循环（控制台 → render_game_to_text() → advanceTime() → 如有视觉内容则截图 → 用户检查）。只有完成迭代后，更改才算“完成”。
• 先编写会失败的测试，再编写实现。 测试是验收标准的可执行形式——当前里程碑中每项可检查的 AC，至少都必须有一个断言该标准的测试；测试必须先编写，并在触及任何实现代码前，确认它因正确的原因而失败。游戏玩法逻辑和视觉基线使用 Playwright（遵循 /qa-game）；纯辅助函数使用单元测试；多人游戏使用多客户端 Playwright。无法通过断言有效验证的视觉或手感 AC（如反馈效果、润色），必须在里程碑中明确标记为“由用户试玩验证”，不得悄悄跳过。如果 AC 太过模糊，无法据此编写测试，请先运行试玩／复现流程，将其转化为可检查的标准。禁止放宽失败的测试来让它通过——应修复实现，或更新里程碑 AC 并重写测试。
• 每次会话都要专注于单一功能。 如果用户的请求包含多个相互独立的功能或更改，在编写任何代码前，先运行范围梳理子流程：列出所有请求，将暂缓处理的请求写入 docs/backlog.md，并通过 AskUserQuestion 选出重要性与单次专注会话内交付难度最平衡的单一事项。尝试处理多个无关功能会导致上下文偏移、使实时迭代验证难以判断是哪个功能出错，并留下未完成检查的里程碑。只有用户明确坚持并认可其中的取舍时，才允许打包处理多个功能。
• 不得悄悄遗漏用户提到的任何事项。 如果会话中出现某项功能、润色事项、重构或未解决问题，但它不在当前范围内，就必须按照 templates/backlog.md 中的格式，将其追加到 docs/backlog.md。待办事项应统一记录在此——切勿依赖对话记忆或 docs/STATE.md 笔记来记住未来工作。开发流程和里程碑规划都要读取此文件。
• 用户需要路线图时，运行里程碑规划，不要临时发挥。 每当用户询问“下一步做什么？”／“我们需要哪些里程碑？”／“还剩什么要交付？”——或者 docs/gameplan.md 尚未完成，而开放中的里程碑已全部结束时——就应根据 gameplan 与当前状态及待办事项之间的差距推导出接下来 1–3 个里程碑，优先安排能够推动架构建设的事项，然后通过 AskUserQuestion 确认，再编写任何里程碑文件。最多提出 3 个：后续里程碑会随着当前里程碑交付而变化，因此过度承诺会浪费规划精力。绝不要提出退出条件无法写成“用户执行 X → 观察到 Y”的里程碑——模糊的目标会产生模糊的里程碑。
• 任何已过构思阶段的项目，其项目根目录下都必须有 AGENTS.md。 这是一个跨工具、无条件读取的约束文件，可确保未来会话遵循本技能的规则，即使本技能未自动触发也一样。如果发现项目已过构思阶段但没有 AGENTS.md，请先运行 agents-bootstrap 子流程，再继续其他工作。
• 无论项目处于哪个阶段，处理项目时都必须遵循该阶段规定的流程。

最小可行文档模式

如果用户对文档开销提出异议（“直接写代码”“跳过文档”），不要默默放弃文档规则——跨会话偏差正是这样开始的。请改用最小可行文档模式，并告诉用户你正在这样做：

• 可以用一条里程碑记录（标题 + 一行 AC）代替完整的里程碑文档。
• 仍必须更新 docs/STATE.md——哪怕只写一行。
• 如果 docs/gameplan.md 和 docs/tech.md 尚不存在，则仍必须创建（否则下一次会话就没有事实依据）。
• 仅当变更_不是_顶层架构决策时，才可以推迟 ADR。引擎、语言和技术栈 ADR 不可跳过。

重点是精简文档，而不是删除文档。如果用户完全不想要任何文档，这说明他们想要的是另一种工具——请如实说明，而不是以降级状态运行此技能。

2. 阶段

构思阶段

用户对游戏有一个想法，但还没有代码库或相关文档。也许他们已经创作了一些概念图，或构思了一些世界观设定。在此阶段，你应帮助用户头脑风暴、完善并打磨游戏创意和玩法循环。

流程

请参考此文档了解构思阶段的流程，并遵循该流程。

阶段完成要求

• 在项目目录中创建 docs/ 文件夹
• 根据与用户的头脑风暴和规划，编写包含详细游戏信息的 docs/gameplan.md
• 编写包含详细技术栈信息的 docs/tech.md，并说明每个库/框架的用途
• 存在 docs/architectural-decisions/ 文件夹，其中包含用于确定引擎、语言和美术风格决策的 0001-engine-and-stack.md

如果项目目录尚未创建，请征求用户许可，以创建新的项目目录并在其中编写文件夹/文件。进入下一阶段前，请让用户在项目目录中开启新会话，使其成为当前工作目录（CWD）。为新会话提供恢复提示词。

脚手架阶段

游戏构想确定后，帮助用户搭建项目脚手架。搭建项目脚手架所用的方法取决于项目采用的技术栈。

流程

请参考此文档了解脚手架阶段的流程，并遵循该流程。

阶段完成要求

• 项目目录中存在初始项目文件
• 已安装依赖项
• 游戏能在浏览器中启动（或在引擎的运行模式中启动），初始场景可以渲染，且控制台没有错误
• 项目根目录下存在 AGENTS.md 和 CLAUDE.md（请参阅 agents-bootstrap sub-pipeline）
• 后续 Agent 无需进一步设置，就能通过一个约定俗成的命令（npm run dev 或引擎的等效命令）运行项目

仅仅“没有编译错误”还不够——项目可能构建成功，却在启动时崩溃。宣布此阶段完成前，必须按照 scaffold.md 中的要求进行冒烟测试。

开发阶段

这是最长的阶段，也可能永无止境。此处的流程极其重要，适用于本项目的所有功能开发。如果用户要求你修复 Bug，则可以暂缓执行此流程，以便快速修复 Bug 并专注于排错。

流程

请参考此文档了解开发阶段的流程，并遵循该流程。

此阶段没有完成要求，因为它是一个可能永无止境的持续阶段；流程文档中的里程碑包含相关要求和验收标准。

3. 里程碑

在开发阶段流程中，你将使用里程碑作为不同大型任务范围的事实依据。这些里程碑位于 docs/milestones/*.md 中。

每个里程碑都应包含以下内容，但不限于此：

• 目标：里程碑的主要目标，详细说明所做更改的内容。
• 范围：列出任务范围内的更改。
• 验收标准：里程碑中的子任务复选框列表。必须在里程碑标记为完成前进行验证并完成这些子任务。
• 退出条件：用户必须验证的最终条件，满足后才能将里程碑标记为完成。

所有大型更改都必须以里程碑文档为依据，或确保更改以现有里程碑文档为依据。唯一的例外是无需大量规划的小型更改、一般性错误修复，或用户要求的后续更改，前提是这些更改属于当前里程碑的范围。

不值得设立里程碑的小型功能添加或更改可以暂缓处理。如果这些更改会在将来发挥作用，就必须记录在里程碑中。遇到此类情况时，可以修订里程碑文档。

实现结束时，必须确保里程碑文档保持更新，并勾选已完成的验收标准，否则后续会话会误以为里程碑尚未完成。请确保用户在继续或标记为完成之前，先测试每个里程碑的退出条件。

规则

1. 里程碑必须按顺序排列，并且每个里程碑都必须包含上述必需部分
2. 选择能够说明交付顺序的最小里程碑集合
3. 将架构层面的基础工作安排在 UX 润色之前
4. 如果里程碑之间存在依赖关系，必须在里程碑文档中说明完成顺序

追加还是新建里程碑

会话期间出现新工作时，判断是扩展当前里程碑还是新建一个里程碑：

• 将验收标准追加到当前里程碑：当新工作是对当前里程碑既有目标范围内的完善时，例如明确行为、细化检查，或将现有验收标准拆分为两个可检查的项目。
• 新建里程碑：当新工作超出当前目标范围，但与项目相关时，例如一个新系统、新功能领域，或为未来里程碑铺路的重构。在新里程碑的 frontmatter 中使用 Depends on: 字段记录依赖顺序。
• 新建后续问题（无里程碑）：当工作规模小、范围孤立且不会提前规划时，例如拼写错误、单行修复或明显的清理工作。如果与当前里程碑有直接关联，也可以一并处理。

如有疑问，优先新建里程碑，而不是不断扩充当前里程碑。臃肿的里程碑会掩盖进展，也会让退出条件更难测试。

4. 重要文件

docs/gameplan.md

关于游戏和游戏构想的主要事实依据。包含游戏玩法循环、规则、游戏主要构想、美术风格等。

何时阅读

每次会话开始时。阅读里程碑时。收集与用户请求相关的游戏背景信息时。

何时编写

用户想要更改游戏运行方式或规则发生变化时，等等。这里是游戏应如何运行的主要事实依据。

docs/tech.md

技术栈的主要事实依据。

何时阅读

每次会话开始时。规划里程碑和架构决策时。

何时编写

向技术栈中添加新技术，或更换正在使用的核心游戏引擎、库或框架时。

docs/milestones/*.md

用于记录不同功能和任务的详细里程碑，这些功能和任务最终将构成游戏。

何时读取

在实施之前。当用户要求你对代码库进行修改时。以及任何需要了解迄今为止已完成事项的相关背景信息时。

何时写入

当用户要求添加尚未在代码库中实现的新功能或进行更改时。当用户希望将旧里程碑全面重构等。

除非用户明确要求更改，或你正在勾选验收标准，否则编写里程碑后无需更新。

docs/architectural-decisions/*.md

针对不同顶层架构决策的详细 ADR。创建 ADR 时，请使用 templates/adr.md。第一个 ADR（0001）应在构思阶段结束时创建，用于确定引擎、语言和美术风格方面的决策。

docs/backlog.md

单文件、仅追加的目录，用于记录用户提到但在记录该事项的会话中决定暂缓的所有功能、润色项、重构或待解决问题。这里是“以后再做”事项的归档位置。首次通过范围梳理暂缓某个事项时，根据 templates/backlog.md 创建此文件。

转入计划的条目应勾选，并链接到纳入该条目的里程碑，不应删除。拒绝的条目应使用删除线标记，并附上一行原因。保留历史记录至关重要：后续会话需要了解曾考虑过哪些事项、何时考虑，以及暂缓或拒绝的原因。

何时读取

• 创建任何新里程碑之前（开发流程第 2 步）。
• 在 scope-triage 第 2 步中，避免重复添加事项。
• 在 session-start 期间，列出用户可能想要纳入计划的事项。
• 当用户询问“接下来做什么？”且未完成的里程碑中没有明显答案时。

何时写入

• 范围梳理暂缓某项事项时。
• 会话中途出现功能、润色或重构需求，但超出当前里程碑范围时。
• 用户随口提到某个想法时（“哦，我们以后应该……”）。立即记录下来，避免遗忘。

docs/STATE.md

单文件会话交接记录，说明上次会话的最后操作、当前里程碑和下一步具体任务。由 session-start 子流程首先读取，并在任何取得进展的会话结束时更新。请使用 templates/state.md。

何时读取

在现有项目的每次会话开始时，首先读取此文件，然后再查看其他文档。

何时写入

在任何修改了代码、文档或决策的会话结束时。哪怕只写一行也比不写好——目的是确保下次会话能够延续进展。

AGENTS.md 和 CLAUDE.md（项目根目录）

用于跨会话、跨工具强制执行规则的文件。在会话开始时，Cursor、Aider、Codex、Claude 和其他 Agent 工具都会无条件读取 AGENTS.md，其保证性强于匹配技能描述。CLAUDE.md 是指向 AGENTS.md 的单行指针，确保两个文件始终保持一致。

由 agents-bootstrap 子流程使用 templates/agents.md生成。

何时读取

其他 Agent 会读取 AGENTS.md——在常规的 make-game 会话中，你无需读取它，因为 docs/ 才是事实来源。进行一致性审计、用户报告外部 Agent 忽略了规则，或准备重新生成该文件之前，请读取它。

何时写入

• 脚手架阶段结束时（必须执行）。
• 在 session-start 的文档回填分支中，gameplan.md 和 tech.md 创建后。
• 顶层技术栈或架构发生更改后——重新生成。
• doc-drift 审计指出 AGENTS.md 已过时后。

AGENTS.md 中的每条架构规则都必须同时存在于 docs/tech.md 或某个 ADR 中。AGENTS.md 是事实来源文档的映射，而非独立的事实来源。

5. 模板

创建此技能要求的任何文档（gameplan.md、tech.md、里程碑、ADR、STATE.md）时，请复制 templates/ 中的结构，而不要自行发挥。在不同会话中保持结构一致，是此技能中最有效的防偏移机制。

6. 子流程

这些子流程可用于开发过程中的个别步骤，例如素材生成、背景设定构建、游戏循环构建、研究等。

请参阅本文档，查看当前所有可用的子流程。仅在任务需要时使用。开始自己的工作流程前，请务必先查看是否有可用的子流程。

7. 其他技能

你也可以考虑为项目安装其他技能。game-creator 技能套件和插件中还有许多其他技能，可以与此技能搭配使用。

请参阅本文档，查看可安装到项目目录中的技能。这些技能可以根据你正在开发的项目，帮助完成开发、规划、素材生成等工作。