用途：为游戏项目撰写美术圣经，确立视觉识别，作为后续资产制作的把关文档，应在 /map-systems 之前运行。
主要能力：按九个章节组织内容——1 视觉识别声明、2 氛围与情绪、3 形状语言、4 色彩系统、5 角色设计方向、6 环境设计语言、7 UI/HUD 视觉方向、8 资产标准、9 参考方向。支持三种工作流层级：full 要求全部九节；standard 仅在项目存在视觉资产故事时要求，最低为 1–4 节；minimal 不要求，可自愿运行。workflow_overrides.art_bible_strict: true 可强制全部九节。docs.density 控制每节深度：terse（默认，约束与参考的要点列表）、balanced（段落解释每个视觉选择）、thorough（完整散文，含风格探索、参考与理由）。
使用方式：先读取 design/gdd/game-concept.md，或在 rigor: minimal 下读取 design/game-brief.md；两者都不存在则报错提示先运行 /brainstorm。若 design/art/art-bible.md 已存在，进入改造模式，用 Grep 定位章节标题与占位标记，构建章节状态表（Complete/Empty/Placeholder），只补写未完成章节，不触碰已有内容。新会话首次获批章节时从 .claude/docs/templates/art-bible.md 创建文件。每节须经 AskUserQuestion 批准后才写入文件。第 1 节单独委派 art-director；第 2–4 节合并为一次委派；第 5–6 节合并为一次委派；第 7 节并行委派 art-director 与 ux-designer；第 8 节并行委派 art-director 与 technical-artist。资产标准需读取 project.yaml 的 performance.* 与 engine.name，缺失时回退到 .claude/docs/technical-preferences.md。
适用场景：游戏项目在概念获批后、资产生产前建立统一视觉规范，供内部或外包团队遵循。
限制：依赖游戏概念或简报文件，缺失即失败；各节需用户逐节批准；美术偏好与技术约束冲突时须显式呈现并由用户决定，不自动解决；具体命令与配置细节以资料为准，其余未提供。