游戏概念获批后需要先建立统一视觉语言并门控资产生产时，编写…

在游戏概念文档 game-concept.md 获批后、编写系统 GDD 前，用可复用流程产出 9 节 Art Bible，作为约束视觉资产生产的单一事实来源。

适用场景

解决思路

1. 解析参数：--review 覆盖 review_mode；读取配置 resolve_config（keys: review_mode, automation, workflow, docs.density）；无配置块时使用 .claude/docs/config-resolution.md 中的默认值。
2. 对每次 AskUserQuestion 遵循 .claude/docs/automation-modes.md（collaborative 总会问；guided 仅大事问；autonomous 记录并继续；automation_always_ask 类别始终提示）。
3. 用 docs.density 控制每节深度（terse=约束+引用的要点列表；balanced=解释每个视觉选择的段落，默认；thorough=完整散文含风格探索、参考与理由），并应用到编写的每一节。
4. 按 workflow 决定要求的节：full 要求全部 9 节；standard 仅当项目存在视觉资产故事时才要求，至少 1–4 节；workflow_overrides.art_bible_strict: true 时无论层级强制 9 节；minimal 不要求但可自愿运行。
5. 读取 design/gdd/game-concept.md；若不存在则失败并提示「No game concept found. Run /brainstorm first — the art bible is authored after the game concept is approved.」。
6. 从 game-concept.md 提取：游戏标题（工作标题）、核心幻想与电梯演讲、所有游戏支柱、若存在的 Visual Identity Anchor、目标平台。
7. 改造模式检测：Glob design/art/art-bible.md；若存在，不读取文档就构建状态表。
8. 用 Grep 找 ^## 标题行号，以及 \[To be designed\]|\[TBD\]|\[To be written\]|^_?TODO 占位符标记。
9. 判断每节状态：有实质内容且无占位符为 Complete；范围内有占位符为 Placeholder；相邻标题紧贴为 Empty。
10. 对真正模糊的节，用 Read(offset, limit) 只读该节行范围，绝不用 Read 读整个文件。
11. 构建 9 节状态表并展示给用户，说明只处理 Empty/Placeholder 的节，不动已有内容。
12. 若 design/art/art-bible.md 不存在，则为全新编写会话，正常继续。
13. 从 project.yaml 读取 performance.* 和 engine.name，用于资产标准约束；缺失或为空（含无 performance/engine 块）时回退到 .claude/docs/technical-preferences.md。
14. 展示会话上下文，在编写前用 AskUserQuestion 两个 tab 提问。
15. Tab “Scope”：问今天需要编写哪些节，选项：Full bible — all 9 sections / Visual identity core (sections 1–4 only) / Asset standards only (section 8) / Resume — fill in missing sections。
16. 根据解析出的 workflow 层级标记推荐项并说明原因（full→Full bible；standard→1–4；minimal→不要求，提供 1–4；art_bible_strict:true→Full bible），这是本技能最大的成本杠杆。
17. Tab “References”：问是否有定义视觉方向的参考游戏、电影或艺术（自由文本，不预设选项）。
18. 若 game-concept.md 有 Visual Identity Anchor，提示将以其为基础。
19. 编写 Sections 1–4：这四节定义核心视觉语言，所有其他节都从其衍生；每节写入文件后再进入下一节。
20. 委派策略：Section 1 单独委派；Sections 2–4 合并为一次 art-director 调用（同一 agent、同一输入且 mood/shape/colour 相互依赖），但仍每节分别审批并立即写入文件。
21. Section 1：目标是一行视觉规则 + 2–3 条支撑原则，用于解决视觉歧义。
22. 若存在视觉锚点，询问：直接基于此锚点扩展 / 扩展前先修改 / 用新选项重新开始。
23. 强制委派 art-director（用 Agent）：提供游戏概念（电梯演讲、核心幻想）、完整支柱集、目标平台、Phase 1 的参考、存在的视觉锚点；要求起草 Visual Identity Statement，含 (1) 一行可解决任何视觉决策歧义的视觉规则，(2) 2–3 条支撑视觉原则，每条带一句设计测试，且每条原则必须服务具体支柱。
24. 将 art-director 草稿呈现给用户，用 AskUserQuestion 选项 A 锁定/B 修改一行/C 修改支撑原则/D 自述方向；批准后立即写入文件。
25. Section 2：目标是各游戏状态的情感目标，具体到光照美术可据此工作。
26. 对每个主要游戏状态定义：主要情绪/氛围目标、光照特征（时间、色温、对比度）、氛围描述词（3–5 个形容词）、能量级别（狂乱/从容/沉思等）。
27. 在此发起 Sections 2–4 的委派：spawn art-director 一次，给锁定的 Visual Identity Statement 和支柱集，一份简报要求三节——(1) mood & atmosphere：为每个主要游戏状态定义氛围目标，命名确切情绪目标、光照特征、至少一个承载氛围的视觉元素；(2) shape language：定义形状语言，每条原则关联视觉身份声明和具体支柱，解释形状选择传达的情感；(3) colour system：设计色彩系统，每个语义色分配都要解释为何此色在此世界表示危险/安全/奖励，识别可能对色盲玩家失败的颜色对并指定备用线索。要求三者相互一致（色板服务氛围目标、形状层级），返回三个独立标记块。
28. 先呈现 Section 2，批准后立即写入文件，再进入 Section 3；不要一次呈现三节（批量只在委派，不在评审）。
29. Section 3 覆盖：角色剪影哲学（缩略图可读性？每原型区分特征？）、环境几何（角度/曲线/有机/几何，哪个主导及原因）、UI 形状语法（UI 呼应世界美学还是独立 HUD 语言）、主角形状 vs 辅助形状（什么吸引视线、什么后退）。
30. Section 3 使用 Sections 2–4 委派返回的 shape-language 块，不再 spawn；批准后立即写入文件。
31. Section 4 覆盖：主色板（5–7 色带角色，说明每色在此世界的含义而非仅 hex）、语义色使用（红/金/蓝/白各传达什么）、每生物群系或区域的色温规则、UI 色板（可不同，明确分歧）、色盲安全（哪些语义色需要形状/图标/声音备份）。
32. Section 4 使用 Sections 2–4 委派返回的 colour-system 块，不再 spawn；批准后立即写入文件。
33. 编写 Sections 5–8：将视觉身份翻译成具体生产规则，具体到外包团队无需额外简报即可执行。
34. 在此发起 Sections 5–6 的委派：spawn art-director 一次，给 sections 1–4，要求两个独立标记块——(1) character design direction：玩家角色视觉原型、每类角色区分特征规则、表情/姿势风格目标、LOD 哲学；(2) environment design language：建筑风格及其与世界文化历史的关系、纹理哲学（painted vs PBR vs stylized 及理由）、道具密度规则、环境叙事指南。要求角色与环境相互可辨识（角色剪影需在环境纹理密度下可读）。
35. 先呈现 Section 5，批准后写入文件，再 Section 6。
36. Section 6 使用 Sections 5–6 委派返回的 environment 块，不再 spawn；批准后写入文件。
37. Section 7：并行 spawn art-director（UI 视觉风格：diegetic vs screen-space HUD、排版方向、图标风格、UI 动画感觉）和 ux-designer（UX 对齐检查：视觉方向是否支持所需交互模式，标记与可读性/可访问性的冲突）。
38. 收集两者；若冲突（如 art-director 要复杂 diegetic UI 但 ux-designer 标记会降低战斗可读性），明确呈现双方立场，不静默解决，用 AskUserQuestion 让用户决定；批准后写入文件。
39. Section 8：并行 spawn art-director（文件格式偏好、命名规范方向、纹理分辨率层级、LOD 层级期望、导出设置哲学）和 technical-artist（引擎特定硬约束：各类资产面数预算、纹理内存限制、材质槽数、导入器约束，以及来自 project.yaml 的 performance.*，回退 .claude/docs/technical-preferences.md）。
40. 若艺术偏好与技术约束冲突（如 art-director 要 4K 纹理但移动端性能预算要求 2K），明确解决，记录理想与受约束标准并解释权衡（资产标准中的模糊正是生产成本来源）；批准后写入文件。
41. Section 9：目标是精选参考集，明确从每个来源取什么、避免什么。
42. spawn art-director 带已完成 sections 1–8，要求 3–5 个参考源（游戏、电影、艺术风格或具体艺术家）；每个说明名称、明确吸取的具体视觉元素（不是「整体美学」，而是具体技术、色彩选择或构图规则）、明确避免或背离什么（防止「模仿 X」读感）；参考应互补，不应指向同一方向；批准后写入文件。
43. Review mode 检查：solo 跳过并记录「AD-ART-BIBLE skipped — Solo mode.」进入 Phase 6；lean 跳过（非 PHASE-GATE）并记录进入 Phase 6；full 正常 spawn。
44. 所有节完成（或 Phase 1 范围内节完成）后，spawn creative-director 用 gate AD-ART-BIBLE（.claude/docs/director-gates/ad-art-bible.md），传递 art bible 文件路径、游戏支柱、视觉身份锚点。
45. 按 .claude/docs/director-gates.md 标准规则处理裁决，并在 art bible 状态头记录：> **Art Director Sign-Off (AD-ART-BIBLE)**: APPROVED [date] / CONCERNS (accepted) [date] / REVISED [date]。
46. 展示下一步前检查项目状态：design/gdd/systems-index.md 是否存在（是则跳过 /map-systems）；engine.name 是否在 project.yaml 或技术偏好中配置（是则跳过 /setup-engine）；design/gdd/ 是否有 *.md（有则跳过 /design-system）；gdd-cross-review-*.md 是否存在（是则跳过 /review-all-gdds）；GDD 是否存在（是则包含 /consistency-check）。
47. 用 AskUserQuestion 提供下一步，仅包含状态检查后确实的选项；分配字母 A、B、C… 只给实际包含的选项；把最合逻辑的推进选项标为 (recommended)；始终包含 /create-architecture 和 Stop here。
48. 选项池包括：/map-systems、/setup-engine、/design-system、/review-all-gdds、/asset-spec（若有 GDD）、/consistency-check（若有 GDD）、/create-architecture、Stop here。
49. 每节遵循：Question → Options → Decision → Draft（来自 art-director agent）→ Approval → Write to file。
50. 永远不要自己起草某节内容——每节内容来自相关 specialist；一次委派可覆盖多节（2–4、5–6），但不得由 orchestrator 自己的判断代替 agent 写入任何节。
51. 每节批准后立即写入文件——不要批量写入或批量批准；批量仅适用于委派调用；用户仍一次只看、批准和提交一节。
52. 向用户呈现所有 agent 分歧——绝不静默解决 art-director 与 technical-artist/ux-designer 之间的冲突。
53. 把 art bible 当作约束文档：它限制未来决策以换取视觉一致性；每节都应感到生产性地缩小解决方案空间。

适用边界 · 注意事项

• 没有 design/gdd/game-concept.md 时：本流程会失败并提示先运行 /brainstorm，故不适用。
• 项目 workflow=minimal 且不存在视觉资产故事时：Art Bible 非必需，可跳过。
• 环境未提供 art-director / creative-director / ux-designer / technical-artist 等 agent、director-gates 与 .claude/docs 配置时，本流程无法按设计执行。