Token导航 LogoToken导航

Agent Skill · 前端设计

art-bible(艺术圣经)

art-bible 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

art-bible 是前端设计类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为执行命令;许可证信息还不明确,第三方扫描已通过,按安装量在前端设计类的 10,216 个 Skill 里排第 6,472。

总安装 499周安装 21GitHub Stars 16,565下载 175核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:art-bible(艺术圣经)
来源仓库:https://github.com/donchitos/claude-code-game-studios
仓库路径:skills/art-bible
安装命令:
npx skills add https://github.com/donchitos/claude-code-game-studios --skill art-bible
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/donchitos/claude-code-game-studios --skill art-bible

这个 Skill 是做什么的

前端设计类 Skill 关注页面结构、视觉规范和组件写法,输出通常是可运行的界面代码。

art-bible 用于管理游戏美术风格指南与视觉一致性标准。适用于 Codex、Claude、Cursor、Gemini CLI 中需要建立和维护艺术圣经的项目。基于已批准的游戏概念文档,提取标题、核心幻想、支柱与视觉规范。需先运行 /brainstorm 生成游戏概念,再使用此技能进行后续艺术指导。

art-bible 属于前端设计类 Skill,可作为该场景下的辅助能力补充。

来源仓库内路径:skills/art-bible

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/donchitos/claude-code-game-studios --skill art…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要执行命令,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

art-bible 怎么安装?

在终端执行 npx skills add https://github.com/donchitos/claude-code-game-studios --skill art-bible。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

art-bible 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

art-bible 需要什么权限?

权限级别是执行命令。安装流程涉及命令执行,可能通过 npx skills add https://github.com/donchitos/claude-code-game-studios --skill art-bible 联网下载 Skill 或依赖。用户安装前应确认命令来源、仓库内容和执行环境。

art-bible 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

art-bible 用的人多吗?

公开数据是累计安装 499 次,近一周安装 21 次,下载 175 次,GitHub 16,565 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

art-bible 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 第三方扫描已通过,常见的高风险行为没有命中。
  • 来源仓库有 16,565 星,维护活跃度相对可查。

先想清楚的地方

  • 需要执行命令,装到常用环境前要先评估影响面。
  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理前端设计类任务、又不想每次都手写提示词的人。

不太适合

  • 不能接受 Skill 在你机器上执行命令的人。
  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

前端设计类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
frontend-design

前端设计 · Codex、Claude

8,823,360126,072只读MIT通过
vercel-composition-patterns

Vercel 组合模式 · Codex、Claude

3,858,81625,893需要联网MIT通过
vercel-react-native-skills

Vercel React native skills 前端 · Codex、Claude

2,468,66425,878只读MIT通过
adapt

adapt 搜索 · Codex、Claude

2,027,04023,125操作浏览器未明确通过
bolder

bolder 分析 · Codex、Claude

2,004,28823,130只读未明确通过
art-bible

艺术圣经 · 本页

49916,565执行命令未明确通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Phase 0: Parse Arguments and Context Check

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.


Phase 1: Framing

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."

Phase 2: Visual Identity Foundation (Sections 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

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.

Section 2: Mood & Atmosphere

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.

Section 3: Shape Language

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.

Section 4: Color System

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.


Phase 3: Production Guides (Sections 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

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.

Section 6: Environment Design Language

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.

Section 7: UI/HUD Visual Direction

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.

Section 8: Asset Standards

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.


Phase 4: Reference Direction (Section 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.


Phase 5: Art Director Sign-Off

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]


Phase 6: Close

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.

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.

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

平台分布

Codex

36.66%
按下载量换算64

Claude

30.17%
按下载量换算53

Cursor

17.65%
按下载量换算31

Gemini CLI

10.44%
按下载量换算18

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

执行命令

安装流程涉及命令执行,可能通过 npx skills add https://github.com/donchitos/claude-code-game-studios --skill art-bible 联网下载 Skill 或依赖。用户安装前应确认命令来源、仓库内容和执行环境。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills