make-game

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Make Games

游戏制作

When working with a user to create a video game, reference the skills/pipelines/commands provided to help the user create a perfect pipeline for their game development.

Based on the state of the user's request, current codebase, and stage of development, choose the proper steps to take with the user to complete their request.

在协助用户制作视频游戏时，请参考提供的技能/流程/命令，帮助用户打造完善的游戏开发流程。

根据用户的请求状态、当前代码库和开发阶段，选择合适的步骤来完成用户的需求。

When to Use

使用场景

Use this skill when:

The user is brainstorming or describing a game idea (no project directory required — the idea phase exists exactly for this)
The current working directory is a game project (has
```
docs/
```
, source files, or an engine config like
```
package.json
```
with Phaser/Three.js, a Unity
```
Assets/
```
, a Godot
```
project.godot
```
, etc.)
The user wants to add gameplay features, fix gameplay bugs, work on assets, or iterate on game design

Do not use this skill when:

The user's request is unrelated to game development (general web apps, CLI tools, libraries, infrastructure, data work, etc.)
The user explicitly asks for a non-game artifact (e.g. "build me a chat app")
The user wants a one-shot viral game from a tweet, news story, or short prompt — shipped end-to-end in a single session with no milestone planning. Use
```
/viral-game
```
instead. That pipeline is opinionated (Phaser/Three.js, here.now, Play.fun) and trades the planning rigor of this skill for ~10-minute time-to-deploy. If a
```
/viral-game
```
session outgrows itself (the user starts asking for milestones, ADRs, or long-term iteration), they should switch back to this skill.

在以下场景中使用本技能：

用户正在头脑风暴或描述游戏创意（无需项目目录——创意阶段正是为此设计）
当前工作目录是游戏项目（包含
```
docs/
```
、源文件，或引擎配置文件，如带有Phaser/Three.js的
```
package.json
```
、Unity的
```
Assets/
```
目录、Godot的
```
project.godot
```
等）
用户想要添加玩法功能、修复玩法漏洞、处理游戏资产或迭代游戏设计

请勿在以下场景中使用本技能：

用户的请求与游戏开发无关（通用Web应用、CLI工具、库、基础设施、数据处理等）
用户明确要求制作非游戏类产物（例如“帮我做一个聊天应用”）
用户想要基于推文、新闻或简短提示制作一次性爆款游戏——在单个会话中从头部署完成，无需里程碑规划。此时应改用
```
/viral-game
```
。该流程具有倾向性（采用Phaser/Three.js、here.now、Play.fun），以牺牲本技能的规划严谨性为代价，实现约10分钟的部署时间。如果
```
/viral-game
```
会话的需求超出范围（用户开始询问里程碑、ADR或长期迭代），应切换回本技能。

1. Rules

1. 规则

No code before plan. If
```
docs/gameplan.md
```
does not exist, you MUST run the idea-phase pipeline to completion — gameplan,
```
docs/tech.md
```
, and ADR-0001 written and user-confirmed — before creating any source files, running engine scaffolders, installing dependencies, or otherwise touching code. A detailed-sounding user prompt is not a substitute for the idea-phase questions: even if the user says "3D racing game with pixel art shaders," you do not yet know the gameplay loop, win condition, controls, scope, or target session length, and improvising those choices is the single biggest cause of refactoring later. Treat this as a hard tripwire — if you find yourself about to scaffold a project without a written gameplan the user has signed off on, stop and run the idea phase first. The clarifying-questions checklist in idea.md is the minimum bar; do not skip items because the prompt "seems clear."
Always run the session-start sub-pipeline first when entering a session in an existing project directory. It recovers context (
```
docs/STATE.md
```
,
```
docs/gameplan.md
```
,
```
docs/tech.md
```
, milestones), determines the current phase, and confirms the next step with the user. Skip only if there is no project directory yet (idea-phase brand-new conversation).
When asking the user questions, use the
```
AskUserQuestion
```
tool. If you can provide some recommendations as multiple choice answers, with the option for the user to provide their own answer, that would be optimal.
- When asking questions, keep them focused, clear, and detailed. If the question may have some logical answers you can think of, provide those as possible answers for the user. This will help if they want to think of a solution themselves as well since they can pull from the different options you provided to curate the perfect answer.
- If you have prior memory or experience with the user, guage their technical ability/expertise, and shape your questions around that. If they do not seem technically advanced, make sure to ask questions in a way they would understand. Offering explanations for more advanced topics along with the question so they aren't answering them blindly.
Based on the current state of the codebase, the users request, and architectural decisions such as game engine, art style, etc. decide which phase of development the game is in, and start with the pipeline outlined for said phase. They are described in the next section.
When scaffolding a new project, do not use your embedded knowledge of how to setup the project — many things might have changed since you were trained. Find the newest version of the documentation, or ask the user to find a link and provide it to you. Read the newest installation instructions for the frameworks/libraries you are working with, and follow them according to the stack and setup the project already has set.
Always prefer the engine's or framework's official scaffolding command over hand-rolling files. Examples:
```
npm create @phaserjs/game@latest
```
for Phaser;
```
npm create vite@latest
```
(then
```
npm install three
```
) for Three.js; Unity's
```
-createProject
```
CLI (
```
"C:\Program Files\Unity\Hub\Editor\<version>\Editor\Unity.exe" -createProject "<path>" -quit
```
on Windows,
```
/Applications/Unity/Hub/Editor/<version>/Unity.app/Contents/MacOS/Unity -createProject <path> -quit
```
on macOS) or Unity Hub's "New project" dialog. For Godot/Unreal, ask the user to create the project from the editor. Hand-written
```
package.json
```
, bundler configs, or engine entry points cause version mismatches the moment a second library is added — do not do it. If you cannot find an official scaffolder and the user cannot point you to one, ask the user to initialize the project themselves and resume the session once it's ready, rather than improvising a setup. Full guidance and per-engine examples live in scaffold.md step 3.
If the user has a large change to anything regarding core gameplay loop, architecture, etc., ensure that the relevant documentation in the
```
docs/
```
folder is updated to reflect their changes. For large architecture decisions, we should write to
```
docs/architectural-decisions
```
that can be referenced later with the changelogs. These changelogs must be detailed and include the reason for changing them. The
```
docs/gameplan.md
```
file must also be updated when these decisions are made, with referenced to the AD documents behind the changes.
After every code change in the development phase, run the live-iterate sub-pipeline. It is the canonical real-time verification loop (console →
```
render_game_to_text()
```
→
```
advanceTime()
```
→ screenshot if visual → user check). A change is not "done" until it has been iterated on.
Write failing tests before writing the implementation. Tests are the executable form of acceptance criteria — every checkable AC for the active milestone must have at least one test that asserts it, written first and confirmed to fail for the right reason before any implementation code is touched. Use Playwright (per
```
/qa-game
```
) for gameplay logic and visual baselines; unit tests for pure helpers; multi-client Playwright for multiplayer. Visual/feel AC that can't be meaningfully asserted (juice, polish) must be explicitly marked "verified by user playtest" in the milestone — never silently skipped. If the AC is too vague to write a test against, run playtest / repro first to make it checkable. Loosening a failing test to make it pass is forbidden — fix the implementation, or update the milestone AC and rewrite the test.
Keep every session focused on a single feature. When the user's request implies more than one independent feature or change, run the scope-triage sub-pipeline before any coding: enumerate the asks, write the deferred ones to
```
docs/backlog.md
```
, and pick the single best balance of important and easy to ship in one focused session via
```
AskUserQuestion
```
. Sessions that try to carry multiple unrelated features cause context drift, make live-iterate verification ambiguous (which feature broke?), and leave milestones half-checked. Bundling features is allowed only when the user explicitly insists and acknowledges the trade-off.
Nothing the user mentions gets silently dropped. If a feature, polish item, refactor, or open question surfaces during a session but is out of scope, it must be appended to
```
docs/backlog.md
```
using the shape from
```
templates/backlog.md
```
. The backlog is the single home for "later" — never rely on conversation memory or
```
docs/STATE.md
```
notes to remember future work. The development pipeline and milestone planning both read this file.
When the user needs a roadmap, run milestone planning, don't improvise. Whenever the user asks "what's next?" / "what milestones do we need?" / "what's left to ship?" — or whenever open milestones run out before
```
docs/gameplan.md
```
is satisfied — derive the next 1–3 milestones from the gap between the gameplan and current state + backlog, ordered architecture-enabling first, then confirm via
```
AskUserQuestion
```
before writing any milestone files. Cap proposals at three: future milestones will look different once the next ones ship, so over-committing wastes planning effort. Never propose a milestone whose exit condition can't be written as "User does X → observes Y" — vague targets produce vague milestones.
AGENTS.md
must exist at the project root for any project past the idea phase. It is the cross-tool, unconditionally-read enforcement file that guarantees future sessions follow this skill's rules even when the skill itself doesn't auto-trigger. If you find a project past the idea phase without an
```
AGENTS.md
```
, run the agents-bootstrap sub-pipeline before continuing other work.
You MUST follow the pipelines outlined by each phase when working on the project based on the phase the project is in.

先规划再编码。如果
```
docs/gameplan.md
```
不存在，必须先完整执行创意阶段流程——完成游戏规划文档、
```
docs/tech.md
```
和ADR-0001的编写并获得用户确认——之后才能创建任何源文件、运行引擎脚手架、安装依赖或进行其他代码操作。即使用户的提示听起来很详细，也不能替代创意阶段的问题：即便用户说“带有像素艺术着色器的3D赛车游戏”，你仍不清楚其玩法循环、胜利条件、控制方式、范围或目标会话时长，而随意决定这些内容是后续重构的最大诱因。将此视为硬性规则——如果你发现自己要在没有用户签字确认的书面游戏规划的情况下搭建项目，请立即停止并先执行创意阶段。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()
```
→如有视觉内容则截图→用户检查）。变更未经过迭代验证不算“完成”。
先编写失败的测试用例，再编写实现代码。测试是验收标准的可执行形式——当前里程碑的每个可检查验收标准都必须至少有一个测试用例来断言它，且必须先编写测试用例并确认其因正确原因失败，再编写实现代码。使用Playwright（配合
```
/qa-game
```
）测试玩法逻辑和视觉基线；使用单元测试测试纯辅助函数；使用多客户端Playwright测试多人游戏。对于无法通过测试有效断言的视觉/体验验收标准（如特效、润色），必须在里程碑中明确标记为“通过用户游戏测试验证”——绝不能默默跳过。如果验收标准过于模糊无法编写测试，请先执行游戏测试/复现流程使其可检查。禁止修改失败的测试用例使其通过——应修复实现代码，或更新里程碑验收标准并重写测试用例。
每次会话专注于单个功能。当用户的请求涉及多个独立功能或变更时，在编码前先执行范围梳理子流程：列出所有需求，将暂时不处理的需求写入
```
docs/backlog.md
```
，并通过
```
AskUserQuestion
```
选择一个重要且能在单个专注会话中完成的最佳需求。尝试同时处理多个无关功能的会话会导致上下文偏移，使实时迭代验证变得模糊（哪个功能出问题了？），并导致里程碑部分完成。仅当用户明确坚持并认可相关权衡时，才允许合并功能。
用户提到的任何内容都不能被忽略。如果会话中出现某个功能、润色项、重构或未解决问题，但超出当前范围，必须使用
```
templates/backlog.md
```
的格式将其添加到
```
docs/backlog.md
```
中。待办事项是所有“后续工作”的唯一记录位置——绝不能依赖对话记忆或
```
docs/STATE.md
```
中的笔记来记住未来的工作。开发流程和里程碑规划都会读取此文件。
当用户需要路线图时，执行里程碑规划流程，而非随意规划。每当用户询问“下一步是什么？”/“我们需要哪些里程碑？”/“还有哪些工作要完成？”——或者当未完成的里程碑在
```
docs/gameplan.md
```
的需求满足前耗尽时——根据游戏规划与当前状态+待办事项之间的差距推导接下来的1-3个里程碑，优先安排架构赋能的工作，然后通过
```
AskUserQuestion
```
确认后再编写任何里程碑文件。提案最多不超过3个：当下一个里程碑完成后，未来的里程碑会有所不同，过度规划会浪费精力。绝不要提出退出条件无法写成“用户执行X→观察到Y”的里程碑——模糊的目标会产生模糊的里程碑。
任何超出创意阶段的项目，其根目录下必须存在
AGENTS.md
文件。这是跨工具、强制读取的规则文件，确保即使本技能未自动触发，未来的会话仍会遵循本技能的规则。如果你发现某个超出创意阶段的项目没有
```
AGENTS.md
```
文件，请先执行Agent初始化子流程，再继续其他工作。
根据项目所处的阶段，必须遵循各阶段概述的流程开展工作。

Minimum-viable doc mode

最小文档模式

If the user pushes back on documentation overhead ("just code it", "skip the docs"), do not silently abandon the doc rules — that is exactly how cross-session drift starts. Instead, downgrade to minimum-viable doc mode and tell the user you're doing so:

One-line milestone entry (title + one-line AC) is acceptable in place of a full milestone doc.
```
docs/STATE.md
```
updates remain mandatory — even one line.
```
docs/gameplan.md
```
and
```
docs/tech.md
```
remain mandatory if they don't yet exist (otherwise the next session has no source of truth).
ADRs may be deferred only if the change is not a top-level architectural decision. Engine, language, and stack ADRs cannot be skipped.

The point is to compress the docs, not delete them. If the user wants no docs at all, that signals they want a different tool — say so honestly rather than running this skill in a degraded state.

如果用户反对文档开销（“直接编码”、“跳过文档”），请勿默默放弃文档规则——这正是跨会话上下文偏移的根源。相反，降级为最小文档模式并告知用户：

可以用一行式里程碑条目（标题+一行验收标准）替代完整的里程碑文档。
```
docs/STATE.md
```
的更新仍然是强制性的——即使只有一行内容。
如果
```
docs/gameplan.md
```
和
```
docs/tech.md
```
尚未存在，仍必须创建（否则下一个会话将没有事实依据）。
仅当变更不是顶级架构决策时，才可推迟编写ADR。引擎、语言和技术栈的ADR不能跳过。

核心是压缩文档，而非删除文档。如果用户完全不需要文档，这表明他们需要其他工具——请如实告知，而非在降级状态下运行本技能。

2. Phases

2. 阶段

Idea Phase

创意阶段

The user has an idea for a game, but no codebase or documentation around it yet. Maybe there is concept art or some sort of lore they've come up with. In this phase, you should help the user brainstorm, develop, and iron out their game idea and gameplay loop.

用户有游戏创意，但尚未建立代码库或相关文档。可能已有概念艺术或设定的背景故事。在本阶段，你应帮助用户头脑风暴、完善并细化游戏创意和玩法循环。

Pipeline

流程

Refer to this document for the idea phase pipeline. Follow it.

请参考此文档中的创意阶段流程并严格遵循。

Requirements for Phase Completion

阶段完成要求

```
docs/
```
folder is created in the project directory
```
docs/gameplan.md
```
is written with detailed game information based on brainstorming and planning with the user
```
docs/tech.md
```
is written with detailed tech stack information, with the use of each library/framework included
```
docs/architectural-decisions/
```
folder exists with
```
0001-engine-and-stack.md
```
locking the engine, language, and art-style decisions

If the project directory has not been created yet, ask the user for permission to create a new project directory and write the folders/files there. Before moving to the next phase, ask the user to start a new session in the project directory so it becomes your CWD. Provide a resume prompt for the new session.

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

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

Scaffold Phase

搭建阶段

After the idea for the game has been solidified, help the user scaffold the project. The methods used to scaffold said project will depend on the tech stack used for the project.

游戏创意确定后，帮助用户搭建项目。搭建方法取决于项目使用的技术栈。

Pipeline

流程

Refer to this document for the scaffold phase pipeline. Follow it.

请参考此文档中的搭建阶段流程并严格遵循。

Requirements for Phase Completion

阶段完成要求

Initial project files exist in the project directory
Dependencies are installed
Game boots in the browser (or the engine's play mode), the initial scene renders, and the console is error-free
```
AGENTS.md
```
and
```
CLAUDE.md
```
exist at the project root (see agents-bootstrap sub-pipeline)
A future agent can run the project with one well-known command (
```
npm run dev
```
, engine equivalent) without further setup

"No compilation errors" alone is not sufficient — projects often build clean and crash on boot. The smoke test in

scaffold.md

is mandatory before declaring this phase complete.

项目目录中存在初始项目文件
已安装依赖
游戏可在浏览器（或引擎的播放模式）中启动，初始场景可渲染，控制台无错误
项目根目录下存在
```
AGENTS.md
```
和
```
CLAUDE.md
```
（请参考Agent初始化子流程）
未来的Agent可通过一个通用命令（
```
npm run dev
```
或引擎等效命令）运行项目，无需额外设置

仅“无编译错误”是不够的——项目通常能正常构建但启动时崩溃。在宣布本阶段完成前，必须执行scaffold.md中的冒烟测试。

Development Phase

开发阶段

This phase is the longest, and possibly never ending phase. The pipeline here is extremely important, and should be applied to any and all feature work in this project. If the user is asking you to fix a bug, you can defer this pipeline to quickly fix said bug and focus on bug fixing.

本阶段耗时最长，可能永远不会结束。本阶段的流程至关重要，应应用于项目中的所有功能开发工作。如果用户要求修复漏洞，可以暂时跳过本流程，专注于漏洞修复。

Pipeline

流程

Refer to this document for the development phase pipeline. Follow it.

There are no requirements for phase completion, as this is an active phase which possibly never ends, and the milestones within the pipeline document requirements and acceptance criteria.

请参考此文档中的开发阶段流程并严格遵循。

本阶段没有完成要求，因为这是一个持续进行的阶段，流程文档中会列出里程碑的要求和验收标准。

3. Milestones

3. 里程碑

Within the development phase pipeline, you will use milestones as a source of truth for different large scoped tasks. These milestones live within

docs/milestones/*.md

Every milestone should include but not be limited to the following:

Objective: The main goal of the milestone, with a detailed description of what the changes being made are.
Scope: List of changes scoped to the task
Acceptance Criteria: Checkbox list of sub-tasks within the milestone that must be verified and completed before the milestone can be marked as done.
Exit Condition: The bottom line condition that must be verified by the user to have the milestone marked as complete.

You MUST ground all large changes in a milestone document, or ensure your changes are grounded in an existing milestone document. The only exceptions to this are small changes that would not require extreme planning, general bug fixes, or follow up changes that the user asks you to make, so long as they are within the scope of the milestone you're working on.

Small feature additions or changes that would not warrant a milestone may be deferred. If the changes would matter in the future, they must be documented in a milestone. You can revise milestone documents for cases like this.

At the end of implementation, you must ensure we keep milestone documentation updated and AC boxes checked off, otherwise future sessions will assume the milestones are incomplete, when they are complete. Ensure the user tests the exit condition of each milestone before moving on or marking as complete.

在开发阶段流程中，你将使用里程碑作为不同大型任务的事实依据。这些里程碑存储在

docs/milestones/*.md

中。

每个里程碑应至少包含以下内容：

目标：里程碑的主要目标，详细描述所做的变更
范围：任务涉及的变更列表
验收标准：里程碑内必须验证并完成的子任务复选框列表
退出条件：必须由用户验证的底线条件，满足后里程碑才可标记为完成

所有重大变更都必须基于里程碑文档，或确保你的变更基于现有里程碑文档。唯一的例外是无需极端规划的小型变更、常规漏洞修复，或用户要求的后续变更（只要这些变更在当前里程碑的范围内）。

无需里程碑的小型功能添加或变更可推迟处理。如果这些变更对未来有影响，必须记录在里程碑中。你可以为此修订里程碑文档。

实现完成后，必须确保里程碑文档已更新且验收标准复选框已勾选，否则未来的会话会误认为里程碑未完成。在继续或标记完成前，请确保用户测试了每个里程碑的退出条件。

Rules

规则

Milestones must be ordered and each one must have the required sections listed above
Choose the smallest milestone set that explains delivery order
Put architecture enabling work before UX polish
If milestones depend on each other, it's important to mention the order in which they must be completed within the milestone documents

里程碑必须有序排列，且每个里程碑必须包含上述必填部分
选择能说明交付顺序的最小里程碑集合
优先安排架构赋能工作，再进行UX润色
如果里程碑之间存在依赖关系，必须在里程碑文档中提及完成顺序

Append vs spawn a new milestone

追加还是新建里程碑

When new work surfaces during a session, decide whether to extend the current milestone or open a new one:

Append AC to the current milestone when the work is in-scope refinement of the milestone's existing objective — clarifying behavior, tightening a check, splitting an existing AC into two checkable items.
Spawn a new milestone when the work is out of scope for the current objective but related to the project — a new system, a new feature area, a refactor that enables future milestones. Use the
```
Depends on:
```
field in the new milestone's frontmatter to capture the ordering relationship.
Open a follow-up issue (no milestone) when the work is small, isolated, and would never be planned ahead of time — a typo, a one-line fix, an obvious cleanup. These can ride on the current milestone if they're trivially adjacent.

When in doubt, prefer spawning a new milestone over inflating the current one. A bloated milestone hides progress and makes the exit condition harder to test.

当会话中出现新工作时，决定是扩展当前里程碑还是新建里程碑：

向当前里程碑追加验收标准：当工作是对里程碑现有目标的范围内细化——明确行为、收紧检查条件、将现有验收标准拆分为两个可检查项。
新建里程碑：当工作超出当前目标范围但与项目相关——新系统、新功能领域、为未来里程碑赋能的重构。在新里程碑的前置内容中使用
```
Depends on:
```
字段记录顺序关系。
创建后续问题（无里程碑）：当工作规模小、独立且无需提前规划——拼写错误、单行修复、明显的清理工作。如果这些工作与当前里程碑密切相关，可附带处理。

如有疑问，优先新建里程碑而非扩大当前里程碑。臃肿的里程碑会掩盖进度，使退出条件更难测试。

4. Important Files

4. 重要文件

docs/gameplan.md

docs/gameplan.md

The main source of truth around the game and idea of the game. Includes gameplay loop, rules, main game idea, art style, etc.

关于游戏及其创意的主要事实依据。包括玩法循环、规则、核心游戏创意、美术风格等。

When to read

读取时机

At the start of every session. When reading through milestones. When gathering context about the game around the user's request.

每次会话开始时。阅读里程碑时。围绕用户请求收集游戏上下文时。

When to write

写入时机

When the user wants to change how the game works, when rules change, etc. This is the main source of truth for how the game should work.

当用户想要改变游戏运作方式、规则变更等情况时。这是游戏应如何运作的主要事实依据。

docs/tech.md

docs/tech.md

The main source of truth on the tech stack.

关于技术栈的主要事实依据。

When to read

读取时机

At the start of every session. When planning out milestones and architectural decisions.

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

When to write

写入时机

When adding new tech to the stack or changing out the core game engines/libraries/frameworks being used.

当向技术栈添加新技术或更换核心游戏引擎/库/框架时。

docs/milestones/*.md

docs/milestones/*.md

Detailed milestones for different features and tasks that eventually build the game.

用于构建游戏的不同功能和任务的详细里程碑。

When to read

读取时机

Prior to implementation. When users ask for you to perform changes to the codebase. Anytime you need relevant prior information to what's been done so far.

实现前。用户要求你对代码库进行变更时。任何需要了解已完成工作的相关信息时。

When to write

写入时机

When a user asks for new features, changes, etc. that have not yet been implemented in the codebase. When the user wants a full refactor to an older milestone, etc.

You should not have to update milestones once written unless there are explicit changes requested by the user, or if you are checking off acceptance criteria.

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

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

docs/architectural-decisions/*.md

docs/architectural-decisions/*.md

Detailed ADRs for different top-level architectural decisions. Use

templates/adr.md

when creating one. The first ADR (

) should be created at the end of the idea phase to lock in engine / language / art-style decisions.

不同顶级架构决策的详细ADR。创建时请使用

templates/adr.md

。第一个ADR（

）应在创意阶段结束时创建，用于锁定引擎/语言/美术风格的决策。

docs/backlog.md

docs/backlog.md

Single-file, append-only catalog of every feature, polish item, refactor, or open question the user has mentioned but that was deferred out of the session that captured it. The home for "later". Created from

templates/backlog.md

the first time scope triage defers an item.

Promoted entries get a checkbox tick and a link to the milestone that absorbed them — they are not deleted. Rejected entries are struck through with a one-line reason. The history matters: future sessions need to see what was considered, when, and why it was deferred or rejected.

单文件、仅追加的目录，记录用户提到但被当前会话推迟处理的所有功能、润色项、重构或未解决问题。这是“后续工作”的存储位置。首次进行范围梳理并推迟项目时，使用

templates/backlog.md

创建此文件。

被推进的条目会勾选复选框并链接到吸收它们的里程碑——不会被删除。被拒绝的条目会添加删除线并附带一行原因。历史记录很重要：未来的会话需要了解曾考虑过哪些内容、何时考虑以及为何推迟或拒绝。

When to read

读取时机

Before creating any new milestone (development pipeline step 2).
During scope-triage step 2, to avoid duplicating items.
During session-start, to surface items the user may want to promote.
When the user asks "what's next?" and the open milestones don't have an obvious answer.

创建任何新里程碑前（开发流程步骤2）。
范围梳理步骤2期间，避免重复条目。
会话启动期间，呈现用户可能想要推进的条目。
当用户询问“下一步是什么？”且未完成的里程碑没有明确答案时。

When to write

写入时机

Whenever scope triage defers an item.
Whenever a feature/polish/refactor surfaces mid-session but is out of scope for the current milestone.
Whenever the user mentions an idea in passing ("oh, eventually we should…"). Capture it immediately so it isn't lost.

范围梳理推迟项目时。
会话中出现功能/润色/重构但超出当前里程碑范围时。
用户随口提到某个创意时（“哦，最终我们应该……”）。立即记录以免丢失。

docs/STATE.md

docs/STATE.md

Single-file session handoff. The previous session's last action, current milestone, and the next concrete step. Read first by the session-start sub-pipeline, updated at the end of any session that made progress. Use

templates/state.md

单文件的会话交接文档。记录上一次会话的最后操作、当前里程碑和下一个具体步骤。会话启动子流程会首先读取此文件，任何取得进展的会话结束时都应更新此文件。使用

templates/state.md

。

When to read

读取时机

At the very start of every session in an existing project, before any other doc.

进入现有项目的每个会话的最开始，在读取其他文档之前。

When to write

写入时机

At the end of any session that changed code, docs, or decisions. Even one line is better than nothing — the goal is continuity for the next session.

任何修改了代码、文档或决策的会话结束时。即使只有一行内容也比没有好——目标是为下一个会话提供连续性。

AGENTS.md

and

CLAUDE.md

(project root)

AGENTS.md

和

CLAUDE.md

（项目根目录）

The cross-session, cross-tool enforcement file.

AGENTS.md

is read unconditionally by Cursor, Aider, Codex, Claude, and other agent tools at session start — a stronger guarantee than skill description matching.

CLAUDE.md

is a one-line pointer to

AGENTS.md

so the two files never drift.

Generated by the agents-bootstrap sub-pipeline using

templates/agents.md

跨会话、跨工具的规则文件。

AGENTS.md

会被Cursor、Aider、Codex、Claude和其他Agent工具在会话开始时强制读取——这比技能描述匹配的保障更强。

CLAUDE.md

是指向

AGENTS.md

的单行指针，确保两个文件不会出现偏差。

由Agent初始化子流程使用

templates/agents.md

生成。

When to read

读取时机

AGENTS.md

is read by other agents — you don't need to read it during a normal

make-game

session because the source of truth lives in

docs/

. Read it when auditing for drift, when the user reports an outside agent ignored the rules, or before regenerating it.

AGENTS.md

由其他Agent读取——在正常的

make-game

会话中你无需读取它，因为事实依据存储在

docs/

中。当审核偏差、用户报告外部Agent忽略规则，或重新生成它之前，请读取此文件。

When to write

写入时机

End of the scaffold phase (mandatory).
During the doc-backfill branch of session-start, once
```
gameplan.md
```
and
```
tech.md
```
exist.
After a top-level stack or architecture change — regenerate.
When the doc-drift audit flags
```
AGENTS.md
```
as stale.

Every architecture rule in

AGENTS.md

must also live in

docs/tech.md

or an ADR.

AGENTS.md

is a reflection of the source-of-truth docs, not its own source.

搭建阶段结束时（强制性）。
会话启动流程的文档回填分支期间，一旦
```
gameplan.md
```
和
```
tech.md
```
存在。
顶级技术栈或架构变更后——重新生成。
文档偏差审核标记
```
AGENTS.md
```
为过时后。

AGENTS.md

中的每个架构规则也必须存在于

docs/tech.md

或某个ADR中。

AGENTS.md

是事实依据文档的镜像，而非独立的事实依据。

5. Templates

5. 模板

When creating any of the docs the skill mandates (

gameplan.md

tech.md

, milestones, ADRs,

STATE.md

), copy the structure from

templates/

rather than improvising. Consistent structure across sessions is the highest-leverage anti-drift mechanism in this skill.

创建本技能要求的任何文档（

gameplan.md

、

tech.md

、里程碑、ADR、

STATE.md

）时，请复制

templates/

中的结构，而非自行编写。跨会话的一致结构是本技能中最有效的防偏差机制。

6. Sub-pipelines

6. 子流程

These sub-pipelines can be used for individual steps during development, such as asset genration, lore building, gameplay loop building, research, etc.

Refer to this document to see all currently available sub-pipelines. Use them when necessary only if the task calls for it. Always refer to sub-pipelines to see if there's one available to use before starting your own pipeline of work.

这些子流程可用于开发过程中的单个步骤，如资产生成、背景故事构建、玩法循环搭建、研究等。

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

7. Other Skills

7. 其他技能

It may be useful to install other skills to the project. There are many other skills in the

game-creator

Skill suite and plugin that can interlace with this skill.

Refer to this document to see skills you can install to the project directory that will help with development, planning, asset generation, etc based on what project you're working on.

向项目中安装其他技能可能会有所帮助。

game-creator

技能套件和插件中有许多其他技能可与本技能配合使用。

请参考此文档查看可安装到项目目录中的技能，这些技能将根据项目类型帮助你进行开发、规划、资产生成等工作。

make-game

Original

Translation

Make Games

游戏制作

When to Use

使用场景

Table of Contents

目录

1. Rules

1. 规则

Minimum-viable doc mode

最小文档模式

2. Phases

2. 阶段

Idea Phase

创意阶段

Pipeline

流程

Requirements for Phase Completion

阶段完成要求

Scaffold Phase

搭建阶段

Pipeline

流程

Requirements for Phase Completion

阶段完成要求

Development Phase

开发阶段

Pipeline

流程

3. Milestones

3. 里程碑

Rules

规则

Append vs spawn a new milestone

追加还是新建里程碑

4. Important Files

4. 重要文件

docs/gameplan.md

docs/gameplan.md

When to read

读取时机

When to write

写入时机

docs/tech.md

docs/tech.md

When to read

读取时机

When to write

写入时机

docs/milestones/*.md

docs/milestones/*.md

When to read

读取时机

When to write

写入时机

docs/architectural-decisions/*.md

docs/architectural-decisions/*.md

docs/backlog.md

docs/backlog.md

When to read

读取时机

When to write

写入时机

docs/STATE.md

docs/STATE.md

When to read

读取时机

When to write

写入时机

AGENTS.md and CLAUDE.md (project root)

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

When to read

读取时机

When to write

写入时机

5. Templates

5. 模板

6. Sub-pipelines

`docs/gameplan.md`

`docs/gameplan.md`

`docs/tech.md`

`docs/tech.md`

`docs/milestones/*.md`

`docs/milestones/*.md`

`docs/architectural-decisions/*.md`

`docs/architectural-decisions/*.md`

`docs/backlog.md`

`docs/backlog.md`

`docs/STATE.md`

`docs/STATE.md`

`AGENTS.md`
and
`CLAUDE.md`
(project root)

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