菜单
Guided, section-by-section GDD authoring for a single game system. Gathers context from existing docs, walks through each required section collaboratively, cross-references dependencies, and writes incrementally to file.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | design-system |
| description | Guided, section-by-section GDD authoring for a single game system. Gathers context from existing docs, walks through each required section collaboratively, cross-references dependencies, and writes incrementally to file. |
| argument-hint | <system-name> [--review full|lean|solo] |
| user-invocable | true |
| allowed-tools | Read, Glob, Grep, Write, Edit, Task, AskUserQuestion, TodoWrite |
| model | sonnet |
When this skill is invoked:
Resolve the review mode (once, store for all gate spawns this run):
--review [full|lean|solo] was passed → use thatproduction/review-mode.txt → use that valueleanSee .claude/docs/director-gates.md for the full check pattern.
A system name or retrofit path is required. If missing:
design/gdd/systems-index.md exists.AskUserQuestion:
[A] Yes — design [system-name] / [B] Pick a different system / [C] Stop here"Usage:
/design-system <system-name>— e.g.,/design-system movementOr to fill gaps in an existing GDD:/design-system retrofit design/gdd/[system-name].mdNo systems index found. Run/map-systemsfirst to map your systems and get the design order."
Detect retrofit mode:
If the argument starts with retrofit or the argument is a file path to an
existing .md file in design/gdd/, enter retrofit mode:
[To be designed] or
equivalent — blank, a single line, or obviously incomplete).## Retrofit: [System Name]
File: design/gdd/[filename].md
Sections already written (will not be touched):
✓ [section name]
✓ [section name]
Missing or incomplete sections (will be authored):
✗ [section name] — missing
✗ [section name] — placeholder only
[To be designed] placeholders or empty section bodies.If NOT in retrofit mode, normalize the system name to kebab-case for the
filename (e.g., "combat system" becomes combat-system).
Read all relevant context before asking the user anything. This is the skill's primary advantage over ad-hoc design — it arrives informed.
design/gdd/game-concept.md — fail if missing:
"No game concept found. Run
/brainstormfirst."
design/gdd/systems-index.md — fail if missing:
"No systems index found. Run
/map-systemsfirst to map your systems."
"[system-name] is not in the systems index. Would you like to add it, or design it as an off-index system?"
design/registry/entities.yaml if it exists.
Extract all entries referenced by or relevant to this system (grep
referenced_by.*[system-name] and source.*[system-name]). Hold these
in context as known facts — values that other GDDs have already
established and this GDD must not contradict.docs/consistency-failures.md if it exists.
Extract entries whose Domain matches this system's category. These are
recurring conflict patterns — present them under "Past failure patterns"
in the Phase 2d context summary so the user knows where mistakes have
occurred before in this domain.From the systems index, identify:
For each dependency GDD that exists, extract and hold in context:
design/gdd/game-pillars.md if it existsdesign/gdd/[system-name].md if it exists (resume, don't
restart from scratch)design/gdd/*.md and read any that are thematically related
(e.g., if designing a system that overlaps with another in scope, read the related GDD
even if it's not a formal dependency)Before starting design work, present a brief summary to the user:
Designing: [System Name]
- Priority: [from index] | Layer: [from index]
- Depends on: [list, noting which have GDDs vs. undesigned]
- Depended on by: [list, noting which have GDDs vs. undesigned]
- Existing decisions to respect: [key constraints from dependency GDDs]
- Pillar alignment: [which pillar(s) this system primarily serves]
- Known cross-system facts (from registry):
- [entity_name]: [attribute]=[value], [attribute]=[value] (owned by [source GDD])
- [item_name]: [attribute]=[value], [attribute]=[value] (owned by [source GDD])
- [formula_name]: variables=[list], output=[min–max] (owned by [source GDD])
- [constant_name]: [value] [unit] (owned by [source GDD]) (These values are locked — if this GDD needs different values, surface the conflict before writing. Do not silently use different numbers.)
If no registry entries are relevant: omit the "Known cross-system facts" section.
If any upstream dependencies are undesigned, warn:
"[dependency] doesn't have a GDD yet. We'll need to make assumptions about its interface. Consider designing it first, or we can define the expected contract and flag it as provisional."
Before asking the user to begin designing, load engine context and surface any constraints or knowledge gaps that will shape the design.
Step 1 — Determine the engine domain for this system: Map the system's category (from systems-index.md) to an engine domain:
| System Category | Engine Domain |
|---|---|
| Combat, physics, collision | Physics |
| Rendering, visual effects, shaders | Rendering |
| UI, HUD, menus | UI |
| Audio, sound, music | Audio |
| AI, pathfinding, behavior trees | Navigation / Scripting |
| Animation, IK, rigs | Animation |
| Networking, multiplayer, sync | Networking |
| Input, controls, keybinding | Input |
| Save/load, persistence, data | Core |
| Dialogue, quests, narrative | Scripting |
Step 2 — Read engine context (if available):
.claude/docs/technical-preferences.md to identify the engine and versiondocs/engine-reference/[engine]/VERSION.mddocs/engine-reference/[engine]/modules/[domain].md if it existsdocs/engine-reference/[engine]/breaking-changes.md for domain-relevant entriesdocs/architecture/adr-*.md and read any ADRs whose domain matches
(check the Engine Compatibility table's "Domain" field)Step 3 — Present the Feasibility Brief:
If engine reference docs exist, present before starting design:
## Technical Feasibility Brief: [System Name]
Engine: [name + version]
Domain: [domain]
### Known Engine Capabilities (verified for [version])
- [capability relevant to this system]
- [capability 2]
### Engine Constraints That Will Shape This Design
- [constraint from engine-reference or existing ADR]
### Knowledge Gaps (verify before committing to these)
- [post-cutoff feature this design might rely on — mark HIGH/MEDIUM risk]
### Existing ADRs That Constrain This System
- ADR-XXXX: [decision summary] — means [implication for this GDD]
(or "None yet")
If no engine reference docs exist (engine not yet configured), show a short note:
"No engine configured yet — skipping technical feasibility check. Run
/setup-enginebefore moving to architecture if you haven't already."
Step 4 — Ask before proceeding:
Use AskUserQuestion:
Use AskUserQuestion:
Once the user confirms, immediately create the GDD file with empty section headers. This ensures incremental writes have a target.
Use the template structure from .claude/docs/templates/game-design-document.md:
# [System Name]
> **Status**: In Design
> **Author**: [user + agents]
> **Last Updated**: [today's date]
> **Implements Pillar**: [from context]
## Overview
[To be designed]
## Player Fantasy
[To be designed]
## Detailed Design
### Core Rules
[To be designed]
### States and Transitions
[To be designed]
### Interactions with Other Systems
[To be designed]
## Formulas
[To be designed]
## Edge Cases
[To be designed]
## Dependencies
[To be designed]
## Tuning Knobs
[To be designed]
## Visual/Audio Requirements
[To be designed]
## UI Requirements
[To be designed]
## Acceptance Criteria
[To be designed]
## Open Questions
[To be designed]
Ask: "May I create the skeleton file at design/gdd/[system-name].md?"
If the user declines: Stop with the following message:
"Verdict: BLOCKED — skeleton creation declined. The design session cannot proceed without the skeleton file, as all subsequent phases use it as the base. Re-run
/design-system [system]when ready to create the file." Do not proceed to Section A.
After writing, update production/session-state/active.md:
File content:
Walk through each section in order. For each section, follow this cycle:
Context -> Questions -> Options -> Decision -> Draft -> Approval -> Write
Context: State what this section needs to contain, and surface any relevant decisions from dependency GDDs that constrain it.
Questions: Ask clarifying questions specific to this section. Use
AskUserQuestion for constrained questions, conversational text for open-ended
exploration.
Options: Where the section involves design choices (not just documentation),
present 2-4 approaches with pros/cons. Explain reasoning in conversation text,
then use AskUserQuestion to capture the decision.
Decision: User picks an approach or provides custom direction.
Draft: Write the section content in conversation text for review. Flag any provisional assumptions about undesigned dependencies.
Approval: Immediately after the draft — in the SAME response — use
AskUserQuestion. NEVER use plain text. NEVER skip this step.
[A] Approve — write it to file / [B] Make changes — describe what to fix / [C] Start overThe draft and the approval widget MUST appear together in one response. If the draft appears without the widget, the user is left at a blank prompt with no path forward — this is a protocol violation.
Write: Use the Edit tool to replace the placeholder with the approved content.
CRITICAL: Always include the section heading in the old_string to ensure
uniqueness — never match [To be designed] alone, as multiple sections use the
same placeholder and the Edit tool requires a unique match. Use this pattern:
old_string: "## [Section Name]\n\n[To be designed]"
new_string: "## [Section Name]\n\n[approved content]"
Confirm the write.
Registry conflict check (Sections C and D only — Detailed Design and Formulas): After writing, scan the section content for entity names, item names, formula names, and numeric constants that appear in the registry. For each match:
"Registry conflict: [name] is registered in [source GDD] as [registry_value]. This section just wrote [new_value]. Which is correct?"
After writing each section, update production/session-state/active.md with the
completed section name. Use Glob to check if the file exists — use Write to create
it if absent, Edit to update it if present.
Each section has unique design considerations and may benefit from specialist agents:
Goal: One paragraph a stranger could read and understand.
Derive recommended options before building the widget: Read the system's category and layer from the systems index (already in context from Phase 2), then determine the recommended option for each tab:
[A] recommended. Player-facing categories (Combat, UI, Dialogue, Character, Animation, Visual Effects, Audio) → [C] Both recommended.docs/architecture/adr-*.md and grep for the system name in the GDD Requirements section of any ADR. If a matching ADR is found → [A] Yes — cite the ADR recommended. If none found → [B] No recommended.[B] No recommended. All other categories → [A] Yes recommended.Append (Recommended) to the appropriate option text in each tab.
Framing questions (ask BEFORE drafting): Use AskUserQuestion with a multi-tab widget:
[A] As a data/infrastructure layer (technical framing) / [B] Through its player-facing effect (design framing) / [C] Both — describe the data layer and its player impact[A] Yes — cite the ADR for implementation details / [B] No — keep the GDD at pure design level[A] Yes — players feel it directly / [B] No — pure infrastructure, players feel what it enablesUse the user's answers to shape the draft. Do NOT answer these questions yourself and auto-draft.
Questions to ask:
Cross-reference: Check that the description aligns with how the systems index describes it. Flag discrepancies.
Design vs. implementation boundary: Overview questions must stay at the behavior
level — what the system does, not how it is built. If implementation questions
arise during the Overview (e.g., "Should this use an Autoload singleton or a signal
bus?"), note them as "→ becomes an ADR" and move on. Implementation patterns belong
in /architecture-decision, not the GDD. The GDD describes behavior; the ADR
describes the technical approach used to achieve it.
Goal: The emotional target — what the player should feel.
Derive recommended option before building the widget: Read the system's category and layer from Phase 2 context:
[A] Direct recommended[B] Indirect recommended[C] Both recommendedAppend (Recommended) to the appropriate option text.
Framing question (ask BEFORE drafting): Use AskUserQuestion:
[A] Direct — player actively uses or feels this system / [B] Indirect — player experiences the effects, not the system / [C] Both — has a direct interaction layer and infrastructure beneath itUse the answer to frame the Player Fantasy section appropriately. Do NOT assume the answer.
Questions to ask:
Cross-reference: Must align with the game pillars. If the system serves a pillar, quote the relevant pillar text.
Review mode check (apply before spawning):
solo → skip this agent spawn. Draft the section without the specialist. Add a note: "creative-director not consulted — Solo mode. Review manually before production."lean → skip unless this is a section with HIGH implementation risk (Sections D and H only). For other sections, draft without the agent.full → spawn as described below.Agent delegation (MANDATORY): After the framing answer is given but before drafting,
spawn creative-director via Task:
Do NOT draft Section B without first consulting creative-director. The framing
answer tells us what kind of fantasy it is; the creative-director shapes how it's
described — tone, language, the specific player moment to anchor to.
Goal: Unambiguous specification a programmer could implement without questions.
This is usually the largest section. Break it into sub-sections:
Questions to ask:
Review mode check (apply before spawning):
solo → skip this agent spawn. Draft the section without the specialist. Add a note: "Specialist agents not consulted — Solo mode. Review manually before production."lean → skip unless this is a section with HIGH implementation risk (Sections D and H only). For other sections, draft without the agent.full → spawn as described below.Agent delegation (MANDATORY): Before drafting Section C, spawn specialist agents via Task in parallel:
AskUserQuestionDo NOT draft Section C without first consulting the appropriate specialists. A systems-designer reviewing rules and mechanics will catch design gaps the main session cannot.
Cross-reference: For each interaction listed, verify it matches what the dependency GDD specifies. If a dependency defines a value or formula and this system expects something different, flag the conflict.
Goal: Every mathematical formula, with variables defined, ranges specified, and edge cases noted.
Completion Steering — always begin each formula with this exact structure:
The [formula_name] formula is defined as:
`[formula_name] = [expression]`
**Variables:**
| Variable | Symbol | Type | Range | Description |
|----------|--------|------|-------|-------------|
| [name] | [sym] | float/int | [min–max] | [what it represents] |
**Output Range:** [min] to [max] under normal play; [behaviour at extremes]
**Example:** [worked example with real numbers]
Do NOT write [Formula TBD] or describe a formula in prose without the variable
table. A formula without defined variables cannot be implemented without guesswork.
Questions to ask:
Review mode check (apply before spawning):
solo → skip this agent spawn. Draft the section without the specialist. Add a note: "systems-designer not consulted — Solo mode. Review manually before production."lean → skip unless this is a section with HIGH implementation risk (Sections D and H only). For other sections, draft without the agent.full → spawn as described below.Agent delegation (MANDATORY): Before proposing any formulas or balance values, spawn specialist agents via Task in parallel:
systems-designer: provide Core Rules from Section C, tuning goals from user, balance context from dependency GDDs. Ask them to propose formulas with variable tables and output ranges.economy-designer: provide placement costs, upgrade cost intent, and progression goals. Ask them to validate cost curves and ratios.AskUserQuestionCross-reference: If a dependency GDD defines a formula whose output feeds into this system, reference it explicitly. Don't reinvent — connect.
Goal: Explicitly handle unusual situations so they don't become bugs.
Completion Steering — format each edge case as:
Example (adapt terminology to the game's domain):
Do NOT write vague entries like "handle appropriately" — each must name the exact condition and the exact resolution. An edge case without a resolution is an open design question, not a specification.
Questions to ask:
Review mode check (apply before spawning):
solo → skip this agent spawn. Draft the section without the specialist. Add a note: "systems-designer not consulted — Solo mode. Review manually before production."lean → skip unless this is a section with HIGH implementation risk (Sections D and H only). For other sections, draft without the agent.full → spawn as described below.Agent delegation (MANDATORY): Spawn systems-designer via Task before finalising edge cases. Provide: the completed Sections C and D, and ask them to identify edge cases from the formula and rule space that the main session may have missed. For narrative systems, also spawn narrative-director. Present their findings and ask the user which to include.
Cross-reference: Check edge cases against dependency GDDs. If a dependency defines a floor, cap, or resolution rule that this system could violate, flag it.
Goal: Map every system connection with direction and nature.
This section is partially pre-filled from the context gathering phase. Present the known dependencies from the systems index and ask:
Cross-reference: This section must be bidirectionally consistent. If this system lists "depends on Combat", then the Combat GDD should list "depended on by [this system]". Flag any one-directional dependencies for correction.
Goal: Every designer-adjustable value, with safe ranges and extreme behaviors.
Questions to ask:
Agent delegation: If formulas are complex, delegate to systems-designer
to derive tuning knobs from the formula variables.
Cross-reference: If a dependency GDD lists tuning knobs that affect this system, reference them here. Don't create duplicate knobs — point to the source of truth.
Goal: Testable conditions that prove the system works as designed.
Completion Steering — format each criterion as Given-When-Then:
Example (adapt terminology to the game's domain):
Include at least: one criterion per core rule from Section C, and one per formula from Section D. Do NOT write "the system works as designed" — every criterion must be independently verifiable by a QA tester without reading the GDD.
Review mode check (apply before spawning):
solo → skip this agent spawn. Draft the section without the specialist. Add a note: "qa-lead not consulted — Solo mode. Review manually before production."lean → skip unless this is a section with HIGH implementation risk (Sections D and H only). For other sections, draft without the agent.full → spawn as described below.Agent delegation (MANDATORY): Spawn qa-lead via Task before finalising acceptance criteria. Provide: the completed GDD sections C, D, E, and ask them to validate that the criteria are independently testable and cover all core rules and formulas. Surface any gaps or untestable criteria to the user.
Questions to ask:
Cross-reference: Include criteria that verify cross-system interactions work, not just this system in isolation.
These sections are included in the template. Visual/Audio is REQUIRED for visual system categories — not optional. Determine the requirement level before asking:
Visual/Audio is REQUIRED (mandatory — do not offer to skip) for these system categories:
For required systems: spawn art-director via Task before drafting this section. Provide: system name, game concept, game pillars, art bible sections 1–4 if they exist. Ask them to specify: (1) VFX and visual feedback requirements for this system's events, (2) any animation or visual style constraints, (3) which art bible principles most directly apply to this system. Present their output; do NOT leave this section as [To be designed] for visual systems.
For all other system categories (Foundation/Infrastructure, Economy, AI/pathfinding, Camera/input), offer the optional sections after the required sections:
Use AskUserQuestion:
For Visual/Audio (non-required systems): Coordinate with art-director and audio-director if detail is needed. Often a brief note suffices at the GDD stage.
Asset Spec Flag: After the Visual/Audio section is written with real content, output this notice: "📌 Asset Spec — Visual/Audio requirements are defined. After the art bible is approved, run
/asset-spec system:[system-name]to produce per-asset visual descriptions, dimensions, and generation prompts from this section."
For UI Requirements: Coordinate with ux-designer for complex UI systems.
After writing this section, check whether it contains real content (not just
[To be designed] or a note that this system has no UI). If it does have real
UI requirements, output this flag immediately:
📌 UX Flag — [System Name]: This system has UI requirements. In Phase 4 (Pre-Production), run
/ux-designto create a UX spec for each screen or HUD element this system contributes to before writing epics. Stories that reference UI should citedesign/ux/[screen].md, not the GDD directly.Note this in the systems index for this system if you update it.
For Open Questions: Capture anything that came up during design that wasn't fully resolved. Each question should have an owner and target resolution date.
After all sections are written:
Read back the complete GDD from file (not from conversation memory — the file is the source of truth). Verify:
Review mode check — apply before spawning CD-GDD-ALIGN:
solo → skip. Note: "CD-GDD-ALIGN skipped — Solo mode." Proceed to Step 5b.lean → skip (not a PHASE-GATE). Note: "CD-GDD-ALIGN skipped — Lean mode." Proceed to Step 5b.full → spawn as normal.Before finalizing the GDD, spawn creative-director via Task using gate CD-GDD-ALIGN (.claude/docs/director-gates.md).
Pass: completed GDD file path, game pillars (from design/gdd/game-concept.md or design/gdd/game-pillars.md), MDA aesthetics target.
Handle verdict per the standard rules in director-gates.md. After resolution, record the verdict in the GDD Status header:
> **Creative Director Review (CD-GDD-ALIGN)**: APPROVED [date] / CONCERNS (accepted) [date] / REVISED [date]
Scan the completed GDD for cross-system facts that should be registered:
For each candidate, check if it already exists in design/registry/entities.yaml:
Grep pattern=" - name: [candidate_name]" path="design/registry/entities.yaml"
Present a summary:
Registry candidates from this GDD:
NEW (not yet registered):
- [entity_name] [entity]: [attribute]=[value], [attribute]=[value]
- [item_name] [item]: [attribute]=[value], [attribute]=[value]
- [formula_name] [formula]: variables=[list], output=[min–max]
ALREADY REGISTERED (referenced_by will be updated):
- [constant_name] [constant]: value=[N] ← matches registry ✅
Ask: "May I update design/registry/entities.yaml with these [N] new entries
and update referenced_by for the existing entries?"
If yes: append new entries and update referenced_by arrays. Never modify
existing value / attribute fields without surfacing it as a conflict first.
Present a completion summary:
GDD Complete: [System Name]
- Sections written: [list]
- Provisional assumptions: [list any assumptions about undesigned dependencies]
- Cross-system conflicts found: [list or "none"]
To validate this GDD, open a fresh Claude Code session and run:
/design-review design/gdd/[system-name].mdNever run
/design-reviewin the same session as/design-system. The reviewing agent must be independent of the authoring context. Running it here would inherit the full design history, making independent critique impossible.
NEVER offer to run /design-review inline. Always direct the user to a fresh window.
After the GDD is complete (and optionally reviewed):
design/gdd/[system-name].mdAsk: "May I update the systems index at design/gdd/systems-index.md?"
Update production/session-state/active.md with:
Use AskUserQuestion:
/consistency-check — verify this GDD's values don't conflict with existing GDDs (recommended before designing the next system)"/gate-check" — if enough MVP systems are designedThis skill delegates to specialist agents for domain expertise. The main session orchestrates the overall flow; agents provide expert content.
| System Category | Primary Agent | Supporting Agent(s) |
|---|---|---|
| Foundation/Infrastructure (event bus, save/load, scene mgmt, service locator) | systems-designer | gameplay-programmer (feasibility), engine-programmer (engine integration) |
| Combat, damage, health | game-designer | systems-designer (formulas), ai-programmer (enemy AI), art-director (hit feedback visual direction, VFX intent) |
| Economy, loot, crafting | economy-designer | systems-designer (curves), game-designer (loops) |
| Progression, XP, skills | game-designer | systems-designer (curves), economy-designer (sinks) |
| Dialogue, quests, lore | game-designer | narrative-director (story), writer (content), art-director (character visual profiles, cinematic tone) |
| UI systems (HUD, menus) | game-designer | ux-designer (flows), ui-programmer (feasibility), art-director (visual style direction), technical-artist (render/shader constraints) |
| Audio systems | game-designer | audio-director (direction), sound-designer (specs) |
| AI, pathfinding, behavior | game-designer | ai-programmer (implementation), systems-designer (scoring) |
| Level/world systems | game-designer | level-designer (spatial), world-builder (lore) |
| Camera, input, controls | game-designer | ux-designer (feel), gameplay-programmer (feasibility) |
| Animation, character movement | game-designer | art-director (animation style, pose language), technical-artist (rig/blend constraints), gameplay-programmer (feel) |
| Visual effects, particles, shaders | game-designer | art-director (VFX visual direction), technical-artist (performance budget, shader complexity), systems-designer (trigger/state integration) |
| Character systems (stats, archetypes) | game-designer | art-director (character visual archetype), narrative-director (character arc alignment), systems-designer (stat formulas) |
When delegating via Task tool:
AskUserQuestionIf the session is interrupted (compaction, crash, new session):
production/session-state/active.md — it records the current system and
which sections are completedesign/gdd/[system-name].md — sections with real content are done;
sections with [To be designed] still need workThis is why incremental writing matters: every approved section survives any disruption.
This skill follows the collaborative design principle at every step:
Never auto-generate the full GDD and present it as a fait accompli. Never write a section without user approval. Never contradict an existing approved GDD without flagging the conflict. Always show where decisions come from (dependency GDDs, pillars, user choices).
This is a long-running skill. After writing each section, check if the status line shows context at or above 70%. If so, append this notice to the response:
Context is approaching the limit (≥70%). Your progress is saved — all approved sections are written to
design/gdd/[system-name].md. When you're ready to continue, open a fresh Claude Code session and run/design-system [system-name]— it will detect which sections are complete and resume from the next one.
/design-review design/gdd/[system-name].md in a fresh session to validate the completed GDD independently/consistency-check to verify this GDD's values don't conflict with other GDDs/map-systems next to move to the next highest-priority undesigned system/gate-check pre-production when all MVP GDDs are authored and reviewedBrownfield onboarding — audits existing project artifacts for template format compliance (not just existence), classifies gaps by impact, and produces a numbered migration plan. Run this when joining an in-progress project or upgrading from an older template version. Distinct from /project-stage-detect (which checks what exists) — this checks whether what exists will actually work with the template's skills.
Creates an Architecture Decision Record (ADR) documenting a significant technical decision, its context, alternatives considered, and consequences. Every major technical choice should have an ADR.
Validates completeness and consistency of the project architecture against all GDDs. Builds a traceability matrix mapping every GDD technical requirement to ADRs, identifies coverage gaps, detects cross-ADR conflicts, verifies engine compatibility consistency across all decisions, and produces a PASS/CONCERNS/FAIL verdict. The architecture equivalent of /design-review.
Guided, section-by-section Art Bible authoring. Creates the visual identity specification that gates all asset production. Run after /brainstorm is approved and before /map-systems or any GDD authoring begins.
Audits game assets for compliance with naming conventions, file size budgets, format standards, and pipeline requirements. Identifies orphaned assets, missing references, and standard violations.
Generate per-asset visual specifications and AI generation prompts from GDDs, level docs, or character profiles. Produces structured spec files and updates the master asset manifest. Run after art bible and GDD/level design are approved, before production begins.