迁移art-bible到Codex原生skill

skills/art-bible/DETAILS.md

@@ -0,0 +1,219 @@
+# Art Bible Workflow
+
+Use this workflow to create or maintain `design/art/art-bible.md`, the visual
+source of truth for the project. Work section by section. The user remains the
+decision maker; the skill supplies professional framing, agent drafts, and
+document maintenance.
+
+## Phase 0: Context Check
+
+1. Parse an optional `--review full|lean|solo` argument.
+2. If no review argument is provided, read `production/review-mode.txt`.
+3. If no review mode is configured, default to `lean`.
+4. Read `design/gdd/game-concept.md`.
+   - If it does not exist, stop and tell the user to run `$brainstorm` first.
+   - Do not create an art bible without a concept document.
+5. Extract the concept context:
+   - game title
+   - elevator pitch
+   - core fantasy
+   - design pillars
+   - Visual Identity Anchor
+   - target platform
+6. Read `docs/technical-preferences.md` if it exists.
+   - Extract engine, language, platform, rendering constraints, input targets,
+     and performance budgets.
+   - If it is missing, continue with conservative placeholders and mention that
+     `$setup-engine` can fill technical constraints later.
+7. If an engine is configured, read `docs/engine-reference/<engine>/VERSION.md`
+   when Section 8 needs version-specific asset or rendering constraints.
+
+## Target Document
+
+- Primary output: `design/art/art-bible.md`
+- Template source: `../../references/studio-docs/templates/art-bible.md`
+- First write may create `design/art/` and a skeleton with the 9 section
+  headings.
+- Skeleton creation is allowed, but section body text must be written or
+  replaced only after user approval.
+
+## Codex Structured Input
+
+Use Codex `request_user_input` for bounded decisions. Follow these limits:
+
+- Ask 1-3 short questions per call.
+- Use 2-5 mutually exclusive options per question.
+- Keep `header` to 12 or fewer characters.
+- Use `id` in `snake_case`.
+- Keep option labels to 1-5 words.
+- Add `(Recommended)` to the recommended option when there is one.
+- Use normal conversation for open-ended reference lists and write approvals.
+
+## Retrofit Mode
+
+If `design/art/art-bible.md` already exists, inspect the 9 sections before
+asking new questions.
+
+Classify each section:
+
+- `Complete`: meaningful project-specific text exists.
+- `Empty`: heading exists with no useful body.
+- `Placeholder`: body contains TBD, TODO, bracket placeholders, or generic
+  template copy.
+
+Default behavior:
+
+- Resume missing work by filling only `Empty` or `Placeholder` sections.
+- Do not rewrite `Complete` sections.
+- Revise a complete section only when the user explicitly names that section or
+  asks for a targeted update.
+- Preserve unrelated content, status notes, and earlier approved decisions.
+
+## Phase 1: Framing
+
+Ask the scope with `request_user_input`:
+
+- `Full Bible (Recommended)`: author all 9 sections.
+- `Visual Core`: author Sections 1-4 only.
+- `Asset Standards`: author Section 8 only.
+- `Resume Missing`: fill only Empty or Placeholder sections.
+
+Then ask for reference titles, images, URLs, or art influences in normal
+conversation. This is intentionally free-form because reference quality matters
+more than preset categories.
+
+If the concept includes a Visual Identity Anchor, state that it is the
+foundation for the art bible. Treat it as a constraint unless the user says to
+change direction.
+
+## Section Authoring Protocol
+
+For every selected section:
+
+1. Ask one focused question about the section's decision.
+2. Offer clear options with tradeoffs when the choice is bounded.
+3. Use the relevant Codex subagent workflow to draft the section.
+4. Present the draft or a compact summary to the user.
+5. Ask: `May I write section <section name> to design/art/art-bible.md?`
+6. After approval, write that section immediately and preserve other sections.
+7. If the user asks for revision, revise the draft and ask again before writing.
+
+Do not batch-write the full art bible without per-section confirmation.
+
+## Sections And Agent Routing
+
+### Section 1: Visual Identity Statement
+
+Purpose: define the one-line visual rule, the primary visual promise, and the
+non-negotiable art direction constraint.
+
+Use `art-director` through Codex subagent workflow.
+
+### Section 2: Mood & Atmosphere
+
+Purpose: define emotional targets, lighting attitude, density, pacing, and what
+the player should feel when looking at the game.
+
+Use `art-director` through Codex subagent workflow.
+
+### Section 3: Shape Language
+
+Purpose: define silhouettes, geometric or organic bias, proportion rules, visual
+rhythm, and readability priorities.
+
+Use `art-director` through Codex subagent workflow.
+
+### Section 4: Color System
+
+Purpose: define palette direction, color meanings, contrast rules, state colors,
+and accessibility constraints.
+
+Use `art-director` through Codex subagent workflow.
+
+### Section 5: Character Design Direction
+
+Purpose: define character silhouette, costume/material language, facial or body
+expressiveness, animation attitude, and player/NPC distinction.
+
+Use `art-director` through Codex subagent workflow.
+
+### Section 6: Environment Design Language
+
+Purpose: define world materials, environmental motifs, navigational readability,
+scale cues, and progression of spaces.
+
+Use `art-director` through Codex subagent workflow.
+
+### Section 7: UI/HUD Visual Direction
+
+Purpose: define interface mood, hierarchy, screen density, typography direction,
+icon language, input readability, and accessibility expectations.
+
+Use `art-director` and `ux-designer` in parallel through Codex subagent workflow.
+If their recommendations conflict, summarize the conflict and ask the user to
+choose before writing.
+
+### Section 8: Asset Standards
+
+Purpose: define asset naming, file formats, resolution or mesh budgets,
+animation/VFX constraints, shader/material constraints, and handoff rules.
+
+Use `art-director` and `technical-artist` in parallel through Codex subagent
+workflow. Technical constraints must come from `docs/technical-preferences.md`
+and, when available, `docs/engine-reference/<engine>/VERSION.md` plus relevant
+engine reference notes.
+
+If technical preferences are missing, write conservative placeholder constraints
+and mark them as needing refresh after `$setup-engine`.
+
+### Section 9: Reference Direction
+
+Purpose: list references by purpose, specify what to borrow, specify what not to
+copy, and define visual anti-references.
+
+Use `art-director` through Codex subagent workflow.
+
+## AD-ART-BIBLE Sign-Off
+
+After the selected scope is complete, handle `AD-ART-BIBLE` based on review
+mode:
+
+- `full`: spawn `art-director` through Codex subagent workflow and ask it to run
+  `AD-ART-BIBLE` using the gate criteria in
+  `references/studio-docs/director-gates.md`.
+- `lean`: skip and output `AD-ART-BIBLE skipped - Lean mode`.
+- `solo`: skip and output `AD-ART-BIBLE skipped - Solo mode`.
+
+Pass this context to the sign-off:
+
+- `design/art/art-bible.md`
+- `design/gdd/game-concept.md`
+- Visual Identity Anchor
+- pillars and core fantasy
+- platform and performance constraints from `docs/technical-preferences.md`, if
+  configured
+
+Record the result in the art bible status header:
+
+- `APPROVED [date]`
+- `CONCERNS accepted [date]`
+- `REVISED [date]`
+
+If the sign-off returns concerns, show them to the user and ask whether to revise
+the named sections or accept the concerns as known risk.
+
+## Close
+
+Finish with a short status summary:
+
+- sections completed this run
+- sections still missing, if any
+- status of `AD-ART-BIBLE`
+- output path: `design/art/art-bible.md`
+
+Recommend only currently available next steps:
+
+- `$setup-engine` if engine or performance constraints are not configured.
+- `Stop here` if the user wants to pause after establishing visual direction.
+
+Verdict: COMPLETE

skills/art-bible/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: art-bible
+description: "Use when you need the /art-bible or $art-bible game-production workflow. Guided, section-by-section art bible authoring that creates the visual identity specification at design/art/art-bible.md."
+---
+
+# Art Bible
+
+Run the Codex Game Studios art-bible workflow.
+
+Before acting, read `DETAILS.md` for the full workflow. Apply project guidance
+from `AGENTS.md` and use `../../standards/` for path-specific standards.
+
+`$art-bible` requires `design/gdd/game-concept.md`. If it is missing, stop and
+tell the user to run `$brainstorm` first.
+
+Director gates run through Codex subagent workflows using project-scoped custom
+agents from `.codex/agents/`. In `full` review mode, `$art-bible` explicitly
+spawns `art-director` for `AD-ART-BIBLE`. Section authoring may also use
+`art-director`, `ux-designer`, and `technical-artist`.
+
+If the current project does not already have `.codex/agents/art-director.toml`,
+`.codex/agents/ux-designer.toml`, `.codex/agents/technical-artist.toml`, or root
+`AGENTS.md`, run `python3 scripts/install_codex_runtime.py <target-project>` from
+the plugin root first.
+
+`$art-bible` writes `design/art/art-bible.md`. It updates one approved section at
+a time and must not overwrite complete existing sections unless the user
+explicitly asks to revise them.

skills/art-bible/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Art Bible"
+  short_description: "Create visual identity and asset standards"
+  default_prompt: "Use $art-bible to create my game's art bible."

skills/brainstorm/DETAILS.md

@@ -379,7 +379,7 @@ If yes, generate the document using the template at `../../references/studio-doc
 
 **Path A — Design-First** (recommended if the concept is well-defined):
    1. "Run `$setup-engine` to configure the engine and populate version-aware reference docs"
-   2. "Run `/art-bible` to create the visual identity specification — do this BEFORE writing GDDs. **The art bible is required before the Technical Setup gate.** It gates asset production and shapes technical architecture decisions (rendering, VFX, UI systems)."
+   2. "Run `$art-bible` to create the visual identity specification — do this BEFORE writing GDDs. **The art bible is required before the Technical Setup gate.** It gates asset production and shapes technical architecture decisions (rendering, VFX, UI systems)."
    3. "Use `/design-review design/gdd/game-concept.md` to validate concept completeness before going downstream"
    4. "Discuss vision with the `creative-director` custom agent for pillar refinement"
    5. "Decompose the concept into individual systems with `/map-systems` — maps dependencies, assigns priorities, and creates the systems index"
@@ -392,7 +392,7 @@ If yes, generate the document using the template at `../../references/studio-doc
 **Path B — Prototype-First** (use if the core mechanic is unproven or the concept needs validation):
    1. "Run `$setup-engine` to configure the engine"
    2. "Run `/prototype [core-mechanic]` — validate the core idea is fun before writing any GDDs (1–3 days throwaway code)"
-   3. "If prototype PROCEEDS: run `/art-bible`, then continue with Path A steps 5–10 above, using prototype learnings to inform your GDDs"
+   3. "If prototype PROCEEDS: run `$art-bible`, then continue with Path A steps 5–10 above, using prototype learnings to inform your GDDs"
    4. "If prototype PIVOTS: return to `$brainstorm` with the learnings and reshape the concept"
    5. "After full design and architecture, build the `/vertical-slice` to validate production readiness before committing to sprints"
 
@@ -418,7 +418,7 @@ append this notice to the current response before continuing:
 
 After the game concept is written, follow the pre-production pipeline in order:
 1. `$setup-engine` — configure the engine and populate version-aware reference docs
-2. `/art-bible` — establish visual identity before writing any GDDs
+2. `$art-bible` — establish visual identity before writing any GDDs
 3. `/map-systems` — decompose the concept into individual systems with dependencies
 4. `/design-system [first-system]` — author per-system GDDs in dependency order
 5. `/create-architecture` — produce the master architecture blueprint