Back to Details

art-bible

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Phase 0: Parse Arguments and Context Check

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

Resolve the review mode (once, store for all gate spawns this run):
  1. If 
    --review [full|lean|solo]
    was passed → use that
  2. Else read 
    production/review-mode.txt
    → use that value
  3. Else → default to 
    lean
See 
.claude/docs/director-gates.md
for the full check pattern.
Read 
design/gdd/game-concept.md
. If it does not exist, fail with:
"No game concept found. Run 
/brainstorm
first — the art bible is authored after the game concept is approved."
Extract from game-concept.md:
  • Game title (working title)
  • Core fantasy and elevator pitch
  • Game pillars (all of them)
  • Visual Identity Anchor section if present (from brainstorm Phase 4 art-director output)
  • Target platform (if noted)
Retrofit mode detection: Glob 
design/art/art-bible.md
. If the file exists:
  • Read it in full
  • For each of the 9 sections, check whether the body contains real content (more than a 
    [To be designed]
    placeholder or similar) vs. is empty/placeholder
  • Build a section status table:
Section | Status
--------|--------
1. Visual Identity Statement | [Complete / Empty / Placeholder]
2. Color Palette | ...
3. Lighting & Atmosphere | ...
4. Character Art Direction | ...
5. Environment & Level Art | ...
6. UI Visual Language | ...
7. VFX & Particle Style | ...
8. Asset Standards | ...
9. Style Prohibitions | ...
  • Present this table to the user:
    "Found existing art bible at 
    design/art/art-bible.md
    . [N] sections are complete, [M] need content. I'll work on the incomplete sections only — existing content will not be touched."
  • Only work on sections with Status: Empty or Placeholder. Do not re-author sections that are already complete.
If the file does not exist, this is a fresh authoring session — proceed normally.
Read 
.claude/docs/technical-preferences.md
if it exists — extract performance budgets and engine for asset standard constraints.
解析审核模式（本次运行中所有gate生成均沿用此设置）：
  1. 若传入
    --review [full|lean|solo]
    参数 → 使用该值
  2. 否则读取
    production/review-mode.txt
    文件 → 使用其中的值
  3. 否则 → 默认使用
    lean
    模式
完整的检查规则请查看
.claude/docs/director-gates.md
。
读取
design/gdd/game-concept.md
文件。若文件不存在，则报错：
"未找到游戏概念文档。请先执行/brainstorm流程——美术规范手册需在游戏概念获批后编写。"
从game-concept.md中提取以下内容：
  • 游戏标题（暂定名）
  • 核心幻想与电梯游说（简短推介语）
  • 游戏核心支柱（全部内容）
  • 若存在视觉标识锚点章节（来自brainstorm阶段4的art-director输出）
  • 目标平台（如有标注）
翻新模式检测：遍历
design/art/art-bible.md
文件。若文件存在：
  • 完整读取文件内容
  • 针对9个章节，逐一检查正文是否包含实际内容（而非
    [待设计]
    之类的占位符或空内容）
  • 构建章节状态表：
章节 | 状态
--------|--------
1. 视觉标识声明 | [已完成 / 空 / 占位符]
2. 调色板 | ...
3. 光照与氛围 | ...
4. 角色美术风格指引 | ...
5. 环境与关卡美术 | ...
6. UI视觉语言 | ...
7. 特效与粒子风格 | ...
8. 资产标准 | ...
9. 风格禁忌 | ...
  • 向用户展示此表格：
    "在
    design/art/art-bible.md
    路径下找到已有的美术规范手册。[N]个章节已完成，[M]个章节需要补充内容。我将仅处理未完成的章节——已有的内容不会被修改。"
  • 仅处理状态为“空”或“占位符”的章节。请勿重新编写已完成的章节。
若文件不存在，则为全新编写流程——正常推进。
若
.claude/docs/technical-preferences.md
文件存在，则读取该文件——提取性能预算与引擎信息，作为资产标准的约束条件。

Phase 1: Framing

阶段1：框架确认

Present the session context and ask two questions before authoring anything:
Use 
AskUserQuestion
with two tabs:
  • Tab "Scope" — "Which sections need to be authored today?" Options: 
    Full bible — all 9 sections
    / 
    Visual identity core (sections 1–4 only)
    / 
    Asset standards only (section 8)
    / 
    Resume — fill in missing sections
  • Tab "References" — "Do you have reference games, films, or art that define the visual direction?" (Free text — let the user type specific titles. Do NOT preset options here.)
If the game-concept.md has a Visual Identity Anchor section, note it:
"Found a visual identity anchor from brainstorm: '[anchor name] — [one-line rule]'. I'll use this as the foundation for the art bible."
在开始编写前，向用户展示会话上下文并提出两个问题：
使用
AskUserQuestion
工具，包含两个标签页：
  • 标签页**"范围"** — "今天需要编写哪些章节？" 选项：
    完整手册——全部9个章节
    / 
    视觉标识核心（仅第1-4章节）
    / 
    仅资产标准（第8章节）
    / 
    续编——补充缺失章节
  • 标签页**"参考资料"** — "你是否有定义视觉风格方向的参考游戏、电影或美术作品？" （自由文本输入——允许用户输入具体名称。此处请勿预设选项。）
若game-concept.md中包含视觉标识锚点章节，则需注明：
"从brainstorm流程中找到视觉标识锚点：'[锚点名称] — [单行规则]'。我将以此为基础编写美术规范手册。"

Phase 2: Visual Identity Foundation (Sections 1–4)

阶段2：视觉标识基础（第1-4章节）

These four sections define the core visual language. All other sections flow from them. Author and write each to file before moving to the next.
这四个章节定义核心视觉语言。所有其他章节均以此为基础展开。完成每个章节的编写后立即写入文件，再推进至下一章节。

Section 1: Visual Identity Statement

第1章节：视觉标识声明

Goal: A one-line visual rule plus 2–3 supporting principles that resolve visual ambiguity.
If a visual anchor exists from game-concept.md: present it and ask:
  • "Build directly from this anchor?"
  • "Revise it before expanding?"
  • "Start fresh with new options?"
Agent delegation (MANDATORY): Spawn 
art-director
via Task:
  • Provide: game concept (elevator pitch, core fantasy), full pillar set, platform target, any reference games/art from Phase 1 framing, the visual anchor if it exists
  • Ask: "Draft a Visual Identity Statement for this game. Provide: (1) a one-line visual rule that could resolve any visual decision ambiguity, (2) 2–3 supporting visual principles, each with a one-sentence design test ('when X is ambiguous, this principle says choose Y'). Anchor all principles directly in the stated pillars — each principle must serve a specific pillar."
Present the art-director's draft to the user. Use 
AskUserQuestion
:
  • Options: 
    [A] Lock this in
    / 
    [B] Revise the one-liner
    / 
    [C] Revise a supporting principle
    / 
    [D] Describe my own direction
Write the approved section to file immediately.
目标：一条单行视觉规则，外加2-3条支持性原则，用于解决视觉歧义。
若game-concept.md中存在视觉标识锚点：展示该锚点并询问：
  • "直接基于此锚点展开编写？"
  • "先修订此锚点再展开？"
  • "从零开始提出新方案？"
Agent委托（强制要求）：通过Task生成
art-director
Agent：
  • 提供信息：游戏概念（电梯游说、核心幻想）、完整核心支柱集、目标平台、阶段1框架确认中获取的参考游戏/美术作品（如有）、视觉标识锚点（如有）
  • 要求："为此游戏起草视觉标识声明。需包含：(1) 一条可解决任何视觉决策歧义的单行视觉规则；(2) 2-3条支持性视觉原则，每条原则需附带一句设计测试说明（'当X存在歧义时，此原则要求选择Y'）。所有原则需直接关联已明确的核心支柱——每条原则必须服务于特定的核心支柱。"
将art-director起草的内容展示给用户。使用
AskUserQuestion
工具：
  • 选项：
    [A] 确认此版本
    / 
    [B] 修订单行规则
    / 
    [C] 修订某条支持性原则
    / 
    [D] 描述我自己的风格方向
获批准后立即将该章节写入文件。

Section 2: Mood & Atmosphere

第2章节：情绪与氛围

Goal: Emotional targets by game state — specific enough for a lighting artist to work from.
For each major game state (e.g., exploration, combat, victory, defeat, menus — adapt to this game's states), define:
  • Primary emotion/mood target
  • Lighting character (time of day, color temperature, contrast level)
  • Atmospheric descriptors (3–5 adjectives)
  • Energy level (frenetic / measured / contemplative / etc.)
Agent delegation: Spawn 
art-director
via Task with the Visual Identity Statement and pillar set. Ask: "Define mood and atmosphere targets for each major game state in this game. Be specific — 'dark and foreboding' is not enough. Name the exact emotional target, the lighting character (warm/cool, high/low contrast, time of day direction), and at least one visual element that carries the mood. Each game state must feel visually distinct from the others."
Write the approved section to file immediately.
目标：针对不同游戏状态设定情绪目标——具体到足以让灯光师据此开展工作。
针对每个主要游戏状态（例如：探索、战斗、胜利、失败、菜单——根据游戏实际状态调整），定义：
  • 核心情绪/氛围目标
  • 光照特征（时段、色温、对比度等级）
  • 氛围描述词（3-5个形容词）
  • 能量等级（狂热 / 平稳 / 沉思 / 等）
Agent委托：通过Task生成
art-director
Agent，提供视觉标识声明与核心支柱集。要求："为此游戏的每个主要状态定义情绪与氛围目标。需具体明确——'黑暗阴森'这类描述不够。请指明确切的情绪目标、光照特征（暖/冷色调、高/低对比度、时段倾向），以及至少一个承载该氛围的视觉元素。每个游戏状态的视觉感受必须与其他状态明显区分。"
获批准后立即将该章节写入文件。

Section 3: Shape Language

第3章节：形状语言

Goal: The geometric vocabulary that makes this game's world visually coherent and distinguishable.
Cover:
  • Character silhouette philosophy (how readable at thumbnail size? Distinguishing trait per archetype?)
  • Environment geometry (angular/curved/organic/geometric — which dominates and why?)
  • UI shape grammar (does UI echo the world aesthetic, or is it a distinct HUD language?)
  • Hero shapes vs. supporting shapes (what draws the eye, what recedes?)
Agent delegation: Spawn 
art-director
via Task with Visual Identity Statement and mood targets. Ask: "Define the shape language for this game. Connect each shape principle back to the visual identity statement and a specific game pillar. Explain what these shape choices communicate to the player emotionally."
Write the approved section to file immediately.
目标：构建几何词汇体系，使游戏世界在视觉上连贯且具有辨识度。
涵盖内容：
  • 角色轮廓设计理念（缩略图尺寸下的可读性如何？每个archetype（原型）的独特特征是什么？）
  • 环境几何形态（棱角分明/曲线柔和/有机形态/几何化——哪种占主导，原因是什么？）
  • UI形状语法（UI是否呼应世界美学，还是采用独立的HUD语言？）
  • 核心形状与辅助形状（哪些元素吸引眼球，哪些元素退居次要？）
Agent委托：通过Task生成
art-director
Agent，提供视觉标识声明与氛围目标。要求："为此游戏定义形状语言。将每条形状原则与视觉标识声明及特定游戏核心支柱关联起来。解释这些形状选择在情感层面向玩家传递了什么信息。"
获批准后立即将该章节写入文件。

Section 4: Color System

第4章节：色彩系统

Goal: A complete, producible palette system that serves both aesthetic and communication needs.
Cover:
  • Primary palette (5–7 colors with roles — not just hex codes, but what each color means in this world)
  • Semantic color usage (what does red communicate? Gold? Blue? White? Establish the color vocabulary)
  • Per-biome or per-area color temperature rules (if the game has distinct areas)
  • UI palette (may differ from world palette — define the divergence explicitly)
  • Colorblind safety: which semantic colors need shape/icon/sound backup
Agent delegation: Spawn 
art-director
via Task with Visual Identity Statement and mood targets. Ask: "Design the color system for this game. Every semantic color assignment must be explained — why does this color mean danger/safety/reward in this world? Identify which color pairs might fail colorblind players and specify what backup cues are needed."
Write the approved section to file immediately.
目标：一套完整、可落地的调色板体系，兼顾美学与信息传达需求。
涵盖内容：
  • 主调色板（5-7种颜色，附带功能定位——不仅提供十六进制代码，还需说明每种颜色在游戏世界中的含义）
  • 语义色彩用法（红色代表什么？金色？蓝色？白色？建立色彩词汇体系）
  • 按生物群系或区域划分的色温规则（若游戏包含不同区域）
  • UI调色板（可能与世界调色板不同——需明确说明差异）
  • 色盲友好性：哪些语义色彩需要搭配形状/图标/声音作为辅助提示
Agent委托：通过Task生成
art-director
Agent，提供视觉标识声明与氛围目标。要求："为此游戏设计色彩系统。每个语义色彩的分配必须附带解释——为何该颜色在游戏世界中代表危险/安全/奖励？识别可能对色盲玩家不友好的色彩组合，并指定所需的辅助提示方式。"
获批准后立即将该章节写入文件。

Phase 3: Production Guides (Sections 5–8)

阶段3：制作指引（第5-8章节）

These sections translate the visual identity into concrete production rules. They should be specific enough that an outsourcing team can follow them without additional briefing.
这些章节将视觉标识转化为具体的制作规则。规则需足够明确，使外包团队无需额外说明即可遵循。

Section 5: Character Design Direction

第5章节：角色设计指引

Agent delegation: Spawn 
art-director
via Task with sections 1–4. Ask: "Define character design direction for this game. Cover: visual archetype for the player character (if any), distinguishing feature rules per character type (how do players tell enemies/NPCs/allies apart at a glance?), expression/pose style targets (stiff/expressive/realistic/exaggerated), and LOD philosophy (how much detail is preserved at game camera distance?)."
Write the approved section to file.
Agent委托：通过Task生成
art-director
Agent，提供第1-4章节内容。要求："为此游戏定义角色设计指引。涵盖：玩家角色的视觉原型（如有）、不同角色类型的独特特征规则（玩家如何一眼区分敌人/NPC/盟友？）、表情/姿态风格目标（僵硬/富有表现力/写实/夸张）、LOD（层次细节）设计理念（在游戏相机距离下保留多少细节？）。"
获批准后将该章节写入文件。

Section 6: Environment Design Language

第6章节：环境设计语言

Agent delegation: Spawn 
art-director
via Task with sections 1–4. Ask: "Define the environment design language for this game. Cover: architectural style and its relationship to the world's culture/history, texture philosophy (painted vs. PBR vs. stylized — why this choice for this game?), prop density rules (sparse/dense — what drives the choice per area type?), and environmental storytelling guidelines (what visual details should tell the story without text?)."
Write the approved section to file.
Agent委托：通过Task生成
art-director
Agent，提供第1-4章节内容。要求："为此游戏定义环境设计语言。涵盖：建筑风格及其与世界文化/历史的关联、纹理设计理念（手绘风格/PBR/stylized风格——为何为此游戏选择该风格？）、道具密度规则（稀疏/密集——不同区域类型的选择依据是什么？）、环境叙事准则（哪些视觉细节无需文字即可传递故事信息？）。"
获批准后将该章节写入文件。

Section 7: UI/HUD Visual Direction

第7章节：UI/HUD视觉指引

Agent delegation: Spawn in parallel:
  • art-director
    : Visual style for UI — diegetic vs. screen-space HUD, typography direction (font personality, weight, size hierarchy), iconography style (flat/outlined/illustrated/photorealistic), animation feel for UI elements
  • ux-designer
    : UX alignment check — does the visual direction support the interaction patterns this game requires? Flag any conflicts between art direction and readability/accessibility needs.
Collect both. If they conflict (e.g., art-director wants elaborate diegetic UI but ux-designer flags it would reduce combat readability), surface the conflict explicitly with both positions. Do NOT silently resolve — use 
AskUserQuestion
to let the user decide.
Write the approved section to file.
并行Agent委托：
  • art-director
    ：UI视觉风格——嵌入场景式（diegetic）vs屏幕空间式HUD、排版方向（字体个性、字重、尺寸层级）、图标风格（扁平化/轮廓化/插画风格/写实风格）、UI元素动画质感
  • ux-designer
    ：UX一致性检查——视觉风格是否支持游戏所需的交互模式？标记美术风格与可读性/无障碍需求之间的任何冲突。
收集两者的输出。若存在冲突（例如：art-director要求复杂的嵌入场景式UI，但ux-designer指出这会降低战斗可读性），需明确呈现冲突双方的立场。请勿私下解决冲突——使用
AskUserQuestion
工具让用户决定。
获批准后将该章节写入文件。

Section 8: Asset Standards

第8章节：资产标准

Agent delegation: Spawn in parallel:
  • art-director
    : File format preferences, naming convention direction, texture resolution tiers, LOD level expectations, export settings philosophy
  • technical-artist
    : Engine-specific hard constraints — poly count budgets per asset category, texture memory limits, material slot counts, importer constraints, anything from the performance budgets in 
    .claude/docs/technical-preferences.md
If any art preference conflicts with a technical constraint (e.g., art-director wants 4K textures but performance budget requires 2K for mobile), resolve the conflict explicitly — note both the ideal and the constrained standard, and explain the tradeoff. Ambiguity in asset standards is where production costs are born.
Write the approved section to file.
并行Agent委托：
  • art-director
    ：文件格式偏好、命名规范方向、纹理分辨率层级、LOD级别预期、导出设置理念
  • technical-artist
    ：引擎特定硬约束——各资产类别面数预算、纹理内存限制、材质插槽数量、导入器约束、
    .claude/docs/technical-preferences.md
    文件中的所有性能预算内容
若美术偏好与技术约束存在冲突（例如：art-director要求4K纹理，但性能预算要求移动端使用2K纹理），需明确解决冲突——记录理想标准与受限标准，并解释权衡取舍。资产标准的模糊性会导致制作成本增加。
获批准后将该章节写入文件。

Phase 4: Reference Direction (Section 9)

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

Goal: A curated reference set that is specific about what to take and what to avoid from each source.
Agent delegation: Spawn 
art-director
via Task with the completed sections 1–8. Ask: "Compile a reference direction for this game. Provide 3–5 reference sources (games, films, art styles, or specific artists). For each: name it, specify exactly what visual element to draw from it (not 'the general aesthetic' — a specific technique, color choice, or compositional rule), and specify what to explicitly avoid or diverge from (to prevent the 'trying to copy X' reading). References should be additive — no two references should be pointing in exactly the same direction."
Write the approved section to file.
目标：一套精心筛选的参考资料集，明确说明从每个来源中借鉴什么、规避什么。
Agent委托：通过Task生成
art-director
Agent，提供已完成的第1-8章节内容。要求："为此游戏整理参考方向。提供3-5个参考来源（游戏、电影、美术风格或特定艺术家）。每个来源需包含：名称、明确说明需借鉴的视觉元素（而非'整体美学'——需指明具体技术、色彩选择或构图规则）、明确说明需规避或偏离的内容（以避免'刻意模仿X'的问题）。参考资料需具有互补性——任意两个参考资料的方向不应完全一致。"
获批准后将该章节写入文件。

Phase 5: Art Director Sign-Off

阶段5：美术总监签字确认

Review mode check — apply before spawning AD-ART-BIBLE:
  • solo
    → skip. Note: "AD-ART-BIBLE skipped — Solo mode." Proceed to Phase 6.
  • lean
    → skip (not a PHASE-GATE). Note: "AD-ART-BIBLE skipped — Lean mode." Proceed to Phase 6.
  • full
    → spawn as normal.
After all sections are complete (or the scoped set from Phase 1 is complete), spawn 
creative-director
via Task using gate AD-ART-BIBLE (
.claude/docs/director-gates.md
).
Pass: art bible file path, game pillars, visual identity anchor.
Handle verdict per standard rules in 
director-gates.md
. Record the verdict in the art bible's status header: 
> **Art Director Sign-Off (AD-ART-BIBLE)**: APPROVED [date] / CONCERNS (accepted) [date] / REVISED [date]
审核模式检查——在生成AD-ART-BIBLE前执行：
  • solo
    模式 → 跳过。备注："AD-ART-BIBLE已跳过——Solo模式。" 推进至阶段6。
  • lean
    模式 → 跳过（非PHASE-GATE）。备注："AD-ART-BIBLE已跳过——Lean模式。" 推进至阶段6。
  • full
    模式 → 正常生成。
所有章节完成后（或阶段1指定的范围完成后），通过Task生成
creative-director
Agent，使用gate AD-ART-BIBLE（
.claude/docs/director-gates.md
）。
传递信息：美术规范手册文件路径、游戏核心支柱、视觉标识锚点。
根据
director-gates.md
中的标准规则处理审核结果。将结果记录在美术规范手册的状态页眉中： 
> **美术总监签字确认（AD-ART-BIBLE）**: 已批准 [日期] / 有意见（已接受）[日期] / 已修订 [日期]

Phase 6: Close

阶段6：收尾

Before presenting next steps, check project state:
  • Does 
    design/gdd/systems-index.md
    exist? → map-systems is done, skip that option
  • Does 
    .claude/docs/technical-preferences.md
    contain a configured engine (not 
    [TO BE CONFIGURED]
    )? → setup-engine is done, skip that option
  • Does 
    design/gdd/
    contain any 
    *.md
    files? → design-system has been run, skip that option
  • Does 
    design/gdd/gdd-cross-review-*.md
    exist? → review-all-gdds is done
  • Do GDDs exist (check above)? → include /consistency-check option
Use 
AskUserQuestion
for next steps. Only include options that are genuinely next based on the state check above:
Option pool — include only if not already done:
  • [_] Run /map-systems — decompose the concept into systems before writing GDDs
    (skip if systems-index.md exists)
  • [_] Run /setup-engine — configure the engine (asset standards may need revisiting after engine is set)
    (skip if engine configured)
  • [_] Run /design-system — start the first GDD
    (skip if any GDDs exist)
  • [_] Run /review-all-gdds — cross-GDD consistency check (required before Technical Setup gate)
    (skip if gdd-cross-review-*.md exists)
  • [_] Run /asset-spec — generate per-asset visual specs and AI generation prompts from approved GDDs
    (include if GDDs exist)
  • [_] Run /consistency-check — scan existing GDDs against the art bible for visual direction conflicts
    (include if GDDs exist)
  • [_] Run /create-architecture — author the master architecture document (next Technical Setup step)
  • [_] Stop here
Assign letters A, B, C… only to the options actually included. Mark the most logical pipeline-advancing option as 
(recommended)
.
Always include 
/create-architecture
and Stop here as options — these are always valid next steps once the art bible is complete.
在展示下一步选项前，检查项目状态：
  • design/gdd/systems-index.md
    是否存在？→ 若已完成map-systems流程，则跳过该选项
  • .claude/docs/technical-preferences.md
    中是否已配置引擎（非
    [待配置]
    ）？→ 若已完成setup-engine流程，则跳过该选项
  • design/gdd/
    路径下是否存在
    *.md
    文件？→ 若已运行design-system流程，则跳过该选项
  • design/gdd/gdd-cross-review-*.md
    是否存在？→ 若已完成review-all-gdds流程，则跳过该选项
  • 是否存在GDD文档（检查上述内容）？→ 包含/consistency-check选项
使用
AskUserQuestion
工具展示下一步选项。仅包含基于上述状态检查的真实可行选项：
选项池——仅包含未完成的流程：
  • [_] 执行/map-systems——在编写GDD前将概念拆解为游戏系统
    （若systems-index.md存在则跳过）
  • [_] 执行/setup-engine——配置引擎（引擎设置完成后可能需要重新审视资产标准）
    （若已配置引擎则跳过）
  • [_] 执行/design-system——启动首个GDD编写
    （若存在任何GDD文档则跳过）
  • [_] 执行/review-all-gdds——跨GDD一致性检查（技术设置gate前需完成）
    （若存在gdd-cross-review-*.md则跳过）
  • [_] 执行/asset-spec——从获批的GDD生成单资产视觉规范与AI生成提示词
    （若存在GDD文档则包含）
  • [_] 执行/consistency-check——扫描现有GDD文档，检查是否与美术规范手册的视觉方向冲突
    （若存在GDD文档则包含）
  • [_] 执行/create-architecture——编写主架构文档（技术设置的下一步）
  • [_] 在此停止
仅为实际包含的选项分配字母A、B、C…。将最符合流程推进逻辑的选项标记为
(推荐)
。
始终包含
/create-architecture
与“在此停止”选项——美术规范手册完成后，这两个选项始终有效。

Collaborative Protocol

协作协议

Every section follows: Question → Options → Decision → Draft (from art-director agent) → Approval → Write to file
  • Never draft a section without first spawning the relevant agent(s)
  • Write each section to file immediately after approval — do not batch
  • Surface all agent disagreements to the user — never silently resolve conflicts between art-director and technical-artist
  • The art bible is a constraint document: it restricts future decisions in exchange for visual coherence. Every section should feel like it narrows the solution space productively.
每个章节遵循以下流程：提问 → 选项 → 决策 → 起草（来自art-director Agent）→ 批准 → 写入文件
  • 未生成相关Agent前，请勿起草任何章节
  • 获批准后立即将章节写入文件——请勿批量处理
  • 将所有Agent之间的分歧告知用户——请勿私下解决art-director与technical-artist之间的冲突
  • 美术规范手册是约束性文档：通过限制未来决策来换取视觉一致性。每个章节应有效缩小解决方案范围。

Recommended Next Steps

推荐下一步

After the art bible is approved:
  • Run 
    /map-systems
    to decompose the concept into game systems before authoring GDDs
  • Run 
    /setup-engine
    if the engine is not yet configured (asset standards may need revisiting after engine selection)
  • Run 
    /design-system [first-system]
    to start authoring per-system GDDs
  • Run 
    /consistency-check
    once GDDs exist to validate them against the art bible's visual rules
  • Run 
    /create-architecture
    to produce the master architecture document
美术规范手册获批后：
  • 执行/map-systems，在编写GDD前将概念拆解为游戏系统
  • 若尚未配置引擎，执行/setup-engine（引擎选定后可能需要重新审视资产标准）
  • 执行/design-system [首个系统]，开始编写单系统GDD文档
  • 若存在GDD文档，执行/consistency-check，验证其是否符合美术规范手册的视觉规则
  • 执行/create-architecture，生成主架构文档