在游戏预制作阶段需要把模糊创意变成可执行概念时…

当你要与用户协作探索游戏创意、筛选方向并形成可继续开发的概念或简报时适用。

适用场景

解决思路

1. 先用 yaml-helper.sh 的 resolve_config 读取 review_mode、automation、docs.density、workflow，并直接使用解析结果；无配置块时按 `.claude/docs/config-resolution.md` 的默认值。
2. 若有 `--review`，覆盖 `review_mode`，并在本轮所有 gate spawn 中保存使用；完整检查模式见 `.claude/docs/director-gates.md`；各 gate 定义在 `.claude/docs/director-gates/[gate-id].md`，由被 spawn 的 agent 自己读取，父会话不要读。
3. 每次 `AskUserQuestion` 都遵循 `.claude/docs/automation-modes.md`：`collaborative` 总是询问，`guided` 只问重大决策，`autonomous` 记录并继续；`automation_always_ask` 类别始终提示。
4. 用 `docs.density` 控制每节深度：`terse` 只写支柱要点和概念要点；`balanced` 写支柱、概念和简短理由（默认）；`thorough` 写支柱、概念、大量理由和备选方案；对每个撰写的 section 应用该密度。
5. 先检查 `workflow` tier：`standard`/`full` 跑完整流程到 Phase 5 和概念文档生成；`minimal` 立即执行 Lean Brief flow 并停止，跳过 Phases 1–5、CD-PILLARS/AD-CONCEPT-VISUAL/TD-FEASIBILITY/PR-SCOPE 导演 gate 和完整概念文档，输出一页 `design/game-brief.md`，而不是 `game-concept.md`。
6. `minimal` 时，从 argument hint（或没有时一个快速开放问题）提出 2–3 个一行概念，使用动词优先或 mashup，按 Phase 2 技巧；用一个 `AskUserQuestion` 选择或组合，这是唯一保证的创意提示。
7. `minimal` 时，以对话方式填写 brief 字段，不要每字段一问：一句话 pitch（兴奋的一句话）、核心循环（玩家重复的 2–4 步循环）、MVP（让它成为该游戏的最短功能列表，每个功能后续变成 story；超过约 7 个就压 scope）、out of scope（刻意不构建的内容）、build order（构建 MVP 的顺序，风险最高或核心乐趣优先）、目标玩家与感受和美术与音频方向（各一行，提供但不强迫）。
8. `minimal` 时，完整回显填好的 brief 供一次确认。
9. `minimal` 写批准：用 `AskUserQuestion` 询问“Brief 已准备好。可以写入 `design/game-brief.md` 吗？”，选项为 `[A] Yes — write it` / `[B] Revise a field first`；选 B 时修改指定字段，显示 before/after，重新询问直到 A；然后按模板写入 `design/game-brief.md`，按需创建目录；写入时同样遵守 `modes.automation`。
10. `minimal` 下一步：先从 `project.yaml` 读取 `engine.name`，仅当它缺失或为空时列出 `/setup-engine`；然后列出 `/create-stories` 把 brief 的 MVP 列表变成可实现 stories（minimal 下 epic 隐式存在，没有单独 `/create-epics` 或 `/sprint-plan`，brief 的 build order 就是计划）；再列出 `/dev-story` 写第一行游戏代码。最后输出一行摘要，包含 pitch、MVP 功能数和 `design/game-brief.md`。此 tier 输出 COMPLETE，不要跑 Phases 1–5、spawn 导演 gate 或写 `game-concept.md`。
11. `standard`/`full` 时解析 argument 中可选 genre/theme hint，如 `roguelike`、`space survival`、`cozy farming`；若为 `open` 或无参数则从零开始。
12. `standard`/`full` 时检查已有概念工作：若存在 `design/gdd/game-concept.md` 则读取并续作而非重启；若存在 `design/gdd/game-pillars.md` 则读取并在已有支柱上构建。
13. `standard`/`full` 时交互式跑构思阶段，每个阶段向用户提问；不要静默生成一切，目标是 AI 作为创意引导者协作探索，而非替代人的愿景。
14. 在关键决策点使用 `AskUserQuestion`：约束品味问题（类型偏好、范围、团队规模）；展示选项后问概念选择，如“哪 2–3 个概念有共鸣？”；方向选择，如“继续开发、继续探索还是做原型？”；概念细化后做支柱排序。先在对话文本写完整创意分析，再用 `AskUserQuestion` 用简洁标签捕获决策。
15. 遵循专业工作室头脑风暴原则：探索时不评判，没有坏点子；鼓励不寻常想法；用“yes, and...”互相构建而非“but...”；把约束当创意燃料；每个阶段限时，保持势头，早期不要过度斟酌。
16. Phase 1 先理解人而不是游戏，用对话而非清单问情感锚点：哪个游戏时刻真正打动你、让你兴奋或忘记时间？具体是什么创造了这种感觉？有没有一直想在游戏里找到但没找到的幻想或权力幻想？
17. Phase 1 品味画像：问最常玩的 3 个游戏以及为什么反复回来，必须纯文本询问，让用户自由输入具体游戏名，不要放进带预设选项的 `AskUserQuestion`；问喜欢或回避的类型及原因；问更喜欢挑战、放松、讲故事还是表达自我，这里用 `AskUserQuestion` 做受限选择。
18. Phase 1 实际约束：把问题捆绑成一个多标签 `AskUserQuestion`，使用精确标签 Tab “Experience”（最希望玩家获得什么体验：挑战与精通 / 故事与发现 / 表达与创造 / 放松与心流）、Tab “Timeline”（现实开发时间线：Weeks / Months / 1-2 years / Multi-year）、Tab “Dev level”（开发旅程位置：First game / Shipped before / Professional background）；不要重命名或复制标签。
19. Phase 1 综合答案成 Creative Brief：3–5 句总结情感目标、品味画像和约束；读回并确认是否捕捉意图。
20. Phase 2 基于 Creative Brief 生成 3 个不同创意方向的概念；使用技巧 1 Verb-First Design：从核心玩家动词（build、fight、explore、solve、survive、create、manage、discover）出发向外构建，动词就是游戏。
21. 使用技巧 2 Mashup Method：组合两个意外元素 `[Genre A] + [Theme B]`，两者张力创造独特 hook，如 farming sim + cosmic horror、roguelike + dating sim、city builder + real-time combat。
22. 使用技巧 3 Experience-First Design（MDA Backward）：从期望玩家情绪出发，MDA 审美目标包括 sensation、fantasy、narrative、challenge、fellowship、discovery、expression、submission，反向推导产生它的 dynamics 和 mechanics。
23. 每个概念展示：Working Title、Elevator Pitch（1–2 句，必须通过 10 秒测试）、Core Verb、Core Fantasy、Unique Hook（通过 and also 测试：Like X, AND ALSO Y）、Primary MDA Aesthetic、Estimated Scope（small/medium/large）、Why It Could Work（一句市场或受众契合）、Biggest Risk（一句最难回答的问题）。
24. 展示全部三个概念后，用 `AskUserQuestion` 捕获选择；此决策无论 `modes.automation` 如何都必须询问，因为概念选择是 `/brainstorm` 的创意核心，没有可辩护的自动默认；按 `.claude/docs/automation-modes.md` 视为豁免，像 `automation_always_ask` 一样覆盖模式。
25. 概念选择必须是纯列表调用，无 tabs、无 form fields；调用 `AskUserQuestion`，prompt 为“哪个概念与你有共鸣？你可以选一个、组合元素或要求全新方向。”，options 为概念 1 — [Title]、概念 2 — [Title]、概念 3 — [Title]、组合多个概念的元素、生成全新方向；不要使用 `tabs` 字段，否则触发 Invalid tool parameters；不要施压选择，让用户自行沉淀。
26. Phase 3 对所选概念用结构化提问构建核心循环；核心循环是游戏心脏，如果单独玩不好，任何内容和打磨都救不了。
27. 30 秒循环：用 `AskUserQuestion` 提问，选项从所选概念推导，不要硬编码；问题 1 核心动作感觉，prompt 为“核心动作的主要感觉是什么？”，生成 3–4 个符合类型和基调的选项，并提供自由文本出口 `I'll describe it`；问题 2 关键设计维度，识别该概念最重要的设计变量，如世界反应性、节奏、玩家能动性，并提问，生成匹配选项，始终包含自由文本出口。
28. 30 秒循环答案后分析：该动作本身是否令人满足？什么让它感觉好？考虑音频反馈、视觉 juice、时机满足感、战术深度。
29. 5 分钟循环：什么结构把逐刻玩法组织成循环？哪里出现 one more turn 或 one more run 心理？玩家在此层级做什么选择？
30. Session 循环 30–120 分钟：完整 session 是什么样？自然停止点在哪？什么 hook 让玩家不玩时也想着游戏？
31. Progression 循环 天/周：玩家如何成长，力量、知识、选项还是故事？长期目标是什么？游戏何时完成？
32. 玩家动机分析，基于 Self-Determination Theory：Autonomy 玩家有多少有意义选择；Competence 玩家如何感到技能成长；Relatedness 玩家如何感到连接，包括角色、其他玩家或世界。
33. Phase 4 协作定义 3–5 个支柱：每个有名称和一句话定义；每个有设计测试：“如果我们在 X 和 Y 之间争论，这个支柱说选 __”；支柱之间应感觉有张力，若都指向同一方向则做得不够。
34. 定义 3+ 反支柱，即游戏不是什么：防止最常见 scope creep，即 wouldn't it be cool if... 不服务核心愿景的功能；表述为 We will NOT do [thing] because it would compromise [pillar]。
35. 支柱确认：展示完整支柱集后 `AskUserQuestion`，prompt 为“这些支柱适合你的游戏吗？”，选项 `[A] Lock these in` / `[B] Rename or reframe one` / `[C] Swap a pillar out` / `[D] Something else`；若 B/C/D 则修改，再问“支柱已更新。准备锁定吗？”，选项 `[A] Lock these in` / `[B] Revise another pillar` / `[C] Something else`。
36. 模式处理：`collaborative` 重复直到用户选 `[A] Lock these in`；`guided` 支柱是重大决策，只问一次，应用所选修订并锁定，不做第二轮确认；`autonomous` 不问，锁定草拟支柱并用 `log_decision` 记录考虑过的备选。
37. 在 spawn CD-PILLARS 和 AD-CONCEPT-VISUAL 前做 review mode 检查：`solo` 跳过两者并注明 CD-PILLARS skipped — Solo mode. AD-CONCEPT-VISUAL skipped — Solo mode. 然后前往 Phase 5；`lean` 跳过两者，因为它们不是 PHASE-GATEs，并注明；`full` 正常 spawn。
38. 支柱和反支柱达成后，在进入 Phase 5 前并行 spawn `creative-director` 和 `art-director`，通过 `Agent`；同时发出两个 `Agent` 调用，不要等一个完成再发另一个。
39. `creative-director` 负责 gate CD-PILLARS（`.claude/docs/director-gates/cd-pillars.md`），传入完整支柱集含设计测试、反支柱、核心幻想、独特 hook。
40. `art-director` 负责 gate AD-CONCEPT-VISUAL（`.claude/docs/director-gates/ad-concept-visual.md`），传入概念 elevator pitch、完整支柱集含设计测试、目标平台（若已知）、用户提到的参考游戏或视觉参照。
41. 收集两个 verdict 后，用双标签 `AskUserQuestion` 一起展示：Tab “Pillars” 展示 creative-director 反馈，选项为 `Lock in as-is` / `Revise [specific pillar]` / `Discuss further`；Tab “Visual anchor” 展示 art-director 的 2–3 个命名视觉方向选项，选项为每个命名方向 + `Combine elements across directions` + `Describe my own direction`。
42. 用户选择的视觉锚点，命名方向或自定义描述，存为 Visual Identity Anchor，写入 game-concept 文档，并成为 art bible 基础。
43. 如果 creative-director 对支柱返回 CONCERNS 或 REJECT，先解决支柱问题再询问视觉锚点选择；视觉方向应从已确认支柱流出。
44. Phase 5 用 Bartle taxonomy 和 Quantic Foundry motivation model 验证游戏到底给谁：Primary player type 谁会爱这个游戏，包括 Achievers、Explorers、Socializers、Competitors、Creators、Storytellers；Secondary appeal 谁可能也喜欢；Who is NOT for 谁不会喜欢，明确这一点同样重要；Market validation 是否有成功游戏服务类似玩家类型，从受众规模学到什么。
45. Phase 6 落地概念：用 `AskUserQuestion` 问目标平台“这个游戏的目标平台是什么？”，选项 `PC (Steam / Epic)` / `Mobile (iOS / Android)` / `Console` / `Web / Browser` / `Multiple platforms`；记录答案，它直接影响引擎建议并传给 `/setup-engine`；注意平台含义，如移动端强烈偏好 Unity、主机端 Godot 有限制、Web 端 Godot 导出干净。
46. 用 `AskUserQuestion` 问引擎经验“你已有使用的引擎吗？”，选项 `Godot` / `Unity` / `Unreal Engine 5` / `No preference — help me decide`；此决策不管 `modes.automation`，包括 `autonomous`，都必须提示，因为引擎选择是全项目架构承诺，下游工具依赖且项目中期基本不可逆，所以无条件保护，不交给可配置的 `automation_always_ask`，模型绝不能静默选引擎。若选择引擎则记录偏好继续，不要事后质疑；若选 No preference 则告诉用户：“Run `/setup-engine` after this session — it will walk you through the full decision based on your concept and platform target.” 不要在此给推荐。
47. 评估美术管线：美术风格是什么，劳动强度多大。
48. 估算内容范围：关卡或区域数量、物品数量、游玩小时数。
49. 定义 MVP：测试核心循环是否好玩的最小构建是什么。
50. 列出最大风险：技术风险、设计风险、市场风险。
51. 定义 scope tiers：完整愿景 vs 时间不够时能发布的内容。
52. spawn TD-FEASIBILITY 前做 review mode 检查：`solo` 跳过并注明，直接去 scope tier 定义；`lean` 跳过，因为它不是 PHASE-GATE，并注明；`full` 正常 spawn。
53. 识别最大技术风险后，在定义 scope tiers 前通过 `Agent` spawn `technical-director` 使用 gate TD-FEASIBILITY（`.claude/docs/director-gates/td-feasibility.md`），传入核心循环描述、平台目标、引擎选择或 undecided、已识别技术风险列表。展示评估；若 HIGH RISK 提议在定稿前重审 scope；若 CONCERNS 记录并继续。
54. spawn PR-SCOPE 前做 review mode 检查：`solo` 跳过并注明，直接去文档生成；`lean` 跳过，因为它不是 PHASE-GATE，并注明；`full` 正常 spawn。
55. 定义 scope tiers 后，通过 `Agent` spawn `producer` 使用 gate PR-SCOPE（`.claude/docs/director-gates/pr-scope.md`），传入完整愿景 scope、MVP 定义、时间线估算、团队规模。展示评估；若 UNREALISTIC 提议在写文档前调整 MVP 定义或 scope tiers。
56. 使用模板 `.claude/docs/templates/game-concept.md` 生成游戏概念文档，从头脑风暴对话填入所有 section，包括 MDA 分析、玩家动机画像、flow state 设计 section。
57. 在游戏概念文档中包含 Visual Identity Anchor section：选定的视觉方向名称、一句话视觉规则、2–3 条支持性视觉原则及其设计测试、色彩哲学摘要；此 section 是 art bible 的种子，在跨 session 忘记前捕获一切必须移动这类决定。
58. 用 `AskUserQuestion` 请求写入批准：prompt 为“游戏概念已准备好。可以写入 `design/gdd/game-concept.md` 吗？”，选项 `[A] Yes — write it` / `[B] Not yet — revise a section first`；若选 B，用 `AskUserQuestion` 询问修改哪个 section，选项 `Elevator Pitch` / `Core Fantasy & Unique Hook` / `Pillars` / `Core Loop` / `MVP Definition` / `Scope Tiers` / `Risks` / `Something else — I'll describe`；修改后以 diff 或清晰 before/after 展示更新 section，再问“准备写入更新后的概念文档吗？”，选项 `[A] Yes — write it` / `[B] Revise another section`。
59. 写入批准模式处理：`collaborative` 重复直到 `[A]`；`guided` 只问一次，应用请求的修改并写文档，不再确认；`autonomous` 不问，写文档并用 `log_decision` 记录决策。
60. 若同意，则用 `.claude/docs/templates/game-concept.md` 生成文档，填入对话所有 section，写入文件并按需创建目录。
61. Scope 一致性规则：Core Identity 表中的 Estimated Scope 字段必须与 Scope Tiers section 的完整愿景时间线匹配，不能只写 Large (9+ months)；写成 Large (X–Y months, solo) 或 Large (X–Y months, team of N)，使摘要表准确。
62. 按专业工作室预制作流水线顺序建议下一步，列出所有步骤不要缩写：Path A Design-First，概念定义清晰时推荐，1 运行 `/setup-engine` 配置引擎并填充版本感知参考文档；2 运行 `/art-bible` 创建视觉身份规范，必须在写 GDD 之前；art bible 是 Technical Setup gate 前置，门控资产生产并塑造技术架构决策，包括渲染、VFX、UI 系统；3 用 `/design-review design/gdd/game-concept.md` 在下游前验证概念完整性；4 与 `creative-director` agent 讨论愿景以细化支柱；5 用 `/map-systems` 把概念分解为系统，映射依赖、分配优先级、创建 systems index；6 用 `/design-system` 按第 5 步识别的每个系统写逐系统 GDD，逐节引导；7 用 `/create-architecture` 规划技术架构，产出主架构蓝图和 Required ADR list；8 用 `/architecture-decision (×N)` 记录关键架构决策，为 Required ADR list 中每个决策写一个 ADR；9 运行 `/architecture-review`，从 GDD 和 ADR 引导 TR registry 和 Requirements Traceability Matrix，Pre-Production gate 前必需；10 用 `/gate-check` 验证推进准备，作为承诺进入生产前的 phase gate。
63. Path B Prototype-First，核心机制未证明或概念需验证时使用：1 运行 `/setup-engine` 配置引擎；2 运行 `/prototype [core-mechanic]` 在写任何 GDD 前验证核心点子好玩，1–3 天一次性代码；3 若原型 PROCEEDS：运行 `/art-bible`，然后继续 Path A 第 5–10 步，用原型学习指导 GDD；4 若原型 PIVOTS：带着学习回到 `/brainstorm` 重塑概念；5 完整设计和架构后，构建 `/vertical-slice` 在承诺 sprint 前验证生产准备度。
64. 输出摘要，包含所选概念 elevator pitch、支柱、主要玩家类型、引擎建议、最大风险、文件路径。Verdict COMPLETE — game concept created and handed off for next steps。
65. Context Window Awareness：多阶段技能。如果任何阶段 context 达到或超过 70%，在继续前向当前响应追加通知：“Context is approaching the limit (≥70%). The game concept document is saved to `design/gdd/game-concept.md`. Open a fresh Claude Code session to continue if needed — progress is not lost.”
66. 游戏概念写完后推荐下一步按顺序：1 `/setup-engine` 配置引擎并填充版本感知参考文档；2 `/art-bible` 在写任何 GDD 前建立视觉身份；3 `/map-systems` 把概念分解为带依赖的系统；4 `/design-system [first-system]` 按依赖顺序写逐系统 GDD；5 `/create-architecture` 产出主架构蓝图；6 `/architecture-review` 引导 TR registry 和 Requirements Traceability Matrix；7 `/gate-check pre-production` 在承诺生产前验证准备度。

适用边界 · 注意事项

• 项目未安装或未配置 Claude Code 的 `.claude` hooks、agents、templates、director gates 和 docs 时，不适用，因为流程依赖这些文件与 spawn 门禁。
• `workflow: minimal` 时不要使用完整 standard/full 流程；只用 Lean Brief，不跑 Phases 1–5、导演 gate 或写 `game-concept.md`。
• 概念选择和引擎选择等关键决策不适用 autonomous 静默执行；概念选择豁免 automation 必须询问，引擎选择无条件提示。