添加brainstorm工作流与插件元数据

.agents/plugins/marketplace.json

@@ -0,0 +1,20 @@
+{
+  "name": "wxm",
+  "interface": {
+    "displayName": "wxm"
+  },
+  "plugins": [
+    {
+      "name": "codex-game-studios",
+      "source": {
+        "source": "local",
+        "path": "./"
+      },
+      "policy": {
+        "installation": "AVAILABLE",
+        "authentication": "ON_INSTALL"
+      },
+      "category": "Coding"
+    }
+  ]
+}

.codex-plugin/plugin.json

@@ -1,28 +1,43 @@
 {
   "name": "codex-game-studios",
   "version": "0.1.0",
-  "description": "[TODO: Brief plugin description]",
+  "description": "A Codex plugin for building game-production workflows step by step, starting with guided game concept brainstorming.",
   "author": {
-    "name": "[TODO: Author Name]",
-    "email": "[TODO: author@example.com]",
-    "url": "[TODO: https://example.com]"
+    "name": "wxm",
+    "email": "18854896936@163.com",
+    "url": "https://gitea.wuxianming.ac.cn/wxm/codex-game-studios"
   },
-  "homepage": "[TODO: https://example.com/codex-game-studios]",
+  "homepage": "https://gitea.wuxianming.ac.cn/wxm/codex-game-studios",
   "repository": "https://gitea.wuxianming.ac.cn/wxm/codex-game-studios",
-  "license": "[TODO: License identifier, for example MIT]",
-  "keywords": [],
+  "license": "MIT",
+  "keywords": [
+    "games",
+    "game-development",
+    "studio-workflow",
+    "brainstorm",
+    "gdd"
+  ],
+  "skills": "./skills/",
   "interface": {
     "displayName": "Codex Game Studios",
-    "shortDescription": "[TODO: Short description for compact views]",
-    "longDescription": "[TODO: Longer plugin description for details views]",
-    "developerName": "[TODO: Developer or team name]",
+    "shortDescription": "Game-production workflows for Codex",
+    "longDescription": "Build a Codex game-production plugin step by step. The current workflow starts with /brainstorm, a guided concept ideation process that turns a rough idea into a structured game concept document.",
+    "developerName": "wxm",
     "category": "Coding",
-    "capabilities": [],
-    "websiteURL": "[TODO: https://example.com]",
-    "privacyPolicyURL": "[TODO: https://example.com/privacy]",
-    "termsOfServiceURL": "[TODO: https://example.com/terms]",
-    "defaultPrompt": [],
+    "capabilities": [
+      "Interactive",
+      "Read",
+      "Write"
+    ],
+    "websiteURL": "https://gitea.wuxianming.ac.cn/wxm/codex-game-studios",
+    "privacyPolicyURL": "https://gitea.wuxianming.ac.cn/wxm/codex-game-studios",
+    "termsOfServiceURL": "https://gitea.wuxianming.ac.cn/wxm/codex-game-studios",
+    "defaultPrompt": [
+      "Run /brainstorm for my game project."
+    ],
     "brandColor": "#0F766E",
+    "composerIcon": "./assets/codex-game-studio.svg",
+    "logo": "./assets/codex-game-studio.svg",
     "screenshots": []
   }
 }

README.md

@@ -4,11 +4,15 @@ This repository is the minimal starting framework for a Codex plugin.
 
 Current state:
 
-- No skills
+- Skills: `/brainstorm`
+- Agents: `creative-director`, `art-director`, `technical-director`, `producer`
+- Assets: `codex-game-studio.svg`
+- References: `director-gates.md`, `templates/game-concept.md`
+- Standards: `design-docs.md`
+- Commands: `/brainstorm` wrapper document
+- Marketplace: `.agents/plugins/marketplace.json`
 - No hooks
-- No agents
 - No rules
-- No commands
 - No MCP servers
 - No app integrations
 

assets/codex-game-studio.svg

@@ -0,0 +1,7 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="512" height="512" viewBox="0 0 512 512">
+  <rect width="512" height="512" rx="96" fill="#111827"/>
+  <path d="M112 146h288v220H112z" fill="#0f766e"/>
+  <path d="M146 184h220v34H146zM146 246h118v34H146zM146 308h180v34H146z" fill="#f8fafc"/>
+  <circle cx="360" cy="280" r="36" fill="#facc15"/>
+  <path d="M360 238v84M318 280h84" stroke="#111827" stroke-width="18" stroke-linecap="round"/>
+</svg>

commands/brainstorm.md

@@ -0,0 +1,15 @@
+# /brainstorm
+
+Run the Brainstorm Codex Game Studio skill workflow.
+
+## Arguments
+
+Pass any text after `/brainstorm` as workflow input.
+
+## Workflow
+
+1. Use `../skills/brainstorm/SKILL.md` as the workflow entry point.
+2. Read `../skills/brainstorm/DETAILS.md` when present for the full procedure.
+3. Apply project guidance from `AGENTS.md` and relevant files in `../standards/` before changing project files.
+4. Use `../agents/<agent-name>.toml` when the skill delegates to a custom agent.
+5. Return decisions, changes, blockers, verification, and next steps.

references/studio-docs/director-gates.md

@@ -0,0 +1,806 @@
+# Director Gates — Shared Review Pattern
+
+This document defines the standard gate prompts for all director and lead reviews
+across every workflow stage. Skills reference gate IDs from this document instead
+of embedding full prompts inline — eliminating drift when prompts need updating.
+
+**Scope**: All 7 production stages (Concept → Release), all 3 Tier 1 directors,
+all key Tier 2 leads. Any skill, team orchestrator, or workflow may invoke these gates.
+
+---
+
+## How to Use This Document
+
+In any skill, replace an inline director prompt with a reference:
+
+```
+Spawn `creative-director` via subagent delegation using gate **CD-PILLARS** from
+`docs/game-studio/director-gates.md`.
+```
+
+Pass the context listed under that gate's **Context to pass** field, then handle
+the verdict using the **Verdict handling** rules below.
+
+---
+
+## Review Modes
+
+Review intensity controls whether director gates run. It can be set globally
+(persists across sessions) or overridden per skill run.
+
+**Global config**: `production/review-mode.txt` — one word: `full`, `lean`, or `solo`.
+Set once during `/start`. Edit the file directly to change it at any time.
+
+**Per-run override**: any gate-using skill accepts `--review [full|lean|solo]` as an
+argument. This overrides the global config for that run only.
+
+Examples:
+```
+/brainstorm space horror           → uses global mode
+/brainstorm space horror --review full   → forces full mode this run
+/architecture-decision --review solo     → skips all gates this run
+```
+
+| Mode | What runs | Best for |
+|------|-----------|----------|
+| `full` | All gates active — every workflow step reviewed | Teams, learning users, or when you want thorough director feedback at every step |
+| `lean` | PHASE-GATEs only (`/gate-check`) — per-skill gates skipped | **Default** — solo devs and small teams; directors review at milestones only |
+| `solo` | No director gates anywhere | Game jams, prototypes, maximum speed |
+
+**Check pattern — apply before every gate spawn:**
+
+```
+Before spawning gate [GATE-ID]:
+1. If skill was called with --review [mode], use that
+2. Else read production/review-mode.txt
+3. Else default to lean
+
+Apply the resolved mode:
+- solo → skip all gates. Note: "[GATE-ID] skipped — Solo mode"
+- lean → skip unless this is a PHASE-GATE (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE)
+         Note: "[GATE-ID] skipped — Lean mode"
+- full → spawn as normal
+```
+
+---
+
+## Invocation Pattern (copy into any skill)
+
+**MANDATORY: Resolve review mode before every gate spawn.** Never spawn a gate without checking. The resolved mode is determined once per skill run:
+1. If skill was called with `--review [mode]`, use that
+2. Else read `production/review-mode.txt`
+3. Else default to `lean`
+
+Apply the resolved mode:
+- `solo` → **skip all gates**. Note in output: `[GATE-ID] skipped — Solo mode`
+- `lean` → **skip unless this is a PHASE-GATE** (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE). Note: `[GATE-ID] skipped — Lean mode`
+- `full` → spawn as normal
+
+```
+# Apply mode check, then:
+Spawn `[agent-name]` via subagent delegation:
+- Gate: [GATE-ID] (see docs/game-studio/director-gates.md)
+- Context: [fields listed under that gate]
+- Await the verdict before proceeding.
+```
+
+For parallel spawning (multiple directors at the same gate point):
+
+```
+# Apply mode check for each gate first, then spawn all that survive:
+Spawn all [N] agents simultaneously via subagent delegation — issue all subagent requests before
+waiting for any result. Collect all verdicts before proceeding.
+```
+
+---
+
+## Standard Verdict Format
+
+All gates return one of three verdicts. Skills must handle all three:
+
+| Verdict | Meaning | Default action |
+|---------|---------|----------------|
+| **APPROVE / READY** | No issues. Proceed. | Continue the workflow |
+| **CONCERNS [list]** | Issues present but not blocking. | Surface to user via `ask the user in chat` — options: `Revise flagged items` / `Accept and proceed` / `Discuss further` |
+| **REJECT / NOT READY [blockers]** | Blocking issues. Do not proceed. | Surface blockers to user. Do not write files or advance stage until resolved. |
+
+**Escalation rule**: When multiple directors are spawned in parallel, apply the
+strictest verdict — one NOT READY overrides all READY verdicts.
+
+---
+
+## Recording Gate Outcomes
+
+After a gate resolves, record the verdict in the relevant document's status header:
+
+```markdown
+> **[Director] Review ([GATE-ID])**: APPROVED [date] / CONCERNS (accepted) [date] / REVISED [date]
+```
+
+For phase gates, record in `docs/architecture/architecture.md` or
+`production/session-state/active.md` as appropriate.
+
+---
+
+## Tier 1 — Creative Director Gates
+
+Agent: `creative-director` | Model tier: Opus | Domain: Vision, pillars, player experience
+
+---
+
+### CD-PILLARS — Pillar Stress Test
+
+**Trigger**: After game pillars and anti-pillars are defined (brainstorm Phase 4,
+or any time pillars are revised)
+
+**Context to pass**:
+- Full pillar set with names, definitions, and design tests
+- Anti-pillars list
+- Core fantasy statement
+- Unique hook ("Like X, AND ALSO Y")
+
+**Prompt**:
+> "Review these game pillars. Are they falsifiable — could a real design decision
+> actually fail this pillar? Do they create meaningful tension with each other? Do
+> they differentiate this game from its closest comparables? Would they help resolve
+> a design disagreement in practice, or are they too vague to be useful? Return
+> specific feedback for each pillar and an overall verdict: APPROVE (strong), CONCERNS
+> [list] (needs sharpening), or REJECT (weak — pillars do not carry weight)."
+
+**Verdicts**: APPROVE / CONCERNS / REJECT
+
+---
+
+### CD-GDD-ALIGN — GDD Pillar Alignment Check
+
+**Trigger**: After a system GDD is authored (design-system, quick-design, or any
+workflow that produces a GDD)
+
+**Context to pass**:
+- GDD file path
+- Game pillars (from `design/gdd/game-concept.md` or `design/gdd/game-pillars.md`)
+- MDA aesthetics target for this game
+- System's stated Player Fantasy section
+
+**Prompt**:
+> "Review this system GDD for pillar alignment. Does every section serve the stated
+> pillars? Are there mechanics or rules that contradict or weaken a pillar? Does
+> the Player Fantasy section match the game's core fantasy? Return APPROVE, CONCERNS
+> [specific sections with issues], or REJECT [pillar violations that must be
+> redesigned before this system is implementable]."
+
+**Verdicts**: APPROVE / CONCERNS / REJECT
+
+---
+
+### CD-SYSTEMS — Systems Decomposition Vision Check
+
+**Trigger**: After the systems index is written by `/map-systems` — validates the
+complete system set before GDD authoring begins
+
+**Context to pass**:
+- Systems index path (`design/gdd/systems-index.md`)
+- Game pillars and core fantasy (from `design/gdd/game-concept.md`)
+- Priority tier assignments (MVP / Vertical Slice / Alpha / Full Vision)
+- Any high-risk or bottleneck systems identified in the dependency map
+
+**Prompt**:
+> "Review this systems decomposition against the game's design pillars. Does the
+> full set of MVP-tier systems collectively deliver the core fantasy? Are there
+> systems whose mechanics don't serve any stated pillar — indicating they may be
+> scope creep? Are there pillar-critical player experiences that have no system
+> assigned to deliver them? Are any systems missing that the core loop requires?
+> Return APPROVE (systems serve the vision), CONCERNS [specific gaps or
+> misalignments with their pillar implications], or REJECT [fundamental gaps —
+> the decomposition misses critical design intent and must be revised before GDD
+> authoring begins]."
+
+**Verdicts**: APPROVE / CONCERNS / REJECT
+
+---
+
+### CD-NARRATIVE — Narrative Consistency Check
+
+**Trigger**: After narrative GDDs, lore documents, dialogue specs, or world-building
+documents are authored (team-narrative, design-system for story systems, writer
+deliverables)
+
+**Context to pass**:
+- Document file path(s)
+- Game pillars
+- Narrative direction brief or tone guide (if exists at `design/narrative/`)
+- Any existing lore that the new document references
+
+**Prompt**:
+> "Review this narrative content for consistency with the game's pillars and
+> established world rules. Does the tone match the game's established voice? Are
+> there contradictions with existing lore or world-building? Does the content serve
+> the player experience pillar? Return APPROVE, CONCERNS [specific inconsistencies],
+> or REJECT [contradictions that break world coherence]."
+
+**Verdicts**: APPROVE / CONCERNS / REJECT
+
+---
+
+### CD-PLAYTEST — Player Experience Validation
+
+**Trigger**: After playtest reports are generated (`/playtest-report`), or after
+any session that produces player feedback
+
+**Context to pass**:
+- Playtest report file path
+- Game pillars and core fantasy statement
+- The specific hypothesis being tested
+
+**Prompt**:
+> "Review this playtest report against the game's design pillars and core fantasy.
+> Is the player experience matching the intended fantasy? Are there systematic issues
+> that represent pillar drift — mechanics that feel fine in isolation but undermine
+> the intended experience? Return APPROVE (core fantasy is landing), CONCERNS [gaps
+> between intended and actual experience], or REJECT [core fantasy is not present —
+> redesign needed before further playtesting]."
+
+**Verdicts**: APPROVE / CONCERNS / REJECT
+
+---
+
+### CD-PHASE-GATE — Creative Readiness at Phase Transition
+
+**Trigger**: Always at `/gate-check` — spawn in parallel with TD-PHASE-GATE and PR-PHASE-GATE
+
+**Context to pass**:
+- Target phase name
+- List of all artifacts present (file paths)
+- Game pillars and core fantasy
+
+**Prompt**:
+> "Review the current project state for [target phase] gate readiness from a
+> creative direction perspective. Are the game pillars faithfully represented in
+> all design artifacts? Does the current state preserve the core fantasy? Are there
+> any design decisions across GDDs or architecture that compromise the intended
+> player experience? Return READY, CONCERNS [list], or NOT READY [blockers]."
+
+**Verdicts**: READY / CONCERNS / NOT READY
+
+---
+
+## Tier 1 — Technical Director Gates
+
+Agent: `technical-director` | Model tier: Opus | Domain: Architecture, engine risk, performance
+
+---
+
+### TD-SYSTEM-BOUNDARY — System Boundary Architecture Review
+
+**Trigger**: After `/map-systems` Phase 3 dependency mapping is agreed but before
+GDD authoring begins — validates that the system structure is architecturally
+sound before teams invest in writing GDDs against it
+
+**Context to pass**:
+- Systems index path (or the dependency map summary if index not yet written)
+- Layer assignments (Foundation / Core / Feature / Presentation / Polish)
+- The full dependency graph (what each system depends on)
+- Any bottleneck systems flagged (many dependents)
+- Any circular dependencies found and their proposed resolutions
+
+**Prompt**:
+> "Review this systems decomposition from an architectural perspective before GDD
+> authoring begins. Are the system boundaries clean — does each system own a
+> distinct concern with minimal overlap? Are there God Object risks (systems doing
+> too much)? Does the dependency ordering create implementation-sequencing problems?
+> Are there implicit shared-state problems in the proposed boundaries that will
+> cause tight coupling when implemented? Are any Foundation-layer systems actually
+> dependent on Feature-layer systems (inverted dependency)? Return APPROVE
+> (boundaries are architecturally sound — proceed to GDD authoring), CONCERNS
+> [specific boundary issues to address in the GDDs themselves], or REJECT
+> [fundamental boundary problems — the system structure will cause architectural
+> issues and must be restructured before any GDD is written]."
+
+**Verdicts**: APPROVE / CONCERNS / REJECT
+
+---
+
+### TD-FEASIBILITY — Technical Feasibility Assessment
+
+**Trigger**: After biggest technical risks are identified during scope/feasibility
+(brainstorm Phase 6, quick-design, or any early-stage concept with technical unknowns)
+
+**Context to pass**:
+- Concept's core loop description
+- Platform target
+- Engine choice (or "undecided")
+- List of identified technical risks
+
+**Prompt**:
+> "Review these technical risks for a [genre] game targeting [platform] using
+> [engine or 'undecided engine']. Flag any HIGH risk items that could invalidate
+> the concept as described, any risks that are engine-specific and should influence
+> the engine choice, and any risks that are commonly underestimated by solo
+> developers. Return VIABLE (risks are manageable), CONCERNS [list with mitigation
+> suggestions], or HIGH RISK [blockers that require concept or scope revision]."
+
+**Verdicts**: VIABLE / CONCERNS / HIGH RISK
+
+---
+
+### TD-ARCHITECTURE — Architecture Sign-Off
+
+**Trigger**: After the master architecture document is drafted (`/create-architecture`
+Phase 7), and after any major architecture revision
+
+**Context to pass**:
+- Architecture document path (`docs/architecture/architecture.md`)
+- Technical requirements baseline (TR-IDs and count)
+- ADR list with statuses
+- Engine knowledge gap inventory
+
+**Prompt**:
+> "Review this master architecture document for technical soundness. Check: (1) Is
+> every technical requirement from the baseline covered by an architectural decision?
+> (2) Are all HIGH risk engine domains explicitly addressed or flagged as open
+> questions? (3) Are the API boundaries clean, minimal, and implementable? (4) Are
+> Foundation layer ADR gaps resolved before implementation begins? Return APPROVE,
+> CONCERNS [list], or REJECT [blockers that must be resolved before coding starts]."
+
+**Verdicts**: APPROVE / CONCERNS / REJECT
+
+---
+
+### TD-ADR — Architecture Decision Review
+
+**Trigger**: After an individual ADR is authored (`/architecture-decision`), before
+it is marked Accepted
+
+**Context to pass**:
+- ADR file path
+- Engine version and knowledge gap risk level for the domain
+- Related ADRs (if any)
+
+**Prompt**:
+> "Review this Architecture Decision Record. Does it have a clear problem statement
+> and rationale? Are the rejected alternatives genuinely considered? Does the
+> Consequences section acknowledge the trade-offs honestly? Is the engine version
+> stamped? Are post-cutoff API risks flagged? Does it link to the GDD requirements
+> it covers? Return APPROVE, CONCERNS [specific gaps], or REJECT [the decision is
+> underspecified or makes unsound technical assumptions]."
+
+**Verdicts**: APPROVE / CONCERNS / REJECT
+
+---
+
+### TD-ENGINE-RISK — Engine Version Risk Review
+
+**Trigger**: When making architecture decisions that touch post-cutoff engine APIs,
+or before finalizing any engine-specific implementation approach
+
+**Context to pass**:
+- The specific API or feature being used
+- Engine version and LLM knowledge cutoff (from `docs/engine-reference/[engine]/VERSION.md`)
+- Relevant excerpt from breaking-changes or deprecated-apis docs
+
+**Prompt**:
+> "Review this engine API usage against the version reference. Is this API present
+> in [engine version]? Has its signature, behaviour, or namespace changed since the
+> LLM knowledge cutoff? Are there known deprecations or post-cutoff alternatives?
+> Return APPROVE (safe to use as described), CONCERNS [verify before implementing],
+> or REJECT [API has changed — provide corrected approach]."
+
+**Verdicts**: APPROVE / CONCERNS / REJECT
+
+---
+
+### TD-PHASE-GATE — Technical Readiness at Phase Transition
+
+**Trigger**: Always at `/gate-check` — spawn in parallel with CD-PHASE-GATE and PR-PHASE-GATE
+
+**Context to pass**:
+- Target phase name
+- Architecture document path (if exists)
+- Engine reference path
+- ADR list
+
+**Prompt**:
+> "Review the current project state for [target phase] gate readiness from a
+> technical direction perspective. Is the architecture sound for this phase? Are
+> all high-risk engine domains addressed? Are performance budgets realistic and
+> documented? Are Foundation-layer decisions complete enough to begin implementation?
+> Return READY, CONCERNS [list], or NOT READY [blockers]."
+
+**Verdicts**: READY / CONCERNS / NOT READY
+
+---
+
+## Tier 1 — Producer Gates
+
+Agent: `producer` | Model tier: Opus | Domain: Scope, timeline, dependencies, production risk
+
+---
+
+### PR-SCOPE — Scope and Timeline Validation
+
+**Trigger**: After scope tiers are defined (brainstorm Phase 6, quick-design, or
+any workflow that produces an MVP definition and timeline estimate)
+
+**Context to pass**:
+- Full vision scope description
+- MVP definition
+- Timeline estimate
+- Team size (solo / small team / etc.)
+- Scope tiers (what ships if time runs out)
+
+**Prompt**:
+> "Review this scope estimate. Is the MVP achievable in the stated timeline for
+> the stated team size? Are the scope tiers correctly ordered by risk — does each
+> tier deliver a shippable product if work stops there? What is the most likely
+> cut point under time pressure, and is it a graceful fallback or a broken product?
+> Return REALISTIC (scope matches capacity), OPTIMISTIC [specific adjustments
+> recommended], or UNREALISTIC [blockers — timeline or MVP must be revised]."
+
+**Verdicts**: REALISTIC / OPTIMISTIC / UNREALISTIC
+
+---
+
+### PR-SPRINT — Sprint Feasibility Review
+
+**Trigger**: Before finalising a sprint plan (`/sprint-plan`), and after any
+mid-sprint scope change
+
+**Context to pass**:
+- Proposed sprint story list (titles, estimates, dependencies)
+- Team capacity (hours available)
+- Current sprint backlog debt (if any)
+- Milestone constraints
+
+**Prompt**:
+> "Review this sprint plan for feasibility. Is the story load realistic for the
+> available capacity? Are stories correctly ordered by dependency? Are there hidden
+> dependencies between stories that could block the sprint mid-way? Are any stories
+> underestimated given their technical complexity? Return REALISTIC (plan is
+> achievable), CONCERNS [specific risks], or UNREALISTIC [sprint must be
+> descoped — identify which stories to defer]."
+
+**Verdicts**: REALISTIC / CONCERNS / UNREALISTIC
+
+---
+
+### PR-MILESTONE — Milestone Risk Assessment
+
+**Trigger**: At milestone review (`/milestone-review`), at mid-sprint retrospectives,
+or when a scope change is proposed that affects the milestone
+
+**Context to pass**:
+- Milestone definition and target date
+- Current completion percentage
+- Blocked stories count
+- Sprint velocity data (if available)
+
+**Prompt**:
+> "Review this milestone status. Based on current velocity and blocked story count,
+> will this milestone hit its target date? What are the top 3 production risks
+> between now and the milestone? Are there scope items that should be cut to protect
+> the milestone date vs. items that are non-negotiable? Return ON TRACK, AT RISK
+> [specific mitigations], or OFF TRACK [date must slip or scope must cut — provide
+> both options]."
+
+**Verdicts**: ON TRACK / AT RISK / OFF TRACK
+
+---
+
+### PR-EPIC — Epic Structure Feasibility Review
+
+**Trigger**: After epics are defined by `/create-epics`, before stories are
+broken out — validates the epic structure is producible before `/create-stories`
+is invoked
+
+**Context to pass**:
+- Epic definition file paths (all epics just created)
+- Epic index path (`production/epics/index.md`)
+- Milestone timeline and target dates
+- Team capacity (solo / small team / size)
+- Layer being epiced (Foundation / Core / Feature / etc.)
+
+**Prompt**:
+> "Review this epic structure for production feasibility before story breakdown
+> begins. Are the epic boundaries scoped appropriately — could each epic realistically
+> complete before a milestone deadline? Are epics correctly ordered by system
+> dependency — does any epic require another epic's output before it can start?
+> Are any epics underscoped (too small, should merge) or overscoped (too large,
+> should split into 2-3 focused epics)? Are the Foundation-layer epics scoped to
+> allow Core-layer epics to begin at the start of the next sprint after Foundation
+> completes? Return REALISTIC (epic structure is producible), CONCERNS [specific
+> structural adjustments before stories are written], or UNREALISTIC [epics must
+> be split, merged, or reordered — story breakdown cannot begin until resolved]."
+
+**Verdicts**: REALISTIC / CONCERNS / UNREALISTIC
+
+---
+
+### PR-PHASE-GATE — Production Readiness at Phase Transition
+
+**Trigger**: Always at `/gate-check` — spawn in parallel with CD-PHASE-GATE and TD-PHASE-GATE
+
+**Context to pass**:
+- Target phase name
+- Sprint and milestone artifacts present
+- Team size and capacity
+- Current blocked story count
+
+**Prompt**:
+> "Review the current project state for [target phase] gate readiness from a
+> production perspective. Is the scope realistic for the stated timeline and team
+> size? Are dependencies properly ordered so the team can actually execute in
+> sequence? Are there milestone or sprint risks that could derail the phase within
+> the first two sprints? Return READY, CONCERNS [list], or NOT READY [blockers]."
+
+**Verdicts**: READY / CONCERNS / NOT READY
+
+---
+
+## Tier 1 — Art Director Gates
+
+Agent: `art-director` | Model tier: Sonnet | Domain: Visual identity, art bible, visual production readiness
+
+---
+
+### AD-CONCEPT-VISUAL — Visual Identity Anchor
+
+**Trigger**: After game pillars are locked (brainstorm Phase 4), in parallel with CD-PILLARS
+
+**Context to pass**:
+- Game concept (elevator pitch, core fantasy, unique hook)
+- Full pillar set with names, definitions, and design tests
+- Target platform (if known)
+- Any reference games or visual touchstones mentioned by the user
+
+**Prompt**:
+> "Based on these game pillars and core concept, propose 2-3 distinct visual identity
+> directions. For each direction provide: (1) a one-line visual rule that could guide
+> all visual decisions (e.g., 'everything must move', 'beauty is in the decay'), (2)
+> mood and atmosphere targets, (3) shape language (sharp/rounded/organic/geometric
+> emphasis), (4) color philosophy (palette direction, what colors mean in this world).
+> Be specific — avoid generic descriptions. One direction should directly serve the
+> primary design pillar. Name each direction. Recommend which best serves the stated
+> pillars and explain why."
+
+**Verdicts**: CONCEPTS (multiple valid options — user selects) / STRONG (one direction clearly dominant) / CONCERNS (pillars don't provide enough direction to differentiate visual identity yet)
+
+---
+
+### AD-ART-BIBLE — Art Bible Sign-Off
+
+**Trigger**: After the art bible is drafted (`/art-bible`), before asset production begins
+
+**Context to pass**:
+- Art bible path (`design/art/art-bible.md`)
+- Game pillars and core fantasy
+- Platform and performance constraints (from `docs/game-studio/technical-preferences.md` if configured)
+- Visual identity anchor chosen during brainstorm (from `design/gdd/game-concept.md`)
+
+**Prompt**:
+> "Review this art bible for completeness and internal consistency. Does the color
+> system match the mood targets? Does the shape language follow from the visual
+> identity statement? Are the asset standards achievable within the platform
+> constraints? Does the character design direction give artists enough to work from
+> without over-specifying? Are there contradictions between sections? Would an
+> outsourcing team be able to produce assets from this document without additional
+> briefing? Return APPROVE (art bible is production-ready), CONCERNS [specific
+> sections needing clarification], or REJECT [fundamental inconsistencies that must
+> be resolved before asset production begins]."
+
+**Verdicts**: APPROVE / CONCERNS / REJECT
+
+---
+
+### AD-PHASE-GATE — Visual Readiness at Phase Transition
+
+**Trigger**: Always at `/gate-check` — spawn in parallel with CD-PHASE-GATE, TD-PHASE-GATE, and PR-PHASE-GATE
+
+**Context to pass**:
+- Target phase name
+- List of all art/visual artifacts present (file paths)
+- Visual identity anchor from `design/gdd/game-concept.md` (if present)
+- Art bible path if it exists (`design/art/art-bible.md`)
+
+**Prompt**:
+> "Review the current project state for [target phase] gate readiness from a visual
+> direction perspective. Is the visual identity established and documented at the
+> level this phase requires? Are the right visual artifacts in place? Would visual
+> teams be able to begin their work without visual direction gaps that cause costly
+> rework later? Are there visual decisions that are being deferred past their latest
+> responsible moment? Return READY, CONCERNS [specific visual direction gaps that
+> could cause production rework], or NOT READY [visual blockers that must exist
+> before this phase can succeed — specify what artifact is missing and why it
+> matters at this stage]."
+
+**Verdicts**: READY / CONCERNS / NOT READY
+
+---
+
+## Tier 2 — Lead Gates
+
+These gates are invoked by orchestration skills and senior skills when a domain
+specialist's feasibility sign-off is needed. Tier 2 leads use Sonnet (default).
+
+---
+
+### LP-FEASIBILITY — Lead Programmer Implementation Feasibility
+
+**Trigger**: After the master architecture document is written (`/create-architecture`
+Phase 7b), or when a new architectural pattern is proposed
+
+**Context to pass**:
+- Architecture document path
+- Technical requirements baseline summary
+- ADR list with statuses
+
+**Prompt**:
+> "Review this architecture for implementation feasibility. Flag: (a) any decisions
+> that would be difficult or impossible to implement with the stated engine and
+> language, (b) any missing interface definitions that programmers would need to
+> invent themselves, (c) any patterns that create avoidable technical debt or
+> that contradict standard [engine] idioms. Return FEASIBLE, CONCERNS [list], or
+> INFEASIBLE [blockers that make this architecture unimplementable as written]."
+
+**Verdicts**: FEASIBLE / CONCERNS / INFEASIBLE
+
+---
+
+### LP-CODE-REVIEW — Lead Programmer Code Review
+
+**Trigger**: After a dev story is implemented (`/dev-story`, `/story-done`), or
+as part of `/code-review`
+
+**Context to pass**:
+- Implementation file paths
+- Story file path (for acceptance criteria)
+- Relevant GDD section
+- ADR that governs this system
+
+**Prompt**:
+> "Review this implementation against the story acceptance criteria and governing
+> ADR. Does the code match the architecture boundary definitions? Are there
+> violations of the coding standards or forbidden patterns? Is the public API
+> testable and documented? Are there any correctness issues against the GDD rules?
+> Return APPROVE, CONCERNS [specific issues], or REJECT [must be revised before merge]."
+
+**Verdicts**: APPROVE / CONCERNS / REJECT
+
+---
+
+### QL-STORY-READY — QA Lead Story Readiness Check
+
+**Trigger**: Before a story is accepted into a sprint — invoked by `/create-stories`,
+`/story-readiness`, and `/sprint-plan` during story selection
+
+**Context to pass**:
+- Story file path
+- Story type (Logic / Integration / Visual/Feel / UI / Config/Data)
+- Acceptance criteria list (verbatim from the story)
+- The GDD requirement (TR-ID and text) the story covers
+
+**Prompt**:
+> "Review this story's acceptance criteria for testability before it enters the
+> sprint. Are all criteria specific enough that a developer would know unambiguously
+> when they are done? For Logic-type stories: can every criterion be verified with
+> an automated test? For Integration stories: is each criterion observable in a
+> controlled test environment? Flag criteria that are too vague to implement
+> against, and flag criteria that require a full game build to test (mark these
+> DEFERRED, not BLOCKED). Return ADEQUATE (criteria are implementable as written),
+> GAPS [specific criteria needing refinement], or INADEQUATE [criteria are too
+> vague — story must be revised before sprint inclusion]."
+
+**Verdicts**: ADEQUATE / GAPS / INADEQUATE
+
+---
+
+### QL-TEST-COVERAGE — QA Lead Test Coverage Review
+
+**Trigger**: After implementation stories are complete, before marking an epic
+done, or at `/gate-check` Production → Polish
+
+**Context to pass**:
+- List of implemented stories with story types (Logic / Integration / Visual / UI / Config)
+- Test file paths in `tests/`
+- GDD acceptance criteria for the system
+
+**Prompt**:
+> "Review the test coverage for these implementation stories. Are all Logic stories
+> covered by passing unit tests? Are Integration stories covered by integration
+> tests or documented playtests? Are the GDD acceptance criteria each mapped to at
+> least one test? Are there untested edge cases from the GDD Edge Cases section?
+> Return ADEQUATE (coverage meets standards), GAPS [specific missing tests], or
+> INADEQUATE [critical logic is untested — do not advance]."
+
+**Verdicts**: ADEQUATE / GAPS / INADEQUATE
+
+---
+
+### ND-CONSISTENCY — Narrative Director Consistency Check
+
+**Trigger**: After writer deliverables (dialogue, lore, item descriptions) are
+authored, or when a design decision has narrative implications
+
+**Context to pass**:
+- Document or content file path(s)
+- Narrative bible or tone guide path (if exists)
+- Relevant world-building rules
+- Character or faction profiles affected
+
+**Prompt**:
+> "Review this narrative content for internal consistency and adherence to
+> established world rules. Are character voices consistent with their established
+> profiles? Does the lore contradict any established facts? Is the tone consistent
+> with the game's narrative direction? Return APPROVE, CONCERNS [specific
+> inconsistencies to fix], or REJECT [contradictions that break the narrative
+> foundation]."
+
+**Verdicts**: APPROVE / CONCERNS / REJECT
+
+---
+
+### AD-VISUAL — Art Director Visual Consistency Review
+
+**Trigger**: After art direction decisions are made, when new asset types are
+introduced, or when a tech art decision affects visual style
+
+**Context to pass**:
+- Art bible path (if exists at `design/art/art-bible.md`)
+- The specific asset type, style decision, or visual direction being reviewed
+- Reference images or style descriptions
+- Platform and performance constraints
+
+**Prompt**:
+> "Review this visual direction decision for consistency with the established art
+> style and production constraints. Does it match the art bible? Is it achievable
+> within the platform's performance budget? Are there asset pipeline implications
+> that create technical risk? Return APPROVE, CONCERNS [specific adjustments], or
+> REJECT [style violation or production risk that must be resolved first]."
+
+**Verdicts**: APPROVE / CONCERNS / REJECT
+
+---
+
+## Parallel Gate Protocol
+
+When a workflow requires multiple directors at the same checkpoint (most common
+at `/gate-check`), spawn all agents simultaneously:
+
+```
+Spawn in parallel (issue all subagent requests before waiting for any result):
+1. creative-director  → gate CD-PHASE-GATE
+2. technical-director → gate TD-PHASE-GATE
+3. producer           → gate PR-PHASE-GATE
+4. art-director       → gate AD-PHASE-GATE
+
+Collect all four verdicts, then apply escalation rules:
+- Any NOT READY / REJECT → overall verdict minimum FAIL
+- Any CONCERNS → overall verdict minimum CONCERNS
+- All READY / APPROVE → eligible for PASS (still subject to artifact checks)
+```
+
+---
+
+## Adding New Gates
+
+When a new gate is needed for a new skill or workflow:
+
+1. Assign a gate ID: `[DIRECTOR-PREFIX]-[DESCRIPTIVE-SLUG]`
+   - Prefixes: `CD-` `TD-` `PR-` `LP-` `QL-` `ND-` `AD-`
+   - Add new prefixes for new agents: `audio-director` → `AU-`, `ux-designer` → `UX-`
+2. Add the gate under the appropriate director section with all five fields:
+   Trigger, Context to pass, Prompt, Verdicts, and any special handling notes
+3. Reference it in skills by ID only — never copy the prompt text into the skill
+
+---
+
+## Gate Coverage by Stage
+
+| Stage | Required Gates | Optional Gates |
+|-------|---------------|----------------|
+| **Concept** | CD-PILLARS, AD-CONCEPT-VISUAL | TD-FEASIBILITY, PR-SCOPE |
+| **Systems Design** | TD-SYSTEM-BOUNDARY, CD-SYSTEMS, PR-SCOPE, CD-GDD-ALIGN (per GDD) | ND-CONSISTENCY, AD-VISUAL |
+| **Technical Setup** | TD-ARCHITECTURE, TD-ADR (per ADR), LP-FEASIBILITY, AD-ART-BIBLE | TD-ENGINE-RISK |
+| **Pre-Production** | PR-EPIC, QL-STORY-READY (per story), PR-SPRINT, all four PHASE-GATEs (via gate-check) | CD-PLAYTEST |
+| **Production** | LP-CODE-REVIEW (per story), QL-STORY-READY, PR-SPRINT (per sprint), QL-TEST-COVERAGE (per sprint close-out) | PR-MILESTONE, AD-VISUAL |
+| **Polish** | QL-TEST-COVERAGE, CD-PLAYTEST, PR-MILESTONE | AD-VISUAL |
+| **Release** | All four PHASE-GATEs (via gate-check) | QL-TEST-COVERAGE |

references/studio-docs/templates/game-concept.md

@@ -0,0 +1,317 @@
+# Game Concept: [Working Title]
+
+*Created: [Date]*
+*Status: [Draft / Under Review / Approved]*
+
+---
+
+## Elevator Pitch
+
+> [1-2 sentences that capture the entire game. Should be compelling enough to
+> make someone want to hear more. Format: "It's a [genre] where you [core
+> action] in a [setting] to [goal]."
+>
+> Test: Can someone who has never heard of this game understand what they'd
+> be doing in 10 seconds? If not, simplify.]
+
+---
+
+## Core Identity
+
+| Aspect | Detail |
+| ---- | ---- |
+| **Genre** | [Primary genre + subgenre(s)] |
+| **Platform** | [PC / Console / Mobile / Cross-platform] |
+| **Target Audience** | [See Player Profile section below] |
+| **Player Count** | [Single-player / Co-op / Multiplayer / MMO] |
+| **Session Length** | [Typical play session: 10 min / 30 min / 1 hr / 2+ hr] |
+| **Monetization** | [Premium / F2P / Subscription / none yet] |
+| **Estimated Scope** | [Small (1-3 months) / Medium (3-9 months) / Large (9+ months)] |
+| **Comparable Titles** | [2-3 existing games in the same space] |
+
+---
+
+## Core Fantasy
+
+[What power, experience, or feeling does the player get from this game?
+What can they do here that they can't do anywhere else?
+
+The core fantasy is the emotional promise. It's not a feature list — it's the
+answer to "why would someone choose THIS game over anything else they could
+be doing?"
+
+Examples of strong core fantasies:
+- "You are a lone survivor building a new life in a hostile wilderness" (survival)
+- "You command a civilization across millennia" (strategy)
+- "You explore a vast, beautiful world at your own pace" (open world)
+- "You master intricate combat and overcome impossible odds" (soulslike)]
+
+---
+
+## Unique Hook
+
+[What makes this game different from everything else in its genre? This is
+the single most important differentiator.
+
+A strong hook passes the "and also" test: "It's like [comparable game],
+AND ALSO [unique thing]." If the "and also" doesn't spark curiosity, the
+hook needs work.
+
+The hook should be:
+- Explainable in one sentence
+- Genuinely novel (not just a combination of existing features)
+- Connected to the core fantasy (not a gimmick bolted on)
+- Something that affects gameplay, not just aesthetics]
+
+---
+
+## Player Experience Analysis (MDA Framework)
+
+The MDA (Mechanics-Dynamics-Aesthetics) framework ensures we design from the
+player's emotional experience backward to the systems that create it.
+
+### Target Aesthetics (What the player FEELS)
+Rank the following aesthetic goals for this game (1 = primary, mark N/A if not
+relevant). These come from the MDA framework's 8 aesthetic categories:
+
+| Aesthetic | Priority | How We Deliver It |
+| ---- | ---- | ---- |
+| **Sensation** (sensory pleasure) | [1-8 or N/A] | [Visual beauty, audio design, haptics] |
+| **Fantasy** (make-believe, role-playing) | [Priority] | [World, characters, player identity] |
+| **Narrative** (drama, story arc) | [Priority] | [Plot structure, player-driven stories] |
+| **Challenge** (obstacle course, mastery) | [Priority] | [Difficulty curve, skill ceiling] |
+| **Fellowship** (social connection) | [Priority] | [Co-op, guilds, shared experiences] |
+| **Discovery** (exploration, secrets) | [Priority] | [Hidden areas, emergent systems, lore] |
+| **Expression** (self-expression, creativity) | [Priority] | [Build variety, cosmetics, creation tools] |
+| **Submission** (relaxation, comfort zone) | [Priority] | [Low-stress loops, ambient gameplay] |
+
+### Key Dynamics (Emergent player behaviors)
+[What behaviors do we WANT to emerge from our mechanics? What should players
+naturally start doing without being told?
+
+Example: "Players will experiment with ability combinations to find synergies"
+Example: "Players will share discoveries with the community"]
+
+### Core Mechanics (Systems we build)
+[What are the 3-5 mechanical systems that generate the dynamics and aesthetics
+above? These are the rules, verbs, and systems we actually implement.]
+
+1. [Mechanic 1 — e.g., "Real-time combat with stamina management"]
+2. [Mechanic 2 — e.g., "Procedurally generated dungeons with hand-crafted rooms"]
+3. [Mechanic 3 — e.g., "Crafting system with discoverable recipes"]
+
+---
+
+## Player Motivation Profile
+
+Understanding WHY players play helps us make every design decision. Based on
+Self-Determination Theory (SDT) and the Player Experience of Need Satisfaction
+(PENS) model.
+
+### Primary Psychological Needs Served
+
+| Need | How This Game Satisfies It | Strength |
+| ---- | ---- | ---- |
+| **Autonomy** (freedom, meaningful choice) | [How does the player feel in control?] | [Core / Supporting / Minimal] |
+| **Competence** (mastery, skill growth) | [How does the player feel skilled?] | [Core / Supporting / Minimal] |
+| **Relatedness** (connection, belonging) | [How does the player feel connected?] | [Core / Supporting / Minimal] |
+
+### Player Type Appeal (Bartle Taxonomy)
+
+Which player types does this game primarily serve?
+
+- [ ] **Achievers** (goal completion, collection, progression) — How: [...]
+- [ ] **Explorers** (discovery, understanding systems, finding secrets) — How: [...]
+- [ ] **Socializers** (relationships, cooperation, community) — How: [...]
+- [ ] **Killers/Competitors** (domination, PvP, leaderboards) — How: [...]
+
+### Flow State Design
+
+Flow occurs when challenge matches skill. How does this game maintain flow?
+
+- **Onboarding curve**: [How do the first 10 minutes teach the player?]
+- **Difficulty scaling**: [How does challenge grow with player skill?]
+- **Feedback clarity**: [How does the player know they're improving?]
+- **Recovery from failure**: [How quickly can they try again? Is failure punishing or educational?]
+
+---
+
+## Core Loop
+
+### Moment-to-Moment (30 seconds)
+[What is the player physically doing most of the time? The most basic, repeated
+action. This MUST be intrinsically satisfying — if the 30-second loop isn't
+fun in isolation, no amount of progression will save the game.]
+
+### Short-Term (5-15 minutes)
+[What objective or cycle structures the moment-to-moment play? Encounters,
+puzzles, rounds, quests. This is where "one more turn" or "one more run"
+psychology lives.]
+
+### Session-Level (30-120 minutes)
+[What does a full play session look like? What does the player accomplish?
+This should end with a natural stopping point AND a reason to come back.]
+
+### Long-Term Progression
+[How does the player grow over days/weeks? Character progression, unlocks,
+story advancement, mastery. What is the player working toward?]
+
+### Retention Hooks
+[What specifically brings the player back for their next session?]
+- **Curiosity**: [Unanswered questions, unexplored areas, locked content]
+- **Investment**: [Progress they don't want to lose, characters they care about]
+- **Social**: [Friends playing, guild obligations, shared goals]
+- **Mastery**: [Skills to improve, challenges to overcome, rankings to climb]
+
+---
+
+## Game Pillars
+
+Design pillars are non-negotiable principles that guide EVERY decision. When
+two design choices conflict, pillars break the tie. Keep to 3-5 pillars.
+
+Real AAA examples:
+- God of War: "Intense combat", "Father-son story", "World exploration"
+- Hades: "Fast fluid combat", "Narrative depth through repeated runs"
+- The Last of Us: "Story as essential", "AI partners build relationships", "Stealth encouraged"
+
+### Pillar 1: [Name]
+[One sentence defining this non-negotiable design principle.]
+
+*Design test*: [A concrete decision this pillar would resolve. "If we're
+debating between X and Y, this pillar says we choose __."]
+
+### Pillar 2: [Name]
+[Definition]
+
+*Design test*: [Decision it resolves]
+
+### Pillar 3: [Name]
+[Definition]
+
+*Design test*: [Decision it resolves]
+
+### Anti-Pillars (What This Game Is NOT)
+
+Anti-pillars are equally important — they prevent scope creep and keep the
+vision focused. Every "no" protects the "yes."
+
+- **NOT [thing]**: [Why this is explicitly excluded and what it would compromise]
+- **NOT [thing]**: [Why]
+- **NOT [thing]**: [Why]
+
+---
+
+## Inspiration and References
+
+| Reference | What We Take From It | What We Do Differently | Why It Matters |
+| ---- | ---- | ---- | ---- |
+| [Game 1] | [Specific mechanic, feeling, or approach] | [Our twist] | [What it validates about our concept] |
+| [Game 2] | [What we learn] | [Our twist] | [Validation] |
+| [Game 3] | [What we learn] | [Our twist] | [Validation] |
+
+**Non-game inspirations**: [Films, books, music, art, real-world experiences
+that influence the tone, world, or feel. Great games often pull from outside
+the medium.]
+
+---
+
+## Target Player Profile
+
+[Be specific. "Gamers" is not a target audience.]
+
+| Attribute | Detail |
+| ---- | ---- |
+| **Age range** | [e.g., 18-35] |
+| **Gaming experience** | [Casual / Mid-core / Hardcore] |
+| **Time availability** | [e.g., "30-minute sessions on weeknights, longer on weekends"] |
+| **Platform preference** | [Where they play most] |
+| **Current games they play** | [2-3 specific titles] |
+| **What they're looking for** | [The unmet need this game fills] |
+| **What would turn them away** | [Dealbreakers for this audience] |
+
+---
+
+## Technical Considerations
+
+| Consideration | Assessment |
+| ---- | ---- |
+| **Recommended Engine** | [Godot / Unity / Unreal and why — consider scope, team expertise, platform targets] |
+| **Key Technical Challenges** | [What's technically hard about this game?] |
+| **Art Style** | [Pixel / 2D / 2.5D / 3D stylized / 3D realistic] |
+| **Art Pipeline Complexity** | [Low (asset store + modifications) / Medium (custom 2D) / High (custom 3D)] |
+| **Audio Needs** | [Minimal / Moderate / Music-heavy / Adaptive] |
+| **Networking** | [None / P2P / Client-Server / Dedicated Servers] |
+| **Content Volume** | [Estimate: X levels, Y items, Z hours of gameplay] |
+| **Procedural Systems** | [Any procedural generation? What scope?] |
+
+---
+
+## Risks and Open Questions
+
+### Design Risks
+[Things that could make the game unfun or uncompelling]
+- [Risk 1 — e.g., "Core loop may not sustain sessions > 30 minutes"]
+- [Risk 2 — e.g., "Player motivation unclear after main story ends"]
+
+### Technical Risks
+[Things that could be hard or impossible to build]
+- [Risk 1 — e.g., "Procedural generation quality is unproven"]
+- [Risk 2 — e.g., "Networking for 100+ players may require dedicated infrastructure"]
+
+### Market Risks
+[Things that could prevent commercial success]
+- [Risk 1 — e.g., "Genre is saturated with established competitors"]
+- [Risk 2 — e.g., "Target audience may be too niche for financial sustainability"]
+
+### Scope Risks
+[Things that could blow the timeline]
+- [Risk 1 — e.g., "Content volume exceeds team capacity"]
+- [Risk 2 — e.g., "Feature X depends on technology we haven't prototyped"]
+
+### Open Questions
+[Things that need prototyping or research before we can answer]
+- [Question 1 — and how we plan to answer it]
+- [Question 2 — and what prototype would resolve it]
+
+---
+
+## MVP Definition
+
+[The absolute minimum version that validates the core hypothesis. The MVP
+answers ONE question: "Is the core loop fun?"]
+
+**Core hypothesis**: [The single statement the MVP tests, e.g., "Players find
+the combat-crafting loop engaging for 30+ minute sessions"]
+
+**Required for MVP**:
+1. [Essential feature 1 — directly tests the hypothesis]
+2. [Essential feature 2]
+3. [Essential feature 3]
+
+**Explicitly NOT in MVP** (defer to later):
+- [Feature that's nice but doesn't test the hypothesis]
+- [Feature that adds scope without validating the core]
+
+### Scope Tiers (if budget/time shrinks)
+
+| Tier | Content | Features | Timeline |
+| ---- | ---- | ---- | ---- |
+| **MVP** | [Minimal] | [Core loop only] | [X weeks] |
+| **Vertical Slice** | [One complete area] | [Core + progression] | [X weeks] |
+| **Alpha** | [All areas, placeholder] | [All features, rough] | [X weeks] |
+| **Full Vision** | [Complete content] | [All features, polished] | [X weeks] |
+
+---
+
+## Next Steps
+
+- [ ] Get concept approval from creative-director
+- [ ] Fill in AGENTS.md technology stack based on engine choice (`/setup-engine`)
+- [ ] Create game pillars document (`/design-review` to validate)
+- [ ] **Prototype core idea** (`/prototype [core-mechanic]`) — before writing GDDs, validate the concept is worth designing
+- [ ] If prototype PROCEEDS: Decompose concept into systems (`/map-systems`)
+- [ ] Design each system (`/design-system [system-name]`) — use prototype learnings in Tuning Knobs and Formulas sections
+- [ ] Build vertical slice in Pre-Production (`/vertical-slice`) — validate full game loop before committing to Production
+- [ ] Validate core loop with playtest (`/playtest-report`)
+- [ ] Plan first milestone (`/sprint-plan new`)

skills/brainstorm/DETAILS.md

@@ -0,0 +1,352 @@
+# Brainstorm Workflow
+
+When this skill is invoked:
+
+1. **Parse the argument** for an optional genre/theme hint (e.g., `roguelike`,
+   `space survival`, `cozy farming`). If `open` or no argument, start from
+   scratch. Also 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 `../../references/studio-docs/director-gates.md` for the full check pattern.
+
+2. **Check for existing concept work**:
+   - Read `design/gdd/game-concept.md` if it exists (resume, don't restart)
+   - Read `design/gdd/game-pillars.md` if it exists (build on established pillars)
+
+3. **Run through ideation phases** interactively, asking the user questions at
+   each phase. Do NOT generate everything silently — the goal is **collaborative
+   exploration** where the AI acts as a creative facilitator, not a replacement
+   for the human's vision.
+
+   **Use `ask the user in chat`** at key decision points throughout brainstorming:
+   - Constrained taste questions (genre preferences, scope, team size)
+   - Concept selection ("Which 2-3 concepts resonate?") after presenting options
+   - Direction choices ("Develop further, explore more, or prototype?")
+   - Pillar ranking after concepts are refined
+   Write full creative analysis in conversation text first, then use
+   `ask the user in chat` to capture the decision with concise labels.
+
+   Professional studio brainstorming principles to follow:
+   - Withhold judgment — no idea is bad during exploration
+   - Encourage unusual ideas — outside-the-box thinking sparks better concepts
+   - Build on each other — "yes, and..." responses, not "but..."
+   - Use constraints as creative fuel — limitations often produce the best ideas
+   - Time-box each phase — keep momentum, don't over-deliberate early
+
+---
+
+### Phase 1: Creative Discovery
+
+Start by understanding the person, not the game. Ask these questions
+conversationally (not as a checklist):
+
+**Emotional anchors**:
+- What's a moment in a game that genuinely moved you, thrilled you, or made
+  you lose track of time? What specifically created that feeling?
+- Is there a fantasy or power trip you've always wanted in a game but never
+  quite found?
+
+**Taste profile**:
+- What 3 games have you spent the most time with? What kept you coming back?
+  *(Ask this as plain text — the user must be able to type specific game names freely.
+  Do NOT put this in an ask the user in chat with preset options.)*
+- Are there genres you love? Genres you avoid? Why?
+- Do you prefer games that challenge you, relax you, tell you stories,
+  or let you express yourself? *(Use `ask the user in chat` for this — constrained choice.)*
+
+**Practical constraints** (shape the sandbox before brainstorming).
+Bundle these into a single multi-tab `ask the user in chat` with these exact tab labels:
+- Tab "Experience" — "What kind of experience do you most want players to have?" (Challenge & Mastery / Story & Discovery / Expression & Creativity / Relaxation & Flow)
+- Tab "Timeline" — "What's your realistic development timeline?" (Weeks / Months / 1-2 years / Multi-year)
+- Tab "Dev level" — "Where are you in your dev journey?" (First game / Shipped before / Professional background)
+
+Use exactly these tab names — do not rename or duplicate them.
+
+**Synthesize** the answers into a **Creative Brief** — a 3-5 sentence
+summary of the person's emotional goals, taste profile, and constraints.
+Read the brief back and confirm it captures their intent.
+
+---
+
+### Phase 2: Concept Generation
+
+Using the creative brief as a foundation, generate **3 distinct concepts**
+that each take a different creative direction. Use these ideation techniques:
+
+**Technique 1: Verb-First Design**
+Start with the core player verb (build, fight, explore, solve, survive,
+create, manage, discover) and build outward from there. The verb IS the game.
+
+**Technique 2: Mashup Method**
+Combine two unexpected elements: [Genre A] + [Theme B]. The tension between
+the two creates the unique hook. (e.g., "farming sim + cosmic horror",
+"roguelike + dating sim", "city builder + real-time combat")
+
+**Technique 3: Experience-First Design (MDA Backward)**
+Start from the desired player emotion (aesthetic goal from MDA framework:
+sensation, fantasy, narrative, challenge, fellowship, discovery, expression,
+submission) and work backward to the dynamics and mechanics that produce it.
+
+For each concept, present:
+- **Working Title**
+- **Elevator Pitch** (1-2 sentences — must pass the "10-second test")
+- **Core Verb** (the single most common player action)
+- **Core Fantasy** (the emotional promise)
+- **Unique Hook** (passes the "and also" test: "Like X, AND ALSO Y")
+- **Primary MDA Aesthetic** (which emotion dominates?)
+- **Estimated Scope** (small / medium / large)
+- **Why It Could Work** (1 sentence on market/audience fit)
+- **Biggest Risk** (1 sentence on the hardest unanswered question)
+
+Present all three. Then use `ask the user in chat` to capture the selection.
+
+**CRITICAL**: This MUST be a plain list call — no tabs, no form fields. Use exactly this structure:
+
+```
+ask the user in chat(
+  prompt: "Which concept resonates with you? You can pick one, combine elements, or ask for fresh directions.",
+  options: [
+    "Concept 1 — [Title]",
+    "Concept 2 — [Title]",
+    "Concept 3 — [Title]",
+    "Combine elements across concepts",
+    "Generate fresh directions"
+  ]
+)
+```
+
+Do NOT use a `tabs` field here. The `tabs` form is for multi-field input only — using it here causes an "Invalid tool parameters" error. This is a plain `prompt` + `options` call.
+
+Never pressure toward a choice — let them sit with it.
+
+---
+
+### Phase 3: Core Loop Design
+
+For the chosen concept, use structured questioning to build the core loop.
+The core loop is the beating heart of the game — if it isn't fun in
+isolation, no amount of content or polish will save the game.
+
+**30-Second Loop** (moment-to-moment):
+
+Ask these as `ask the user in chat` calls — derive the options from the chosen concept, don't hardcode them:
+
+1. **Core action feel** — prompt: "What's the primary feel of the core action?" Generate 3-4 options that fit the concept's genre and tone, plus a free-text escape (`I'll describe it`).
+
+2. **Key design dimension** — identify the most important design variable for this specific concept (e.g., world reactivity, pacing, player agency) and ask about it. Generate options that match the concept. Always include a free-text escape.
+
+After capturing answers, analyze: Is this action intrinsically satisfying? What makes it feel good? (Audio feedback, visual juice, timing satisfaction, tactical depth?)
+
+**5-Minute Loop** (short-term goals):
+- What structures the moment-to-moment play into cycles?
+- Where does "one more turn" / "one more run" psychology kick in?
+- What choices does the player make at this level?
+
+**Session Loop** (30-120 minutes):
+- What does a complete session look like?
+- Where are the natural stopping points?
+- What's the "hook" that makes them think about the game when not playing?
+
+**Progression Loop** (days/weeks):
+- How does the player grow? (Power? Knowledge? Options? Story?)
+- What's the long-term goal? When is the game "done"?
+
+**Player Motivation Analysis** (based on Self-Determination Theory):
+- **Autonomy**: How much meaningful choice does the player have?
+- **Competence**: How does the player feel their skill growing?
+- **Relatedness**: How does the player feel connected (to characters,
+  other players, or the world)?
+
+---
+
+### Phase 4: Pillars and Boundaries
+
+Game pillars are used by real AAA studios (God of War, Hades, The Last of
+Us) to keep hundreds of team members making decisions that all point the
+same direction. Even for solo developers, pillars prevent scope creep and
+keep the vision sharp.
+
+Collaboratively define **3-5 pillars**:
+- Each pillar has a **name** and **one-sentence definition**
+- Each pillar has a **design test**: "If we're debating between X and Y,
+  this pillar says we choose __"
+- Pillars should feel like they create tension with each other — if all
+  pillars point the same way, they're not doing enough work
+
+Then define **3+ anti-pillars** (what this game is NOT):
+- Anti-pillars prevent the most common form of scope creep: "wouldn't it
+  be cool if..." features that don't serve the core vision
+- Frame as: "We will NOT do [thing] because it would compromise [pillar]"
+
+**Pillar confirmation**: After presenting the full pillar set, use `ask the user in chat`:
+- Prompt: "Do these pillars feel right for your game?"
+- Options: `[A] Lock these in` / `[B] Rename or reframe one` / `[C] Swap a pillar out` / `[D] Something else`
+
+If the user selects B, C, or D, make the revision, then use `ask the user in chat` again:
+- Prompt: "Pillars updated. Ready to lock these in?"
+- Options: `[A] Lock these in` / `[B] Revise another pillar` / `[C] Something else`
+
+Repeat until the user selects [A] Lock these in.
+
+**Review mode check** — apply before spawning CD-PILLARS and AD-CONCEPT-VISUAL:
+- `solo` → skip both. Note: "CD-PILLARS skipped — Solo mode. AD-CONCEPT-VISUAL skipped — Solo mode." Proceed to Phase 5.
+- `lean` → skip both (not PHASE-GATEs). Note: "CD-PILLARS skipped — Lean mode. AD-CONCEPT-VISUAL skipped — Lean mode." Proceed to Phase 5.
+- `full` → spawn as normal.
+
+**After pillars and anti-pillars are agreed, spawn BOTH `creative-director` AND `art-director` via Codex subagent delegation in parallel before moving to Phase 5. Issue both subagent requests simultaneously — do not wait for one before starting the other.**
+
+- **`creative-director`** — gate **CD-PILLARS** (`../../references/studio-docs/director-gates.md`)
+  Pass: full pillar set with design tests, anti-pillars, core fantasy, unique hook.
+
+- **`art-director`** — gate **AD-CONCEPT-VISUAL** (`../../references/studio-docs/director-gates.md`)
+  Pass: game concept elevator pitch, full pillar set with design tests, target platform (if known), any reference games or visual touchstones the user mentioned.
+
+Collect both verdicts, then present them together using a two-tab `ask the user in chat`:
+- Tab **"Pillars"**: present creative-director feedback. Options mirror the standard CD-PILLARS handling — `Lock in as-is` / `Revise [specific pillar]` / `Discuss further`.
+- Tab **"Visual anchor"**: present the art-director's 2-3 named visual direction options. Options: each named direction (one per option) + `Combine elements across directions` + `Describe my own direction`.
+
+The user's selected visual anchor (the named direction or their custom description) is stored as the **Visual Identity Anchor** — it will be written into the game-concept document and becomes the foundation of the art bible.
+
+If the creative-director returns CONCERNS or REJECT on pillars, resolve pillar issues before asking for the visual anchor selection — visual direction should flow from confirmed pillars.
+
+---
+
+### Phase 5: Player Type Validation
+
+Using the Bartle taxonomy and Quantic Foundry motivation model, validate
+who this game is actually for:
+
+- **Primary player type**: Who will LOVE this game? (Achievers, Explorers,
+  Socializers, Competitors, Creators, Storytellers)
+- **Secondary appeal**: Who else might enjoy it?
+- **Who is this NOT for**: Being clear about who won't like this game is as
+  important as knowing who will
+- **Market validation**: Are there successful games that serve a similar
+  player type? What can we learn from their audience size?
+
+---
+
+### Phase 6: Scope and Feasibility
+
+Ground the concept in reality:
+
+- **Target platform**: Use `ask the user in chat` — "What platforms are you targeting for this game?"
+  Options: `PC (Steam / Epic)` / `Mobile (iOS / Android)` / `Console` / `Web / Browser` / `Multiple platforms`
+  Record the answer — it directly shapes the engine recommendation and will be passed to `/setup-engine`.
+  Note platform implications if relevant (e.g., mobile means Unity is strongly preferred; console means Godot has limitations; web means Godot exports cleanly).
+
+- **Engine experience**: Use `ask the user in chat` — "Do you already have an engine you work in?"
+  Options: `Godot` / `Unity` / `Unreal Engine 5` / `No preference — help me decide`
+  - If they pick an engine → record it as their preference and move on. Do NOT second-guess it.
+  - If "No preference" → tell them: "Run `/setup-engine` after this session — it will walk you through the full decision based on your concept and platform target." Do not make a recommendation here.
+- **Art pipeline**: What's the art style and how labor-intensive is it?
+- **Content scope**: Estimate level/area count, item count, gameplay hours
+- **MVP definition**: What's the absolute minimum build that tests "is the
+  core loop fun?"
+- **Biggest risks**: Technical risks, design risks, market risks
+- **Scope tiers**: What's the full vision vs. what ships if time runs out?
+
+**Review mode check** — apply before spawning TD-FEASIBILITY:
+- `solo` → skip. Note: "TD-FEASIBILITY skipped — Solo mode." Proceed directly to scope tier definition.
+- `lean` → skip (not a PHASE-GATE). Note: "TD-FEASIBILITY skipped — Lean mode." Proceed directly to scope tier definition.
+- `full` → spawn as normal.
+
+**After identifying biggest technical risks, spawn `technical-director` via Codex subagent delegation using gate TD-FEASIBILITY (`../../references/studio-docs/director-gates.md`) before scope tiers are defined.**
+
+Pass: core loop description, platform target, engine choice (or "undecided"), list of identified technical risks.
+
+Present the assessment to the user. If HIGH RISK, offer to revisit scope before finalising. If CONCERNS, note them and continue.
+
+**Review mode check** — apply before spawning PR-SCOPE:
+- `solo` → skip. Note: "PR-SCOPE skipped — Solo mode." Proceed to document generation.
+- `lean` → skip (not a PHASE-GATE). Note: "PR-SCOPE skipped — Lean mode." Proceed to document generation.
+- `full` → spawn as normal.
+
+**After scope tiers are defined, spawn `producer` via Codex subagent delegation using gate PR-SCOPE (`../../references/studio-docs/director-gates.md`).**
+
+Pass: full vision scope, MVP definition, timeline estimate, team size.
+
+Present the assessment to the user. If UNREALISTIC, offer to adjust the MVP definition or scope tiers before writing the document.
+
+---
+
+4. **Generate the game concept document** using the template at
+   `../../references/studio-docs/templates/game-concept.md`. Fill in ALL sections from the
+   brainstorm conversation, including the MDA analysis, player motivation
+   profile, and flow state design sections.
+
+   **Include a Visual Identity Anchor section** in the game concept document with:
+   - The selected visual direction name
+   - The one-line visual rule
+   - The 2-3 supporting visual principles with their design tests
+   - The color philosophy summary
+
+   This section is the seed of the art bible — it captures the "everything must
+   move" decision before it can be forgotten between sessions.
+
+5. Use `ask the user in chat` for write approval:
+- Prompt: "Game concept is ready. May I write it to `design/gdd/game-concept.md`?"
+- Options: `[A] Yes — write it` / `[B] Not yet — revise a section first`
+
+If [B]: ask which section to revise using `ask the user in chat` with options: `Elevator Pitch` / `Core Fantasy & Unique Hook` / `Pillars` / `Core Loop` / `MVP Definition` / `Scope Tiers` / `Risks` / `Something else — I'll describe`
+
+After revising, show the updated section as a diff or clear before/after, then use `ask the user in chat` — "Ready to write the updated concept document?"
+Options: `[A] Yes — write it` / `[B] Revise another section`
+Repeat until the user selects [A].
+
+If yes, generate the document using the template at `../../references/studio-docs/templates/game-concept.md`, fill in ALL sections from the brainstorm conversation, and write the file, creating directories as needed.
+
+**Scope consistency rule**: The "Estimated Scope" field in the Core Identity table must match the full-vision timeline from the Scope Tiers section — not just say "Large (9+ months)". Write it as "Large (X–Y months, solo)" or "Large (X–Y months, team of N)" so the summary table is accurate.
+
+6. **Suggest next steps** (in this order — this is the professional studio
+   pre-production pipeline). List ALL steps — do not abbreviate or truncate:
+
+**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)."
+   3. "Use `/design-review design/gdd/game-concept.md` to validate concept completeness before going downstream"
+   4. "Discuss vision with the `creative-director` agent for pillar refinement"
+   5. "Decompose the concept into individual systems with `/map-systems` — maps dependencies, assigns priorities, and creates the systems index"
+   6. "Author per-system GDDs with `/design-system` — guided, section-by-section GDD writing for each system identified in step 5"
+   7. "Plan the technical architecture with `/create-architecture` — produces the master architecture blueprint and Required ADR list"
+   8. "Record key architectural decisions with `/architecture-decision (×N)` — write one ADR per decision in the Required ADR list from `/create-architecture`"
+   9. "Run `/architecture-review` — bootstraps the TR registry and Requirements Traceability Matrix from your GDDs and ADRs (required before the Pre-Production gate)"
+   10. "Validate readiness to advance with `/gate-check` — phase gate before committing to production"
+
+**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"
+   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"
+
+7. **Output a summary** with the chosen concept's elevator pitch, pillars,
+   primary player type, engine recommendation, biggest risk, and file path.
+
+Verdict: **COMPLETE** — game concept created and handed off for next steps.
+
+---
+
+## Context Window Awareness
+
+This is a multi-phase skill. If context reaches or exceeds 70% during any phase,
+append this notice to the current response before continuing:
+
+> **Context is approaching the limit (≥70%).** The game concept document is saved
+> to `design/gdd/game-concept.md`. Open a fresh Codex session to continue
+> if needed — progress is not lost.
+
+---
+
+## Recommended Next Steps
+
+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
+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
+6. `/architecture-review` — bootstrap TR registry and Requirements Traceability Matrix
+7. `/gate-check pre-production` — validate readiness before committing to production

skills/brainstorm/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: brainstorm
+description: "Use when you need the /brainstorm game-production workflow. Guided game concept ideation — from zero idea to a structured game concept document. Uses professional studio ideation techniques, player psychology frameworks, and structured creative exploration."
+---
+
+# Brainstorm
+
+Run the `/brainstorm` Codex Game Studio workflow.
+
+Before acting, read `DETAILS.md` for the full workflow. Apply project guidance from `AGENTS.md`, use `../../standards/` for path-specific standards, and use `../../agents/<agent-name>.toml` when the workflow delegates to a custom agent.

skills/brainstorm/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Brainstorm"
+  short_description: "Use when you need the /brainstorm game-production workflow. Guided game concept ideation — from zero idea to a structure"
+  default_prompt: "Run /brainstorm for my game project."

standards/design-docs.md

@@ -0,0 +1,18 @@
+---
+paths:
+  - "design/gdd/**"
+---
+
+# Design Document Rules
+
+- Every design document MUST contain these 8 sections: Overview, Player Fantasy, Detailed Rules, Formulas, Edge Cases, Dependencies, Tuning Knobs, Acceptance Criteria
+- Formulas must include variable definitions, expected value ranges, and example calculations
+- Edge cases must explicitly state what happens, not just "handle gracefully"
+- Dependencies must be bidirectional — if system A depends on B, B's doc must mention A
+- Tuning knobs must specify safe ranges and what gameplay aspect they affect
+- Acceptance criteria must be testable — a QA tester must be able to verify pass/fail
+- No hand-waving: "the system should feel good" is not a valid specification
+- Balance values must link to their source formula or rationale
+- Design documents MUST be written incrementally: create skeleton first, then fill
+  each section one at a time with user approval between sections. Write each
+  approved section to the file immediately to persist decisions and manage context