art-bible

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,workflow,docs.density

已在上方解析——照此使用；--review 会覆盖 review_mode。没有区块 → 默认值见 .claude/docs/config-resolution.md。

美术圣经

阶段 0：解析参数并检查上下文

完整的检查模式请参见 .claude/docs/director-gates.md。各个门槛的定义位于 .claude/docs/director-gates/[gate-id].md——派生的 Agent 会读取自己的门槛文件；父会话不要读取该文件。

每次调用 AskUserQuestion 都必须遵循 .claude/docs/automation-modes.md （协作模式始终询问 · 引导模式仅在重大事项时询问 · 自主模式记录并继续； automation_always_ask 类别始终提示）。

docs.density——它控制每个章节的深度，而 workflow 控制哪些章节存在。modes.rigor 会同时设置两者；若只需调整深度，请显式设置 docs.density：terse（默认值，通过 rigor: minimal 设置）= 每个章节均为包含约束和 参考资料的项目符号列表；balanced = 用段落解释每个视觉选择 （rigor: standard）；thorough = 完整的散文，包含风格探索、参考资料和 每项选择的理由。将其应用于你撰写的每个章节。

workflow（参见 .claude/docs/workflow-modes.md）：

• full — 必须包含全部 9 个美术圣经章节。
• standard — 仅当项目中存在视觉资产故事时才需要； 需要时至少包含第 1–4 节。workflow_overrides.art_bible_strict: true 会强制要求全部 9 个章节，不受级别影响。
• minimal — 不作要求。仍可自愿执行。

读取 design/gdd/game-concept.md——或者读取 design/game-brief.md，它是一页式简报，在 rigor: minimal 时取代前者。按章节读取：使用 Grep 工具查找所需标题 （模式 ^#，内容模式），再通过 offset 和 limit 读取对应范围。 如果两者都不存在，则失败并显示：

"未找到游戏概念。请先运行 /brainstorm——美术圣经将在游戏概念获批后编写。"

从 game-concept.md 中提取（从简报中提取：暂定标题、宣传文案、“目标受众 / 体验感受”行和“美术与音频方向”行——简报中没有支柱、视觉 识别锚点或平台信息）：

• 游戏标题（暂定）
• 核心幻想和电梯推介
• 游戏支柱（全部）
• 视觉识别锚点章节（如存在，来自 brainstorm 阶段 4 的美术指导输出）
• 目标平台（如有注明）

改造模式检测：对 design/art/art-bible.md 执行 Glob。如果文件存在， 请建立状态表，不要读取文档——你即将只编写不完整的章节，因此加载已完成的章节， 恰好会加载你不会修改的内容：

Grep pattern="^## " path="design/art/art-bible.md" output_mode="content" -n
Grep pattern="\[To be designed\]|\[TBD\]|\[To be written\]|^_?TODO" path="design/art/art-bible.md" output_mode="content" -n

• 第一次 grep 会给出章节标题及其行号——相邻标题之间的间隔即为该章节的大小。
• 第二次会给出占位符标记及其所在位置。
• 如果章节到下一个标题之间有实质性内容，且其中没有占位符标记，则该章节为已完成；如果标记落在其范围内，则为占位符；如果相邻标题紧挨着，则为空。
• 如果两次 grep 仍无法明确判断某个章节，请使用 Read(offset, limit) 读取该章节的行范围——绝不要读取整个文件。
• 建立章节状态表：

Section | Status
--------|--------
1. Visual Identity Statement | [Complete / Empty / Placeholder]
2. Mood & Atmosphere | ...
3. Shape Language | ...
4. Color System | ...
5. Character Design Direction | ...
6. Environment Design Language | ...
7. UI/HUD Visual Direction | ...
8. Asset Standards | ...
9. Reference Direction | ...

• 向用户展示此表：

  "在 design/art/art-bible.md 中发现现有美术圣经。已完成 [N] 个章节，[M] 个章节需要补充内容。我只会处理不完整的章节——不会修改现有内容。"

• 只处理状态为“空”或“占位符”的章节。不要重新编写已经完成的章节。 如果文件不存在，这就是一个全新的编写会话。第一个获批的章节会根据 .claude/docs/templates/art-bible.md 创建文件。该模板中的九个 ## N. Name 标题正是改造模式读取的标题——请先询问： “可以根据艺术圣经模板创建 design/art/art-bible.md 吗？”随后，每个获批的章节都会将其自身的 [To be designed] 行替换为 Edit；标题必须与模板中的一致。

批准某个章节，即表示批准写入该章节。 每个章节都必须通过 AskUserQuestion 获得批准；其中批准选项必须为 [A] Lock this in and write it to design/art/art-bible.md（第 1 节的完整选项列表见下文）。选择该选项即表示批准写入该章节；无论是全新编写还是改造，都不得写入未获批准的章节。

提取素材标准约束所需的性能预算和引擎信息：从 project.yaml 读取 performance.* 和 engine.name；如果某个键缺失或为空（包括 project.yaml 中没有 performance 或 engine 块的情况），则回退到 .claude/docs/technical-preferences.md。

---

阶段 1：确定范围

在开始编写之前，介绍本次会话的背景并提出两个问题：

使用包含两个选项卡的 AskUserQuestion：

• 选项卡 “范围”——“今天需要编写哪些章节？” 选项：完整艺术圣经 — 全部 9 个章节 / 视觉识别核心（仅第 1–4 节） / 仅素材标准（第 8 节） / 继续 — 填写缺失章节

  将已解析的 workflow 层级实际要求的选项标记为 （推荐），并说明原因——层级已决定了这一点，用户不应为了作答而了解层级表：

  • full → 完整艺术圣经——此层级要求全部 9 个章节。
  • standard → 视觉识别核心（仅第 1–4 节）——只要需要艺术圣经，这就是文档规定的最低要求。说明：“standard 要求第 1–4 节；如果需要，也可以编写第 5–9 节。”
  • minimal → 不要求艺术圣经。提问前先说明这一点，并将第 1–4 节作为可选的实用内容，而不是默认编写全部 9 节。
  • workflow_overrides.art_bible_strict: true → 无论层级如何，都选择完整艺术圣经。

  这是本技能中影响成本最大的因素：每个编写的章节都需要启动一个专家流程，因此在层级只要求 4 个章节时编写 9 个章节，会使本次运行的成本翻倍有余，而产出的内容下游并不会检查。

• 选项卡 “参考”——“是否有确定视觉方向的参考游戏、电影或艺术作品？” （自由文本——让用户输入具体名称。此处不要预设选项。）

如果 game-concept.md 中有“视觉识别锚点”一节，请注明：

“发现来自头脑风暴的视觉识别锚点：‘[锚点名称] — [一行规则]’。我会以此为艺术圣经的基础。”

仅编写所选范围内的章节。 阶段 2–4 只处理所选范围内的章节——如果选择“继续”，则只处理改造表中的空缺和占位符行；跳过所有其他章节，以及没有待处理章节的阶段。阶段 6 会逐一列出本次未编写的章节及原因。

第 2 阶段：视觉识别基础（第 1–4 节）

这四节定义了核心视觉语言。**所有其他章节都由此延伸。**撰写每一节并写入文件后，再开始下一节。

**本阶段的委派策略。**第 1 节单独委派——它是基础，用户需要先在不同的核心方向之间做出选择，之后才能基于此构建其他内容。然后将第 2–4 节一起委派给 art-director，而不是分三次委派：这三节由同一个 Agent 使用相同的输入（视觉识别陈述 + 支柱）撰写，氛围、形状和色彩相互依存——艺术总监会将它们一起定义，而不会孤立地处理。分开调用会导致 Agent 在不了解刚写下的形状语言时，就要推理色彩。

这并未减少专家的参与程度——每一节仍由专家撰写，这正是 .claude/docs/effects-map.md 指出艺术圣经委派为强制要求的原因。相同的三节只需调用一次，而不是三次。每节由用户审批并立即写入文件的流程保持不变。

第 1 节：视觉识别陈述

目标：用一条视觉规则和 2–3 条辅助原则来消除视觉歧义。

如果 game-concept.md 中已有视觉锚点：展示该锚点并询问：

• “直接基于这个锚点构建？”
• “先修改，再展开？”
• “从头开始，提出新选项？”

Agent 委派（强制）：通过 Agent 启动 art-director：

• 提供：游戏概念（电梯推介、核心幻想）、完整的支柱集合、目标平台、第 1 阶段构思中的任何参考游戏 / 美术，以及已有的视觉锚点
• 询问：“为这款游戏起草一份视觉识别陈述。请提供：(1) 一条可用于消除任何视觉决策歧义的视觉规则；(2) 2–3 条辅助视觉原则，每条原则都附带一句设计检验标准（‘当 X 存在歧义时，本原则建议选择 Y’）。所有原则都必须直接锚定于既定支柱——每条原则都必须服务于某个特定支柱。（对于没有支柱的单页简报，请将原则锚定于其推介内容和‘感受’部分。）”

向用户展示艺术总监的草稿。使用 AskUserQuestion：

• 选项：[A] 确认并写入 design/art/art-bible.md / [B] 修改单句规则 / [C] 修改某条辅助原则 / [D] 描述我自己的方向

将获批的章节立即写入文件。

第 2 节：情绪与氛围

目标：根据游戏状态设定情绪目标——具体到灯光美术师可以据此开展工作。

针对每种主要游戏状态（如探索、战斗、胜利、失败、菜单——根据本游戏的状态调整），定义：

• 主要情绪／氛围目标
• 灯光特征（一天中的时段、色温、对比度）
• 氛围描述词（3–5 个形容词）
• 能量水平（狂热／沉稳／沉思等）

第 2–4 节的 Agent 委派——在此处一次调用。 通过 Agent 启动 art-director，提供已锁定的视觉身份陈述和支柱集合， 并要求它在同一份简报中完成全部三个部分：

1. 情绪与氛围——“为本游戏的每种主要游戏状态定义情绪与氛围目标。务必具体——仅说‘黑暗且令人不安’远远不够。明确具体的情绪目标、灯光特征（暖／冷、高／低对比度、一天中的时段倾向），以及至少一个承载这种情绪的视觉元素。每种游戏状态在视觉上都必须与其他状态截然不同。”
2. 形状语言——“定义本游戏的形状语言。将每项形状原则与视觉身份陈述和某个具体游戏支柱关联起来。说明这些形状选择在情感上向玩家传达什么。”
3. 色彩系统——“为本游戏设计色彩系统。必须解释每项语义色彩的指定——为什么在这个世界中，这种颜色代表危险／安全／奖励？指出哪些颜色组合可能不利于色盲玩家，并说明需要哪些备用提示。”

要求这三部分彼此保持一致——调色板必须服务于情绪目标和形状层级——并将结果分别标注为三个区块，以便每部分都能单独审批和写入文件。

然后向用户展示第 2 节，待其批准后立即写入文件， 再进入第 3 节。不要一次展示全部三部分：批量处理发生在委派阶段，而非审核阶段。

第 3 节：形状语言

目标：构成几何词汇，使本游戏的世界在视觉上连贯且易于辨识。

涵盖：

• 角色轮廓理念（缩略图尺寸下的辨识度如何？每种原型的区别特征是什么？）
• 环境几何（以棱角、曲线、有机形态还是几何形态为主？为什么？）
• UI 形状语法（UI 是否呼应世界美学，还是采用独立的 HUD 语言？）
• 主导形状与辅助形状（什么元素吸引视线，什么元素退居背景？）

草稿来源：使用第 2 节下发出的第 2–4 节委派所返回的形状语言区块。 不要再次启动 Agent。

将获批的部分立即写入文件。

第 4 节：色彩系统

目标：打造完整且可制作的调色板系统，兼顾美学与信息传达需求。

涵盖：

• 主调色板（5–7 种颜色及其用途——不只是十六进制代码，还要说明每种颜色在这个世界中的含义）
• 语义色彩用法（红色传达什么？金色呢？蓝色呢？白色呢？建立色彩词汇）
• 各生物群系或区域的色温规则（如果游戏有不同区域）
• UI 调色板（可能与世界调色板不同——明确说明差异）
• 色盲适用性：哪些语义颜色需要形状／图标／声音作为备用提示

草稿来源：使用第 2 节下发出的第 2–4 节委派所返回的色彩系统区块。 不要再次启动 Agent。

将获批的部分立即写入文件。

---

第 3 阶段：制作指南（第 5–8 节）

这些部分将视觉身份转化为具体的制作规则。规则应足够具体，让外包团队无需额外说明即可遵循。

第 5 节：角色设计方向

第 5–6 节的 Agent 委派——在此处发起一次调用。 两节需要使用同一个 Agent 和相同的输入（sections 1–4），因此再次调用只会重新发送整套视觉形象设定。将 sections 1–4 提供给 art-director，并要求它完成以下两项：

1. 角色设计方向——“涵盖：玩家角色的视觉原型（如有）、区分不同角色类型的规则（玩家如何一眼区分敌人、NPC 和盟友？）、表情／姿势风格目标（僵硬／生动／写实／夸张），以及 LOD 理念（在游戏镜头距离下保留多少细节？）。”
2. 环境设计语言——“涵盖：建筑风格及其与世界文化／历史的关系、纹理理念（绘制风格与 PBR 或风格化表现之间如何选择——为什么这种选择适合本游戏？）、道具密度规则（稀疏／密集——不同区域类型的选择由什么决定？），以及环境叙事指南（哪些视觉细节应在不使用文字的情况下讲述故事？）。”

要求角色和环境彼此清晰可辨——角色剪影必须能从同一份设计简报所定义的环境纹理密度中凸显出来。返回两个分别标注的内容块。

先呈现第 5 节，经批准后写入文件，再处理第 6 节。

第 6 节：环境设计语言

草稿来源：第 5 节中发起的第 5–6 节委派——使用它返回的环境内容块。不要再次发起调用。

将获批的章节写入文件。

第 7 节：UI/HUD 视觉方向

Agent 委派：并行启动：

• art-director：UI 的视觉风格——叙事融入式还是屏幕空间 HUD、字体方向（字体个性、字重、字号层级）、图标风格（扁平／描边／插画／照片级写实），以及 UI 元素的动画观感
• ux-designer：UX 一致性检查——视觉方向是否支持本游戏所需的交互模式？指出美术指导与可读性／无障碍需求之间的任何冲突。

收集两方的意见。如果存在冲突（例如，art-director 希望采用复杂的叙事融入式 UI，但 ux-designer 指出这会降低战斗中的可读性），请明确呈现双方的立场。不要擅自解决——使用 AskUserQuestion 让用户决定。

将获批的章节写入文件。

第 8 节：资源规范

Agent 委派：并行启动：

• art-director：文件格式偏好、命名规范方向、纹理分辨率档位、LOD 级别预期、导出设置理念
• technical-artist：引擎特定的硬性约束——各类资源的多边形数量预算、纹理内存限制、材质槽数量、导入器约束，以及性能预算（project.yaml 中的 performance.*；若无，则参考 .claude/docs/technical-preferences.md）

如果任何美术偏好与技术约束冲突（例如，art-director 希望使用 4K 纹理，但性能预算要求移动端使用 2K 纹理），请明确呈现冲突双方的立场——理想标准与受限标准，以及相应的权衡。不要擅自解决——使用 AskUserQuestion 让用户选择（选项：理想标准、受限标准，或记录两者并按每项资源具体判断）。资源规范中的模糊之处会催生制作成本。

将获批的章节写入文件。

阶段 4：参考方向（第 9 节）

目标：整理一组经过筛选的参考资料，明确指出每个来源中哪些内容值得借鉴，哪些内容应当避免。

Agent 委派：通过 Agent 启动 art-director，并提供已完成的第 1–8 节。提问：“请为这款游戏整理参考方向。提供 3–5 个参考来源（游戏、电影、艺术风格或特定艺术家）。对于每个来源：写明名称，准确指出要从中借鉴的视觉元素（不能只说‘整体美感’——应当是具体的技法、配色选择或构图规则），并明确指出需要避免或与之拉开差异的内容（防止给人‘试图复制 X’的印象）。参考来源应当互为补充——不能有两个来源指向完全相同的方向。”

将获批的章节写入文件。

---

阶段 5：艺术总监签核

检查评审模式——启动 AD-ART-BIBLE 前应用：

• solo → 跳过。注明：“已跳过 AD-ART-BIBLE——Solo 模式。”然后记录跳过情况（见下文），并继续阶段 6。
• lean → 跳过（不是 PHASE-GATE）。注明：“已跳过 AD-ART-BIBLE——Lean 模式。” 然后记录跳过情况（见下文），并继续阶段 6。
• full → 按正常流程启动。

若跳过，请询问：“我可以在 design/art/art-bible.md 的页眉中记录此次跳过的签核吗？”如果对方同意，则将页眉中的 > **Art Director Sign-Off (AD-ART-BIBLE)**: [Not yet reviewed] 替换为 > **Art Director Sign-Off (AD-ART-BIBLE)**: SKIPPED [date] — [solo|lean] mode ——关卡接受上述任一形式作为已记录的签核。

所有章节完成后（或阶段 1 中限定的章节范围完成后），通过 Agent 启动 art-director，并使用关卡 AD-ART-BIBLE（.claude/docs/director-gates/ad-art-bible.md）。

提供以下内容：艺术圣经路径（design/art/art-bible.md）；游戏支柱和核心幻想；平台和性能限制（project.yaml 中的 platform.* 和 performance.*，若没有则使用 .claude/docs/technical-preferences.md）；以及视觉识别锚点。若阶段 0 阅读了单页简报，则将其中的宣传语和“希望玩家感受到的内容”一并作为游戏支柱和核心幻想，并将“美术与音频方向”作为锚点传递。

根据 director-gates.md 中的标准规则处理评审结果。 对于 Revise flagged items，或为解决 REJECT，相关章节的专属专家——art-director，以及负责第 7 节的 ux-designer 和负责第 8 节的 technical-artist——需重新起草每个标记的章节，然后像其他章节一样提交、获批并写入文件，之后再记录 REVISED [date]。 NOT ASSESSED 绝不代表获批：指出缺少的输入，然后补充该输入并重新运行关卡，或记录为 NOT ASSESSED。 在艺术圣经的状态页眉中记录评审结果： > **Art Director Sign-Off (AD-ART-BIBLE)**: APPROVED [date] / CONCERNS (accepted) [date] / REVISED [date] / NOT ASSESSED [date] — [missing input]

---

第 6 阶段：收尾

首先，逐一说明本次未编写的九个章节及原因——超出所选范围，或已完成。例如：“本次未编写：第 5–9 节（超出所选范围；standard 要求编写第 1–4 节）。” 如果流程在第 4 节后停止，输出就不能看起来像一份完整的美术圣经。

展示后续步骤前，检查项目状态：

• design/gdd/systems-index.md 是否存在？→ map-systems 已完成，跳过该选项
• 是否已配置引擎——project.yaml 中存在 engine.name，或 .claude/docs/technical-preferences.md 中的 Engine 字段已配置（不是 [TO BE CONFIGURED]）？→ setup-engine 已完成，跳过该选项
• design/gdd/ 是否包含任何 *.md 文件？→ design-system 已运行，跳过该选项
• design/gdd/gdd-cross-review-*.md 是否存在？→ review-all-gdds 已完成
• 是否存在 GDD（见上方检查）？→ 包含 /consistency-check 选项

使用 AskUserQuestion 提供后续步骤。只包含根据上述状态检查确实适用的选项：

在 workflow: minimal 下，选项池为 /create-stories（尚无故事）或 /dev-story [next story]，以及“到此为止”——下方的 GDD/架构选项池仅适用于 standard/full。

选项池——仅在尚未完成时包含：

• [_] 运行 /map-systems — 在编写 GDD 前将概念分解为各个系统（如果 systems-index.md 存在则跳过）
• [_] 运行 /setup-engine — 配置引擎（设置引擎后可能需要重新审视资源规范）（如果引擎已配置则跳过）
• [_] 运行 /design-system — 开始编写第一份 GDD（如果已有任何 GDD 则跳过）
• [_] 运行 /review-all-gdds — 检查各 GDD 之间的一致性（通过 Technical Setup 门槛前必须完成）（如果 gdd-cross-review-*.md 存在则跳过）
• [_] 运行 /asset-spec — 根据已批准的 GDD 生成逐项资源视觉规范和 AI 生成提示词（如果已有 GDD 则包含）
• [_] 运行 /consistency-check — 检查现有 GDD 是否与美术圣经的视觉方向存在冲突（如果已有 GDD 则包含）
• [_] 运行 /create-architecture — 编写主架构文档（Technical Setup 的下一步）
• [_] 到此为止

仅将 A、B、C……分配给实际包含的选项。将最能推动流程前进的选项标记为 (recommended)。

始终包含（仅限 standard/full）/create-architecture 和“到此为止”两个选项——美术圣经完成后，这些始终是有效的后续步骤。

---

协作协议

适用于 collaborative 模式（默认模式）。 关于 guided 和 autonomous 模式，请参阅 .claude/docs/automation-modes.md——以下规则说明了 collaborative 模式的要求，并非通用行为。

每个章节都遵循：提问 → 选项 → 决策 → 草稿（由 art-director agent 提供）→ 批准 → 写入文件

• 绝不要自行起草章节——每个章节的内容都必须来自相应的专业 Agent。一次委派可以涵盖多个章节（第 2–4 节共用一次调用，第 5–6 节也一样），但不得以编排者自身的判断代替 Agent 来撰写任何章节。
• 每节获批后立即写入文件——不要批量处理写入或批准。批量处理仅适用于委派调用；用户仍会逐节查看、批准并提交。
• 将 Agent 之间的所有分歧呈现给用户——绝不要擅自解决 art-director 和 technical-artist 之间的冲突。
• 美术圣经是一份约束性文档：它通过限制未来的决策来换取视觉一致性。每个章节都应让解决方案空间得到有益的收窄。

---

推荐的后续步骤

通过美术设定手册审核后：

• 运行 /map-systems，将概念分解为游戏系统，然后再编写 GDD
• 如果尚未配置引擎，运行 /setup-engine（选择引擎后可能需要重新审视资源规范）
• 运行 /design-system [first-system]，开始编写各系统的 GDD
• GDD 编写完成后，运行 /consistency-check，根据美术设定手册中的视觉规则进行验证
• 运行 /create-architecture，生成主架构文档