引导式入门

此技能是新用户的入口。它不会假设你已经有了游戏创意、引擎偏好或任何经验。它先询问，然后将你路由到正确的工作流。

---

工作流

1. 检测项目状态（静默）

在询问任何问题之前，静默收集上下文信息，以便量身定制你的引导建议。不要主动展示这些结果 — 它们用于指导推荐，而非作为对话开场白。

检查：

• 引擎已配置？ 读取 .claude/docs/technical-preferences.md。如果 Engine 字段包含 [TO BE CONFIGURED]，说明引擎未设置。
• 游戏概念是否存在？ 检查 design/gdd/game-concept.md。
• 源代码是否存在？ 使用 Glob 搜索 src/ 中的源文件（*.gd、*.cs、*.cpp、*.h、*.rs、*.py、*.js、*.ts）。
• 原型是否存在？ 检查 prototypes/ 中的子目录。
• 设计文档是否存在？ 统计 design/gdd/ 中的 Markdown 文件数量。
• 生产工件（Production Artifacts）？ 检查 production/sprints/ 或 production/milestones/ 中是否有文件。

在内部保存这些发现。你将用它们来验证用户的自评结果并定制后续推荐。

---

2. 询问用户当前阶段

这是用户首先看到的内容。清晰地展示以下 4 个选项：

欢迎使用 Claude Code Game Studios！

在提出建议之前，我想了解你目前的起点。你的游戏创意现在处于哪个阶段？

A）还没有想法 — 我完全没有任何游戏概念。我想探索并弄清楚要做什么。

B）模糊的想法 — 我有一个粗略的主题、感觉或类型方向（例如"跟太空有关的东西"或"一款温馨的农场游戏"），但还没有具体内容。

C）清晰的概念 — 我知道核心想法 — 类型、基本机制，可能还有一句话的推介 — 但还没有正式形成文档。

D）已有成果 — 我已经有了设计文档、原型、代码或重要的规划工作。我想整理或继续这些工作。

等待用户回答。在用户回复之前不要继续。

---

3. 根据回答进行路由

如果选 A：还没有想法

用户在进入其他任何环节之前需要创意探索。引擎选择、技术配置 — 这些都以后再说。

1. 确认从零开始完全没问题
2. 简要说明 /brainstorm 的作用（使用专业框架的引导式创意发想 — MDA 框架、玩家心理学、动词优先设计）
3. 建议下一步运行 /brainstorm open
4. 展示推荐路径：
   • /brainstorm — 发现你的游戏概念
   • /setup-engine — 配置引擎（brainstorm 会推荐一个）
   • /map-systems — 将概念拆解为系统并规划 GDD（游戏设计文档）编写顺序
   • /prototype — 测试核心机制
   • /sprint-plan — 规划第一个冲刺（Sprint）

如果选 B：模糊的想法

用户有一个种子想法，但需要帮助将其发展成完整概念。

1. 请他们分享模糊的想法 — 哪怕几个字就够了
2. 确认这是一个好的起点（不要评判或改变方向）
3. 建议运行 /brainstorm [他们的线索] 来发展它
4. 展示推荐路径：
   • /brainstorm [线索] — 将想法发展为完整概念
   • /setup-engine — 配置引擎
   • /map-systems — 将概念拆解为系统并规划 GDD 编写顺序
   • /prototype — 测试核心机制
   • /sprint-plan — 规划第一个冲刺

如果选 C：清晰的概念

用户知道自己要做什么，但还没有形成文档。

1. 提出 2-3 个后续问题来了解他们的概念：
   • 类型和核心机制是什么？（一句话）
   • 有引擎偏好吗，还是需要帮助选择？
   • 大致规模如何？（Game Jam 游戏、小型项目、大型项目）
2. 根据他们的回答，提供两条路径：
   • 先正式化：运行 /brainstorm，将概念结构化为正式的游戏概念文档，包含游戏支柱（Pillars）、MDA 分析和规模层级
   • 直接配置引擎：如果用户对概念很有信心，直接进入 /setup-engine，之后手动编写 GDD
3. 展示推荐路径（根据他们的选择调整）：
   • /brainstorm 或 /setup-engine（由用户选择）
   • /design-review — 验证概念文档
   • /map-systems — 将概念拆解为独立系统，标记依赖关系和优先级
   • /design-system — 编写各系统的 GDD（引导式，逐节完成）
   • /architecture-decision — 做出第一批技术决策
   • /sprint-plan — 规划第一个冲刺

如果选 D：已有成果

用户已经有工件了。弄清楚什么存在、什么缺失。

1. 分享你在步骤 1 中的发现（现在它相关了）：
   • "我看到你有 [X 个源文件 / Y 份设计文档 / Z 个原型]..."
   • "你的引擎 [已配置为 X / 尚未配置]..."
2. 建议运行 /project-stage-detect 进行全面分析
3. 如果引擎未配置，指出应先运行 /setup-engine
4. 展示推荐路径：
   • /project-stage-detect — 全面的缺口分析
   • /setup-engine — 如果尚未配置
   • /design-system — 如果系统索引存在但 GDD 不完整
   • /gate-check — 验证是否准备好进入下一阶段
   • /sprint-plan — 整理工作

---

4. 继续前确认

在展示推荐路径后，询问用户想先执行哪一步。永远不要自动运行下一个技能。

"你想从 [推荐的第一步] 开始，还是想先做其他事情？"

---

5. 交接

当用户选择下一步时，让他们自己调用技能，或者主动提出帮他们运行。无论哪种方式，一旦用户有了明确的下一步行动，/start 技能的任务就完成了。

---

边界情况

• 用户选了 D 但项目为空：温和地引导 — "看起来项目是一个全新模板，还没有任何工件。路径 A 或 B 可能更合适？"
• 用户选了 A 但项目中有代码：提及你的发现 — "我注意到 src/ 中已有代码。你是想选 D（已有成果）吗？还是想用新概念重新开始？"
• 用户是回访者（引擎已配置、概念已存在）：完全跳过入门 — "看起来你已经配置好了！引擎是 [X]，游戏概念在 design/gdd/game-concept.md。想从上次停下的地方继续吗？试试 /sprint-plan，或者直接告诉我你想做什么。"
• 用户不属于任何选项：让他们用自己的话描述情况，然后灵活适配。4 个选项是起点，不是牢笼。

---

协作协议

此技能遵循协作设计原则：

1. 先询问 — 永远不要假设用户的状态或意图
2. 展示选项 — 给出清晰的路径，而非命令
3. 用户决定 — 由他们选择方向
4. 不自动执行 — 推荐下一个技能，但不要未经询问就运行
5. 灵活适配 — 如果用户的情况不符合模板，倾听并调整