start

引导式入门

新用户的入口。不要求用户已有游戏创意、引擎或经验：它会读取项目，询问用户从哪里开始，说明它对项目的判断，并指出唯一的下一步。它绝不会自行执行该步骤。

它只会在用户明确同意后，通过辅助工具将以下设置写入 project.yaml：project.stage（及其旧版镜像 production/stage.txt）、modes.rigor 和 modes.automation。它绝不会写入 modes.review_mode 或 production/review-mode.txt，也不会写入 rigor 会影响的其他设置（modes.workflow、docs.density、qa.level、modes.story_granularity、team.size）：已写入的值会优先于 rigor 展开结果，而镜像文件的优先级高于该值。

使用提问工具提问。如果没有提问工具，就将选项编号列出，并在提问后结束本轮，等待回答。问题必须是回复中的最后内容：之后不得附加路径、备注或建议。跳过或关闭问题不算回答：请用纯文本重新提问。

第 2、4 和 5 阶段的问题会影响项目，因此无论自动化模式如何，都必须询问。引擎不属于这些问题：由 /setup-engine 选择。第 6 阶段的最后一个问题应根据 project.yaml 中已有的 modes.automation 提出，具体参见 .claude/docs/automation-modes.md；如果尚未设置，则提出该问题。

第 1 阶段：读取项目

运行 bash .claude/scripts/project-state.sh 并保留其各行内容。暂时不要展示；这些内容用于核对用户在第 2 阶段的回答。

行	用途
engine、code_root、source_files	是否已设置引擎，以及有多少代码。source_files 为 unknown 表示无法找到代码根目录：应说明这一点，绝不能说“没有代码”
concept	design/gdd/game-concept.md 或 design/game-brief.md 是否存在
gdd_files、adr	磁盘上的设计文档和架构决策（用于确定第 4 阶段的项目阶段）
prototype、sprint、milestone、story	其他已有工作
origin_url	包含 donchitos/claude-code-game-studios（不区分大小写）：克隆的远程地址仍指向模板仓库，因此推送或拉取请求会发送到那里。属于其他所有者的分支是用户自己的
stage	已记录的项目阶段（如果有）

忽略 phase_inferred：它会根据文件数量进行猜测，有代码但没有设计文档的项目并不处于 Production 阶段。如果辅助脚本运行失败，请说明这一点，并手动读取相同信息（project.yaml 中的引擎、两个概念文件、代码根目录中的文件、design/gdd/）。

辅助脚本不会报告 rigor 或自动化设置。读取 project.yaml（如果存在），并记录是否已设置 modes.rigor 和 modes.automation：已设置的值会保留，并且不再询问相应问题（第 4、5 阶段）。

回访用户（已设置引擎且存在 concept）：不提问。说明引擎、找到的概念或简介，以及审查模式：如果已设置 modes.review_mode，就使用其值；否则使用 modes.rigor 所隐含的模式（minimal → solo、standard → lean、full → full）。建议下一步使用 /help，适用时补充模板远程地址的提示，然后停止。

第 2 阶段：询问用户从哪里开始

使用提问工具询问：“欢迎！你的游戏目前处于什么起点？”选项：

• A) 还没有想法：没有游戏概念；探索并寻找想要制作的内容。
• B) 有个模糊想法：有主题、感觉或类型（“做个太空题材的游戏”“做个温馨的农场游戏”）。
• C) 概念明确：核心创意和类型已知，但还没有写下来。
• D) 已有成果：已经有设计文档、原型、代码或计划。

等待回答。如果回答与第 1 阶段的发现相矛盾，只说明一次你发现的情况，然后重新询问：例如，空项目却选择 D（“看起来这是一个全新的模板；A 或 B 是否更合适？”），或磁盘上有代码却选择 A（“我在 [code_root] 中找到了代码；你是想选 D 吗？”）。如果没有合适的选项，请让用户描述自己的情况，并据此选择后续流程。

第 3 阶段：确定下一步

只说出紧接着要做的下一步。完整路径等到第 6 阶段、明确严谨程度后再定。

• A，没有想法： 从零开始也没问题。/brainstorm open 可以自由探索；/brainstorm [hint] 可以从一个词或主题开始。下一步：/brainstorm open，或者想到提示时使用提示。将其描述为“把没有想法变成书面设计，供下一步据此构建”；设计的篇幅取决于严谨程度，因此留到第 6 阶段再定。
• B，想法模糊： 请用户用几个词描述想法，按原样接受，并说出 /brainstorm [their words]。
• C，概念明确： 请用户用一句话描述概念（类型和核心机制），用纯文本回答。然后询问：“你想如何继续？”选项：先正式确定（/brainstorm [concept] 将其写下来）/ 直接开始（现在运行 /setup-engine，之后再写设计）。 下一步由用户选择。
• D，已有工作： 说明第 1 阶段发现的内容（“[code_root] 下有 N 个源文件、N 份设计文档，引擎为 [X / 尚未设置]”）。如果尚未设置引擎，且内容不超过一个概念，下一步是 /setup-engine；否则是 /project-stage-detect。

然后说：“我稍后会说明完整路径。”

第 4 阶段：展示假设，然后保存

确定两个值。

阶段。 路径 A、B 和 C：Concept。路径 D：根据第 1 阶段的行确定：

磁盘上的内容	阶段
没有引擎，或内容不超出一个概念（gdd_files 为 0）	Concept
gdd_files 为 1 或更多，adr 为 0	Systems Design
adr 为 1 或更多	Technical Setup

严谨程度。 如果 project.yaml 中已设置 modes.rigor，保留该值并说明这一点。否则，根据用户在第 2 和第 3 阶段所说的内容，参考 .claude/docs/settings-guidance.md §3 中的信号推断：

用户提到的内容	严谨程度
开放世界、RPG、模拟、沙盒、派系、制作、经济、MMO、多人游戏、许多系统	full
发布、商业、Steam、一个明确的核心循环	standard
Game Jam、周末、原型、第一款游戏、小型、只是想试试	minimal
以上都没有，或还没有想法	minimal（默认值）

路径 B 中的提示仍然是一种描述：“某种开放世界生存模拟”对应 full。

展示卡片：

What I'll set up
  Stage:  [stage]  ([why, from what was found or picked])
  Rigor:  [value]  ([why, in the user's words] | already set)
          minimal: short brief, coarse stories, tests optional; about 4 steps to code
          standard: about 8 design documents before code; standard QA evidence
          full: everything in standard plus validation builds; evidence everywhere
  /settings changes either of these any time.

然后使用提问工具询问：“将这些内容保存到 project.yaml（并将阶段保存到 production/stage.txt）？”选项：保存 / 不保存。不要询问严谨程度本身：卡片中已显示该值，用户可以通过 /settings 修改。

• 保存： 运行 bash .claude/scripts/set-stage.sh "[stage]"，然后仅当尚未设置严谨程度时，运行 bash .claude/scripts/config-set.sh modes.rigor [value]。检查回读的行是否匹配。说：“已保存。严谨程度 [value] 会设置其他六项设置；/settings 会显示并修改这些设置。”
• 不保存或任何非明确肯定的回答：不写入任何内容，本次运行中保留这些值，并说明尚未保存。

如果辅助脚本以非零状态退出，显示其输出，说明哪个设置未写入，并继续使用本次运行的值。

第 5 阶段：询问需要确认多少内容

如果已设置 modes.automation，说“自动化级别为 [value]”，然后继续。否则询问： “最后一个问题：工作过程中，你希望我在多大程度上向你确认？”选项：

• 引导式（推荐）：由我决定小事，但遇到重大事项（范围变更、 删除、架构变更）时仍会停下来确认。
• 协作式：每个重要步骤前都先询问，并在写入前展示草稿。
• 自主式：我继续推进并记录决策，只在必须始终询问的类别上停下来。速度最快，消耗的 token 最多。

映射关系：Guided → guided，Collaborative → collaborative，Autonomous → autonomous。用户的选择即表示同意写入：运行 bash .claude/scripts/config-set.sh modes.automation [value]，除非用户在第 4 阶段拒绝保存（此时说明尚未保存）。

阶段 6：展示路径

说：“这是你在 rigor [value] 下的路径。每项技能在任何 rigor 下都可以运行；rigor 改变的是必需内容，而非允许内容。”

路径从阶段 3 指定的步骤开始。如果该步骤是 /brainstorm（路径 A 和 B，以及路径 C 的 Formalize it first），则先列出 /brainstorm，再列出 /setup-engine：两者可以各自独立运行。

minimal：4 步，运行代码

1. /setup-engine：选择并配置引擎
2. /brainstorm：编写单页 design/game-brief.md
3. /create-stories：将简报中的 MVP 列表转化为故事（无需史诗或迭代计划）
4. /dev-story：编写第一行游戏代码

standard

• 概念：/setup-engine → /brainstorm → /prototype → /art-bible → /gate-check
• 系统设计：/map-systems → /design-system（每个系统执行一次）→ /review-all-gdds → /gate-check
• 架构：/create-architecture → /architecture-decision（每项决策执行一次）→ /create-control-manifest → /architecture-review → /test-setup → /ux-design （无障碍和交互模式）→ /gate-check
• 预制作：/ux-design（HUD 和关键屏幕）→ /create-epics → /create-stories → /sprint-plan → /gate-check
• 制作：/dev-story

每次 /gate-check 通过后，项目都会进入下一阶段。

**full：**包含 standard 的所有内容，此外还会在预制作阶段加入 /vertical-slice 和 /playtest-report，并在每份 GDD 之后加入 /design-review。

已有工作的路径 D（阶段为 Systems Design 或更后阶段，或磁盘上已有代码）则使用以下路径。 只列出适用的步骤；简报只列出适用的一个来源。在 minimal 下：

1. /project-stage-detect：检查项目所处阶段及缺失内容
2. /adopt：检查现有文件是否符合技能读取的格式
3. /setup-engine：仅当尚未设置引擎时执行；如果 engine 指定了引擎，则省略
4. 仅当缺少 concept 时提供简报：如果代码根目录中有 10 个或更多源文件，则运行 /reverse-document design [code_root]（从游戏生成简报），之后完全不提及 /brainstorm；只有当源文件少于 10 个时才运行 /brainstorm

在 standard 和 full 下，先执行步骤 1 至 3，再执行 /design-system retrofit [path]、 /architecture-decision retrofit [path]、/architecture-review 和 /gate-check。

将 minimal 作为文档所述的基础配置，而非较低级的模式，并只提及一次它的取舍：没有 GDD，因此设计问题会在代码中暴露出来。

如果 origin_url 指向模板仓库，则补充：“你的克隆仓库的 origin 仍指向 CCGS 模板仓库，因此推送或拉取请求都会发往那里。准备好后，运行 git remote rename origin template，然后运行 git remote add origin <your repo URL>。UPGRADING.md 会从 template 拉取更新；跳过其中添加 template 远程仓库的 git remote add template 步骤，因为该远程仓库现在已经存在。”只建议，不要代为执行。

询问：“你想从 [first step] 开始吗？”选项：Yes, start with [first step] / Something else first。无论选择哪个，都会进入阶段 7，绝不运行该步骤。

阶段 7：交接

只回复一行：“输入 [skill] 即可开始。”不要启动该技能，也不要调用其技能工具，即使用户回答“是”也不例外：由用户输入技能名称。如果用户选择先做其他事情，则以相同方式为其指定相应技能。

结论：COMPLETE，用户已了解情况并完成交接。如果用户在阶段 7 之前停止，则说明保存了哪些设置，哪些没有保存。