Align brainstorm workflow with Codex input schema

README.md

@@ -8,8 +8,7 @@ skills expose the runtime workflows directly. Do not use a global
 ## Current State
 
 - Skills:
-  - `$brainstorm` guides game concept ideation into `design/gdd/game-concept.md`
+  - `$brainstorm` guides game concept ideation into `design/gdd/game-concept.md`.
-    and `design/gdd/game-pillars.md`.
 - Runtime agents: `creative-director`, `art-director`, `technical-director`, `producer`
 - Runtime source: `runtime/agents/`
 - Project guide template: `project-template/AGENTS.md`
@@ -22,13 +21,9 @@ skills expose the runtime workflows directly. Do not use a global
 
 `production/review-mode.txt` controls review-gate intensity:
 
-- `full`: all key director / lead review gates call their custom agents.
+- `full`: all gates active — every workflow step reviewed.
-- `lean`: only PHASE-GATE review gates such as `/gate-check` call directors;
+- `lean`: PHASE-GATEs only (`/gate-check`) — per-skill gates skipped.
-  ordinary per-skill review gates are skipped.
+- `solo`: no director gates anywhere.
-- `solo`: all director review gates are skipped.
-
-This is not a global off switch for all custom agents. Future team workflows may
-still call specialist subagents as part of their core work.
 
 ## Runtime Setup
 

project-template/AGENTS.md

@@ -43,16 +43,12 @@ production/review-mode.txt
 
 Allowed values:
 
-- `full` — all key director / lead review gates call their custom agents.
+- `full` — all gates active; every workflow step is reviewed.
-- `lean` — only PHASE-GATE review gates such as `/gate-check` call directors;
+- `lean` — PHASE-GATEs only (`/gate-check`); per-skill gates are skipped.
-  ordinary per-skill review gates are skipped.
+- `solo` — no director gates anywhere.
-- `solo` — all director review gates are skipped.
 
 Default when the file is missing: `lean`.
 
-This is not a global switch for all custom-agent usage. Future team workflows
-may still call specialist subagents as part of their core work.
-
 ## Collaboration Protocol
 
 User-driven collaboration, not autonomous execution. Every workflow follows:
@@ -77,12 +73,12 @@ The current plugin build exposes only the migrated `/brainstorm` workflow.
 
 ```text
 design/gdd/game-concept.md
-design/gdd/game-pillars.md
 ```
 
-In default `lean` mode, `/brainstorm` writes the initial pillar document itself.
+Game pillars and anti-pillars are defined during `/brainstorm` and recorded
-In `full` mode, the `creative-director` review gate participates in creating or
+inside `design/gdd/game-concept.md`. A separate `design/gdd/game-pillars.md`
-updating the pillar document.
+may be created later from the template if the project needs a standalone
+pillar source of truth.
 
 ## Design Documents
 
@@ -95,7 +91,7 @@ docs/architecture/
 production/
 ```
 
-`design/gdd/game-concept.md`, `design/gdd/game-pillars.md`, and
+`design/gdd/game-concept.md`, optional `design/gdd/game-pillars.md`, and
 `design/gdd/systems-index.md` are top-level design documents. They are not
 per-system GDDs.
 

references/studio-docs/director-gates.md

@@ -4,9 +4,8 @@ This document defines the standard gate prompts for all director and lead review
 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 shared director
+**Scope**: All 7 production stages (Concept → Release), all 3 Tier 1 directors,
-custom agents, and all key Tier 2 leads. Any skill, team orchestrator, or
+all key Tier 2 leads. Any skill, team orchestrator, or workflow may invoke these gates.
-workflow may invoke these gates.
 
 ---
 
@@ -19,31 +18,15 @@ Spawn `creative-director` via Codex custom-agent delegation using gate
 **CD-PILLARS** from `references/studio-docs/director-gates.md`.
 ```
 
-The matching custom agent must already be installed in the target project at
+Pass the context listed under that gate's **Context to pass** field, then handle
-`.codex/agents/<agent-name>.toml`. The target project should also have a root
+the verdict using the **Verdict handling** rules below.
-`AGENTS.md` installed from `project-template/AGENTS.md`; this is the shared
-project guide used by Codex and bundled custom agents. The plugin source copies
-for agents live in `runtime/agents/`; run
-`python3 scripts/install_codex_runtime.py <target-project>` from the plugin root
-if the target project is missing the agents or root guide. Pass the context
-listed under that gate's **Context to pass** field, then handle the verdict
-using the **Verdict handling** rules below.
-
-Director names are Codex custom agent names. Do not recreate them by pasting
-profile text into a generic default agent.
 
 ---
 
 ## Review Modes
 
-Review intensity controls whether director and lead **review gates** run. It is
+Review intensity controls whether director gates run. It can be set globally
-not a global switch for all custom-agent or subagent usage: a future team
+(persists across sessions) or overridden per skill run.
-workflow may still call specialist agents as part of its core work. Apply
-review mode only to gate invocations such as `CD-PILLARS`, `TD-FEASIBILITY`,
-`PR-SCOPE`, and the `*-PHASE-GATE` checks.
-
-Review intensity 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.
@@ -55,14 +38,14 @@ Examples:
 ```
 /brainstorm space horror           → uses global mode
 /brainstorm space horror --review full   → forces full mode this run
-/architecture-decision --review solo     → skips review gates this run
+/architecture-decision --review solo     → skips all gates this run
 ```
 
 | Mode | What runs | Best for |
 |------|-----------|----------|
-| `full` | All key director / lead review gates call their custom agents | Teams, learning users, or when you want thorough director feedback at every step |
+| `full` | All gates active — every workflow step reviewed | Teams, learning users, or when you want thorough director feedback at every step |
-| `lean` | Only PHASE-GATE review gates such as `/gate-check` call directors; ordinary per-skill review gates are skipped | **Default** — solo devs and small teams; directors review at milestones only |
+| `lean` | PHASE-GATEs only (`/gate-check`) — per-skill gates skipped | **Default** — solo devs and small teams; directors review at milestones only |
-| `solo` | All director review gates are skipped | Game jams, prototypes, maximum speed |
+| `solo` | No director gates anywhere | Game jams, prototypes, maximum speed |
 
 **Check pattern — apply before every gate spawn:**
 
@@ -73,9 +56,8 @@ Before spawning gate [GATE-ID]:
 3. Else default to lean
 
 Apply the resolved mode:
-- solo → skip all director / lead review gates. Note: "[GATE-ID] skipped — Solo mode"
+- solo → skip all gates. Note: "[GATE-ID] skipped — Solo mode"
-- lean → skip ordinary per-skill review gates; only run PHASE-GATE checks
+- lean → skip unless this is a PHASE-GATE (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE)
-         (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE)
          Note: "[GATE-ID] skipped — Lean mode"
 - full → spawn as normal
 ```
@@ -90,20 +72,15 @@ Apply the resolved mode:
 3. Else default to `lean`
 
 Apply the resolved mode:
-- `full` → **spawn all key director / lead review gates** as described by the skill.
+- `solo` → **skip all gates**. Note in output: `[GATE-ID] skipped — Solo mode`
-- `lean` → **spawn only PHASE-GATE review gates** such as `/gate-check`
+- `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`
-  (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE). Skip ordinary
+- `full` → spawn as normal
-  per-skill review gates and note: `[GATE-ID] skipped — Lean mode`
-- `solo` → **skip all director review gates**. Note in output:
-  `[GATE-ID] skipped — Solo mode`
 
 ```
 # Apply mode check, then:
 Spawn `[agent-name]` via Codex custom-agent delegation:
 - Gate: [GATE-ID] (see references/studio-docs/director-gates.md)
-- Custom agent file: .codex/agents/[agent-name].toml in the target project
 - Context: [fields listed under that gate]
-- Codex fork_context: false unless full thread context is required
 - Await the verdict before proceeding.
 ```
 
@@ -111,9 +88,8 @@ 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] custom agents simultaneously via Codex subagent delegation. Issue
+Spawn all [N] agents simultaneously via Codex custom-agent delegation — issue all custom-agent requests before
-all subagent requests before waiting for any result. Collect all verdicts before
+waiting for any result. Collect all verdicts before proceeding.
-proceeding.
 ```
 
 ---
@@ -125,7 +101,7 @@ 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 a structured prompt when available, or ask directly in chat: `Revise flagged items` / `Accept and proceed` / `Discuss further` |
+| **CONCERNS [list]** | Issues present but not blocking. | Surface to user via Codex `request_user_input` — options: `Revise flagged` / `Accept` / `Discuss` |
 | **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
@@ -160,15 +136,8 @@ or any time pillars are revised)
 **Context to pass**:
 - Full pillar set with names, definitions, and design tests
 - Anti-pillars list
-- Pillar conflict priority
 - Core fantasy statement
 - Unique hook ("Like X, AND ALSO Y")
-- Required output document path for `/brainstorm`: `design/gdd/game-pillars.md`
-- Template to use when the document is created or updated:
-  `references/studio-docs/templates/game-pillars.md`
-- Existing `design/gdd/game-pillars.md` contents, if the file already exists
-- Orchestrator assessment: missing / present and current / present but stale /
-  present but incomplete
 
 **Prompt**:
 > "Review these game pillars. Are they falsifiable — could a real design decision
@@ -176,18 +145,7 @@ or any time pillars are revised)
 > 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).
+> [list] (needs sharpening), or REJECT (weak — pillars do not carry weight)."
-> When this gate is invoked from `/brainstorm` after the user has locked pillars,
-> ensure `design/gdd/game-pillars.md` exists as the brainstorm-stage pillar
-> source of truth. If it already exists and matches the locked pillars, review it
-> in place and avoid rewriting for churn. If it is missing, stale, or incomplete,
-> create or update it with `references/studio-docs/templates/game-pillars.md` as
-> the structure. The initial brainstorm version must capture core fantasy, unique
-> hook, target MDA aesthetics, 3-5 pillars, design tests, anti-pillars, conflict
-> priority, and validation status; deeper cross-department implications can be
-> marked TBD for later refinement. Begin the response with the required verdict
-> token, then state whether the pillar document is current, created, updated, or
-> blocked."
 
 **Verdicts**: APPROVE / CONCERNS / REJECT
 
@@ -661,9 +619,7 @@ Agent: `art-director` | Target custom agent file: `.codex/agents/art-director.to
 ## Tier 2 — Lead Gates
 
 These gates are invoked by orchestration skills and senior skills when a domain
-specialist's feasibility sign-off is needed. If a Tier 2 lead custom agent is
+specialist's feasibility sign-off is needed. Tier 2 leads use Sonnet (default).
-added later, invoke it with the same Codex custom-agent delegation pattern used
-for Tier 1 agents.
 
 ---
 
@@ -810,7 +766,7 @@ 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):
+Spawn in parallel (issue all custom-agent 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

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

@@ -1,247 +1,313 @@
 # Game Pillars: [Game Title]
 
 ## Document Status
-
 - **Version**: 1.0
 - **Last Updated**: [Date]
-- **Owner**: creative-director
+- **Approved By**: creative-director
-- **Status**: Draft / Under Review / Approved
+- **Status**: [Draft / Under Review / Approved]
-
-> **Creative Director Review (CD-PILLARS)**: [APPROVED date / CONCERNS accepted date / REVISED date]
 
 ---
 
-## Purpose
+## What Are Game Pillars?
 
-This document is the source of truth for the game's creative pillars. It is
+Pillars are the 3-5 non-negotiable principles that define this game's identity.
-created during `/brainstorm` once the user locks the pillars. The first version
+Every design, art, audio, narrative, and technical decision must serve at least
-can be lightweight; later workflows may deepen the cross-department implications
+one pillar. If a feature doesn't serve a pillar, it doesn't belong in the game.
-and validation details as the project matures.
 
-Pillars are the 3-5 non-negotiable principles that define the game's identity.
+**Why pillars matter**: In a typical development cycle, the team makes thousands
-Every design, art, audio, narrative, production, and technical decision should
+of small creative decisions. Pillars ensure all those decisions push in the same
-serve at least one pillar. If a feature does not serve a pillar, it probably
+direction, creating a coherent player experience rather than a collection of
-does not belong in the game.
+disconnected features.
+
+### What Makes a Good Pillar
+
+A good pillar is:
+- **Falsifiable**: "Fun gameplay" is not a pillar. "Combat rewards patience over
+  aggression" is — it makes a testable claim about design choices.
+- **Constraining**: If a pillar never forces you to say no to something, it's
+  too vague. Good pillars eliminate options.
+- **Cross-departmental**: A pillar that only constrains game design but says
+  nothing about art, audio, or narrative is incomplete. Real pillars shape
+  every discipline.
+- **Memorable**: The team should be able to recite the pillars from memory.
+  If they can't, the pillars are too numerous or too complex.
+
+### Real AAA Examples
+
+These studios publicly shared their game pillars, showing how concrete and
+specific effective pillars can be:
+
+| Game | Pillars | Why They Work |
+| ---- | ---- | ---- |
+| **God of War (2018)** | Visceral combat; Father-son emotional journey; Continuous camera (no cuts); Norse mythology reimagined | "Continuous camera" is radical — it cut a standard cinematic tool. "Father-son journey" constrains narrative, level design, AND combat (Atreus as companion). |
+| **Hades** | Fast fluid combat; Story depth through repetition; Every run teaches something new | "Story through repetition" justified the roguelike structure narratively — death IS the story. "Every run teaches" constrains level and encounter design. |
+| **The Last of Us** | Story is essential, not optional; AI partners build relationships; Stealth is always an option | "AI partners build relationships" drove massive investment in companion AI — not just pathfinding, but emotional presence. |
+| **Celeste** | Tough but fair; Accessibility without compromise; Story and mechanics are the same thing | "Story and mechanics are the same thing" — climbing IS the struggle, the dash IS the anxiety. Pillar prevented mechanics from being "just gameplay." |
+| **Hollow Knight** | Atmosphere over explanation; Earned mastery; World tells its own story | "Atmosphere over explanation" — no tutorials, no hand-holding, the world teaches through environmental design. |
+| **Dead Cells** | Every weapon is viable; Combat is a dance; Permanent death creates meaning | "Every weapon is viable" is extremely constraining — it demands constant balance work across hundreds of items. |
 
 ---
 
 ## Core Fantasy
 
-[What power, experience, or feeling does the player get from this game? This is
+> [What power, experience, or feeling does the player get from this game? What
-the emotional promise, not a feature list.]
+> can they do here that they can't do anywhere else? The core fantasy is the
-
+> emotional promise — the answer to "why would someone choose THIS game?"
----
+>
-
+> Strong core fantasies are visceral and immediate:
-## Unique Hook
+> - "You are a lone survivor building a new life in a hostile wilderness"
-
+> - "You command a civilization across millennia"
-[Like X, and also Y. The hook should make the game distinguishable from its
+> - "You explore a vast, beautiful world at your own pace"
-closest comparables in one sentence.]
+> - "You master intricate combat and overcome impossible odds"]
 
 ---
 
 ## Target MDA Aesthetics
 
-Rank the aesthetics this game is intentionally trying to deliver.
+[Rank the aesthetic goals this game serves, from the MDA Framework. This ranking
+guides every pillar — your pillars should collectively deliver your top 2-3
+aesthetics.]
 
-| Rank | Aesthetic | How This Game Delivers It |
+| Rank | Aesthetic | How Our Game Delivers It |
 | ---- | ---- | ---- |
-| 1 | [Challenge / Discovery / Fantasy / etc.] | [Specific delivery mechanism] |
+| 1 | [e.g., Challenge] | [Specific delivery mechanism] |
-| 2 | [Aesthetic] | [Specific delivery mechanism] |
+| 2 | [e.g., Discovery] | [Specific delivery mechanism] |
-| 3 | [Aesthetic] | [Specific delivery mechanism] |
+| 3 | [e.g., Fantasy] | [Specific delivery mechanism] |
-| Not targeted | [Aesthetic] | [Why this is not a priority] |
+| 4 | [e.g., Narrative] | [Specific delivery mechanism] |
+| N/A | [Aesthetics not targeted] | [Why this isn't a priority] |
 
-Reference aesthetics: Sensation, Fantasy, Narrative, Challenge, Fellowship,
+**Aesthetics reference** (Hunicke, LeBlanc, Zubek):
-Discovery, Expression, Submission.
+- **Sensation**: Sensory pleasure (visual beauty, satisfying audio, haptic feedback)
+- **Fantasy**: Make-believe, inhabiting a role or world
+- **Narrative**: Drama, story arcs, emotional plot progression
+- **Challenge**: Obstacle course, skill mastery, overcoming difficulty
+- **Fellowship**: Social connection, cooperation, shared experience
+- **Discovery**: Exploration, uncovering secrets, understanding hidden systems
+- **Expression**: Self-expression, creativity, personal identity
+- **Submission**: Relaxation, comfort, meditative play
 
 ---
 
-## Pillar Summary
+## The Pillars
 
-| Pillar | One-Sentence Definition | Primary Design Test |
+### Pillar 1: [Name]
-| ---- | ---- | ---- |
-| [Pillar 1] | [Falsifiable definition] | [If debating X vs Y, choose __] |
-| [Pillar 2] | [Falsifiable definition] | [If debating X vs Y, choose __] |
-| [Pillar 3] | [Falsifiable definition] | [If debating X vs Y, choose __] |
-
----
-
-## Pillar 1: [Name]
 
 **One-Sentence Definition**: [A clear, falsifiable statement of what this pillar
-means.]
+means. Must be specific enough that two people would reach the same conclusion
+when applying it to a design question.]
 
-**Target Aesthetics Served**: [Which MDA aesthetics this pillar supports.]
+**Target Aesthetics Served**: [Which MDA aesthetics from the ranking above does
+this pillar primarily deliver?]
 
-**Design Test**: [A concrete decision this pillar resolves.]
+**Design Test**: [A concrete decision this pillar resolves. "If we're debating
+between X and Y, this pillar says we choose __."]
 
-### Cross-Department Implications
+#### What This Means for Each Department
 
-| Department | This Pillar Says | Example |
+| Department | This Pillar Says... | Example |
 | ---- | ---- | ---- |
-| Design | [How it constrains mechanics and rules] | [Concrete example] |
+| **Game Design** | [How this constrains and inspires mechanics] | [Concrete example] |
-| Art | [How it constrains visuals] | [Concrete example] |
+| **Art** | [How this constrains and inspires visuals] | [Concrete example] |
-| Audio | [How it constrains sound/music] | [Concrete example] |
+| **Audio** | [How this constrains and inspires sound/music] | [Concrete example] |
-| Narrative | [How it constrains story/writing] | [Concrete example] |
+| **Narrative** | [How this constrains and inspires story/writing] | [Concrete example] |
-| Engineering | [Technical priorities or constraints] | [Concrete example] |
+| **Engineering** | [Technical implications and priorities] | [Concrete example] |
-| Production | [Scope and scheduling implications] | [Concrete example] |
 
-### Serving This Pillar
+#### Serving This Pillar
-
+- [Concrete example of a feature/decision that embodies this pillar]
-- [Concrete feature or decision that embodies this pillar]
 - [Another example]
 
-### Violating This Pillar
+#### Violating This Pillar
-
+- [Concrete example of what would betray this pillar — things we must never do]
-- [Plausible feature or decision that would betray the pillar]
 - [Another example]
 
 ---
 
-## Pillar 2: [Name]
+### Pillar 2: [Name]
 
-**One-Sentence Definition**: [A clear, falsifiable statement.]
+**One-Sentence Definition**: [Specific, falsifiable statement]
 
-**Target Aesthetics Served**: [MDA aesthetics.]
+**Target Aesthetics Served**: [MDA aesthetics]
 
-**Design Test**: [A concrete decision this pillar resolves.]
+**Design Test**: [Concrete decision it resolves]
 
-### Cross-Department Implications
+#### What This Means for Each Department
 
-| Department | This Pillar Says | Example |
+| Department | This Pillar Says... | Example |
 | ---- | ---- | ---- |
-| Design | [Constraint or inspiration] | [Example] |
+| **Game Design** | [Constraint/inspiration] | [Example] |
-| Art | [Constraint or inspiration] | [Example] |
+| **Art** | [Constraint/inspiration] | [Example] |
-| Audio | [Constraint or inspiration] | [Example] |
+| **Audio** | [Constraint/inspiration] | [Example] |
-| Narrative | [Constraint or inspiration] | [Example] |
+| **Narrative** | [Constraint/inspiration] | [Example] |
-| Engineering | [Constraint or inspiration] | [Example] |
+| **Engineering** | [Constraint/inspiration] | [Example] |
-| Production | [Constraint or inspiration] | [Example] |
-
-### Serving This Pillar
 
+#### Serving This Pillar
 - [Example]
 - [Example]
 
-### Violating This Pillar
+#### Violating This Pillar
-
 - [Example]
 - [Example]
 
 ---
 
-## Pillar 3: [Name]
+### Pillar 3: [Name]
 
-**One-Sentence Definition**: [A clear, falsifiable statement.]
+**One-Sentence Definition**: [Specific, falsifiable statement]
 
-**Target Aesthetics Served**: [MDA aesthetics.]
+**Target Aesthetics Served**: [MDA aesthetics]
 
-**Design Test**: [A concrete decision this pillar resolves.]
+**Design Test**: [Concrete decision it resolves]
 
-### Cross-Department Implications
+#### What This Means for Each Department
 
-| Department | This Pillar Says | Example |
+| Department | This Pillar Says... | Example |
 | ---- | ---- | ---- |
-| Design | [Constraint or inspiration] | [Example] |
+| **Game Design** | [Constraint/inspiration] | [Example] |
-| Art | [Constraint or inspiration] | [Example] |
+| **Art** | [Constraint/inspiration] | [Example] |
-| Audio | [Constraint or inspiration] | [Example] |
+| **Audio** | [Constraint/inspiration] | [Example] |
-| Narrative | [Constraint or inspiration] | [Example] |
+| **Narrative** | [Constraint/inspiration] | [Example] |
-| Engineering | [Constraint or inspiration] | [Example] |
+| **Engineering** | [Constraint/inspiration] | [Example] |
-| Production | [Constraint or inspiration] | [Example] |
-
-### Serving This Pillar
 
+#### Serving This Pillar
 - [Example]
 - [Example]
 
-### Violating This Pillar
+#### Violating This Pillar
-
 - [Example]
 - [Example]
 
 ---
 
-## Optional Additional Pillars
+### Pillar 4: [Name] (Optional)
 
-Use this section only if the game needs a fourth or fifth pillar. Keep the total
+[Same structure as Pillars 1-3]
-pillar count between 3 and 5.
+
+### Pillar 5: [Name] (Optional)
+
+[Same structure as Pillars 1-3]
 
 ---
 
-## Anti-Pillars
+## Anti-Pillars (What This Game Is NOT)
 
-Anti-pillars define what this game is not. Good anti-pillars block tempting
+Anti-pillars are equally important as pillars — they prevent scope creep and
-ideas that would dilute the core fantasy.
+keep the vision focused. Every "no" protects the "yes."
 
-- **NOT [thing]**: [Why this is excluded, what pillar it would compromise, and
+Great anti-pillars are things the team might actually want to do. "NOT a racing
-  what it would cost.]
+game" is obvious and useless. "NOT an open-world game" is useful if the genre
-- **NOT [thing]**: [Why excluded.]
+could plausibly support it.
-- **NOT [thing]**: [Why excluded.]
+
+- **NOT [thing]**: [Why this is explicitly excluded, what pillar it would
+  compromise, and what it would cost in development focus]
+- **NOT [thing]**: [Why excluded]
+- **NOT [thing]**: [Why excluded]
 
 ---
 
-## Pillar Conflict Priority
+## Pillar Conflict Resolution
 
-When two pillars conflict, resolve the conflict in this order.
+When two pillars conflict (and they will), use this priority order. The ranking
+reflects which aspects of the experience are most essential to the core fantasy.
 
-| Priority | Pillar | Why It Wins |
+| Priority | Pillar | Rationale |
 | ---- | ---- | ---- |
-| 1 | [Highest priority pillar] | [Rationale] |
+| 1 | [Highest priority pillar] | [Why this wins when it conflicts with others] |
-| 2 | [Second priority pillar] | [Rationale] |
+| 2 | [Second priority] | [Why] |
-| 3 | [Third priority pillar] | [Rationale] |
+| 3 | [Third priority] | [Why] |
 
-**Resolution process**:
+**Resolution Process**:
-
+1. Identify which pillars are in tension
-1. Identify which pillars are in tension.
+2. Consult the priority ranking above
-2. Check the priority table.
+3. If the lower-priority pillar can be served partially without compromising the
-3. Preserve the lower-priority pillar only where it does not weaken the higher-priority one.
+   higher-priority one, do so
-4. If the conflict is fundamental, escalate to `creative-director` for pillar revision.
+4. If not, the higher-priority pillar wins
+5. Document the decision and rationale in the relevant design document
+6. If the conflict is fundamental (two pillars are irreconcilable), escalate to
+   the creative-director to consider revising the pillars themselves
 
 ---
 
 ## Player Motivation Alignment
 
-Use Self-Determination Theory as a sanity check.
+[Verify that the pillars collectively serve the target player's psychological needs.
+Based on Self-Determination Theory (Deci & Ryan) and the Player Experience of
+Need Satisfaction model.]
 
 | Need | Which Pillar Serves It | How |
 | ---- | ---- | ---- |
-| Autonomy | [Pillar name] | [Meaningful choices or agency] |
+| **Autonomy** (meaningful choice, player agency) | [Pillar name] | [How this pillar creates autonomy] |
-| Competence | [Pillar name] | [Mastery, feedback, skill growth] |
+| **Competence** (mastery, skill growth, clear feedback) | [Pillar name] | [How this pillar creates competence] |
-| Relatedness | [Pillar name] | [Connection, belonging, emotional bond] |
+| **Relatedness** (connection, belonging, emotional bond) | [Pillar name] | [How this pillar creates relatedness] |
+
+**Gap check**: If any of the three needs is not served by at least one pillar,
+consider whether the pillar set is complete. A game that satisfies all three
+SDT needs has the strongest foundation for sustained engagement.
 
 ---
 
-## Reference Games and Inspirations
+## Emotional Arc
+
+[Map the intended emotional journey of a play session. This should be a
+deliberate design, not an accident.]
+
+### Session Emotional Arc
+
+| Phase | Duration | Target Emotion | Pillar(s) Driving It | Mechanics Delivering It |
+| ---- | ---- | ---- | ---- | ---- |
+| Opening | [e.g., 0-5 min] | [e.g., Curiosity, anticipation] | [Which pillar] | [What the player does] |
+| Rising | [e.g., 5-20 min] | [e.g., Tension, focus, flow] | [Which pillar] | [What the player does] |
+| Climax | [e.g., 20-30 min] | [e.g., Triumph, relief, awe] | [Which pillar] | [What the player does] |
+| Resolution | [e.g., 30-40 min] | [e.g., Satisfaction, reflection] | [Which pillar] | [What the player does] |
+| Hook | [End of session] | [e.g., Curiosity, unfinished business] | [Which pillar] | [What makes them return] |
+
+### Long-Term Emotional Progression
+
+[How does the emotional experience evolve across the full game? Early game vs
+mid game vs late game vs endgame should each feel distinct.]
+
+---
+
+## Reference Games
 
 | Reference | What We Take From It | What We Do Differently | Which Pillar It Validates |
 | ---- | ---- | ---- | ---- |
-| [Game 1] | [Specific mechanic, feeling, or approach] | [Our twist] | [Pillar] |
+| [Game 1] | [Specific mechanic, feeling, or approach] | [Our twist] | [Pillar name] |
-| [Game 2] | [Specific learning] | [Our twist] | [Pillar] |
+| [Game 2] | [What we learn] | [Our twist] | [Pillar name] |
-| [Game 3] | [Specific learning] | [Our twist] | [Pillar] |
+| [Game 3] | [What we learn] | [Our twist] | [Pillar name] |
 
-**Non-game inspirations**: [Films, books, music, art, real-world experiences.]
+**Non-game inspirations**: [Films, books, music, art, real-world experiences
+that inform the tone, world, or feel. Great games pull from outside the medium.]
 
 ---
 
-## Validation Checklist
+## Pillar Validation Checklist
 
-- [ ] 3-5 pillars total
+Before finalizing the pillars, verify:
-- [ ] Each pillar is falsifiable
+
-- [ ] Each pillar constrains real design choices
+- [ ] **Count**: 3-5 pillars (no more, no fewer)
-- [ ] Each pillar has a design test
+- [ ] **Falsifiable**: Each pillar makes a claim that could be wrong
-- [ ] Each pillar has cross-department implications
+- [ ] **Constraining**: Each pillar forces saying "no" to some plausible ideas
-- [ ] At least 3 anti-pillars are defined
+- [ ] **Cross-departmental**: Each pillar has implications for design, art, audio, narrative, AND engineering
-- [ ] Pillar conflict priority is explicit
+- [ ] **Design-tested**: Each pillar has a concrete design test that resolves a real decision
-- [ ] Top MDA aesthetics are covered
+- [ ] **Anti-pillars defined**: At least 3 explicit "this game is NOT" statements
-- [ ] Autonomy, competence, and relatedness have been considered
+- [ ] **Priority-ranked**: Clear order for resolving conflicts between pillars
-- [ ] Every pillar traces back to the core fantasy
+- [ ] **MDA-aligned**: Pillars collectively deliver the top-ranked target aesthetics
+- [ ] **SDT coverage**: At least one pillar serves Autonomy, one Competence, one Relatedness
+- [ ] **Memorable**: The team can recite all pillars from memory
+- [ ] **Core fantasy served**: Every pillar traces back to the core fantasy promise
 
 ---
 
 ## Next Steps
 
-- [ ] Keep this document linked from `design/gdd/game-concept.md`
+- [ ] Get pillar approval from creative-director
-- [ ] Use these pillars when writing system GDDs
+- [ ] Distribute to all department leads for sign-off
-- [ ] Revisit after major prototype learnings or milestone pivots
+- [ ] Create design tests for each pillar using real upcoming decisions
+- [ ] Schedule first pillar review (after 2 weeks of development)
+- [ ] Add pillars to the game-concept document and pitch document
 
 ---
 
-This document lives at `design/gdd/game-pillars.md`.
+*This document is the creative north star. It lives in `design/gdd/game-pillars.md`
+and is referenced by every design, art, audio, and narrative document in the project.
+Review quarterly or after major milestone pivots.*

skills/brainstorm/DETAILS.md

@@ -11,21 +11,6 @@ When this skill is invoked:
 
    See `../../references/studio-docs/director-gates.md` for the full check pattern.
 
-   Review mode controls **director / lead review gates only**. It is not a
-   blanket rule for all custom-agent or subagent usage. For `/brainstorm`, the
-   current agent calls are review gates, so `lean` skips CD-PILLARS,
-   AD-CONCEPT-VISUAL, TD-FEASIBILITY, and PR-SCOPE; `full` runs them; `solo`
-   skips all director review gates.
-
-   Director agent source files live in `../../runtime/agents/`, and the project
-   guidance template lives at `../../project-template/AGENTS.md`. Before running
-   any `full` review-mode gate, verify the target project has the matching
-   `.codex/agents/<agent-name>.toml` files installed and a root `AGENTS.md`. If
-   they are missing, run `python3 scripts/install_codex_runtime.py <target-project>`
-   from the plugin root first. When a gate is active, spawn the named Codex
-   custom agent; do not recreate the director role by pasting profile text into
-   a generic default agent.
-
 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)
@@ -35,17 +20,27 @@ When this skill is invoked:
    exploration** where the AI acts as a creative facilitator, not a replacement
    for the human's vision.
 
-   **Use a structured decision prompt when available** at key decision points
+   **Use Codex `request_user_input`** at key decision points throughout brainstorming:
-   throughout brainstorming. In Codex, use the current user-input mechanism if
-   it is available in the active mode; otherwise ask the same question directly
-   in chat and wait for the user's reply.
    - 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
+   Write full creative analysis in conversation text first, then call
-   the structured prompt or chat question to capture the decision with concise
+   `request_user_input` to capture the decision with concise labels.
-   labels.
+
+   Codex structured input requirements:
+   - Ask 1-3 short questions per `request_user_input` call.
+   - Each question must include `header` (12 or fewer characters), `id` (snake_case),
+     `question` (one sentence), and 2-3 mutually exclusive `options`.
+   - Each option must include `label` (1-5 words) and `description` (one short sentence).
+   - Put the recommended option first and suffix its label with `(Recommended)` when
+     there is a recommendation.
+   - Do not add an explicit `Other` option in Codex app runs; the client supplies the
+     free-form Other path. For app-server integrations, the equivalent free-form
+     option is represented by `isOther`.
+   - If a Claude reference choice list has more than 3 options, split it into a
+     first 2-3 option category question plus a follow-up `request_user_input` call,
+     or rely on the Codex free-form Other path for uncommon cases.
 
    Professional studio brainstorming principles to follow:
    - Withhold judgment — no idea is bad during exploration
@@ -70,19 +65,53 @@ conversationally (not as a checklist):
 **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 a structured prompt with preset options.)*
+  Do NOT put this in `request_user_input` 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 a structured prompt for this when available — constrained choice.)*
+  or let you express yourself? *(Use `request_user_input` for this — constrained choice.
+  Use 2-3 grouped options plus Codex's free-form Other path.)*
 
 **Practical constraints** (shape the sandbox before brainstorming).
-Bundle these into a single multi-field structured prompt when available:
+Bundle these into one Codex `request_user_input` call with three questions:
-- 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)
 
-If the UI supports grouping fields, use exactly these group names. If not,
+```json
-ask the three questions one at a time.
+{
+  "questions": [
+    {
+      "header": "Experience",
+      "id": "target_experience",
+      "question": "What kind of experience do you most want players to have?",
+      "options": [
+        {"label": "Challenge", "description": "Players seek mastery, pressure, and earned wins."},
+        {"label": "Story", "description": "Players seek discovery, drama, and authored moments."},
+        {"label": "Expression", "description": "Players seek creativity, agency, or relaxed flow."}
+      ]
+    },
+    {
+      "header": "Timeline",
+      "id": "timeline",
+      "question": "What's your realistic development timeline?",
+      "options": [
+        {"label": "Weeks", "description": "A jam-scale prototype or tiny polished game."},
+        {"label": "Months", "description": "A focused indie scope with selective polish."},
+        {"label": "1+ years", "description": "A larger project that needs strong scope control."}
+      ]
+    },
+    {
+      "header": "Dev level",
+      "id": "dev_level",
+      "question": "Where are you in your dev journey?",
+      "options": [
+        {"label": "First game", "description": "Keep systems simple and learning-friendly."},
+        {"label": "Shipped before", "description": "Use moderate scope and proven patterns."},
+        {"label": "Professional", "description": "Assume stronger production and technical context."}
+      ]
+    }
+  ]
+}
+```
+
+Do not use tabs or more than three options per question in Codex.
 
 **Synthesize** the answers into a **Creative Brief** — a 3-5 sentence
 summary of the person's emotional goals, taste profile, and constraints.
@@ -120,25 +149,40 @@ For each concept, present:
 - **Why It Could Work** (1 sentence on market/audience fit)
 - **Biggest Risk** (1 sentence on the hardest unanswered question)
 
-Present all three. Then use a structured prompt or direct chat question to
+Present all three. Then use Codex `request_user_input` to capture the selection.
-capture the selection.
 
-**CRITICAL**: This MUST be a plain list choice, not a multi-field form. Use this structure:
+**CRITICAL**: Codex `request_user_input` only supports 1-3 short questions and
+2-3 options per question. Do not use tabs, form fields, or a 5-option list.
+Use exactly this shape:
 
-```
+```json
-structured decision prompt(
+{
-  prompt: "Which concept resonates with you? You can pick one, combine elements, or ask for fresh directions.",
+  "questions": [
-  options: [
+    {
-    "Concept 1 — [Title]",
+      "header": "Concept",
-    "Concept 2 — [Title]",
+      "id": "concept_choice",
-    "Concept 3 — [Title]",
+      "question": "Which concept is the strongest starting point?",
-    "Combine elements across concepts",
+      "options": [
-    "Generate fresh directions"
+        {"label": "Concept 1", "description": "[Title] — [one-line reason it fits]."},
+        {"label": "Concept 2", "description": "[Title] — [one-line reason it fits]."},
+        {"label": "Concept 3", "description": "[Title] — [one-line reason it fits]."}
+      ]
+    },
+    {
+      "header": "Next move",
+      "id": "concept_next_move",
+      "question": "How should we proceed with that direction?",
+      "options": [
+        {"label": "Develop it", "description": "Use the selected concept as the foundation."},
+        {"label": "Combine", "description": "Blend the selected concept with elements from another."},
+        {"label": "Fresh set", "description": "Generate three new directions from the brief."}
+      ]
+    }
   ]
-)
+}
 ```
 
-Do NOT use a multi-field form here. This is a plain prompt plus options.
+If the user wants a custom blend, use the Codex free-form Other path.
 
 Never pressure toward a choice — let them sit with it.
 
@@ -152,11 +196,12 @@ isolation, no amount of content or polish will save the game.
 
 **30-Second Loop** (moment-to-moment):
 
-Ask these as structured prompts when available — derive the options from the chosen concept, don't hardcode them:
+Ask these with Codex `request_user_input` — 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`).
+1. **Core action feel** — prompt: "What's the primary feel of the core action?" Generate exactly 2-3 options that fit the concept's genre and tone. Use the Codex free-form Other path for custom answers.
 
-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.
+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 exactly 2-3 options that match the concept. Use the Codex free-form Other path for custom answers.
 
 After capturing answers, analyze: Is this action intrinsically satisfying? What makes it feel good? (Audio feedback, visual juice, timing satisfaction, tactical depth?)
 
@@ -201,53 +246,34 @@ Then define **3+ anti-pillars** (what this game is NOT):
   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 a structured prompt:
+**Pillar confirmation**: After presenting the full pillar set, use Codex `request_user_input`:
 - 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`
+- Options: `[A] Lock these in` / `[B] Revise one` / `[C] Discuss further`
 
-If the user selects B, C, or D, make the revision, then use a structured prompt again:
+If the user selects B or C, make the revision or discuss the concern, then use
+Codex `request_user_input` again:
 - Prompt: "Pillars updated. Ready to lock these in?"
-- Options: `[A] Lock these in` / `[B] Revise another pillar` / `[C] Something else`
+- Options: `[A] Lock these in` / `[B] Revise another` / `[C] Discuss further`
 
 Repeat until the user selects [A] Lock these in.
 
-Treat `[A] Lock these in` as approval to create or update
-`design/gdd/game-pillars.md` during this `/brainstorm` run. The file is a
-brainstorm-stage artifact: start it lightweight now, then let later workflows
-deepen it as the project matures.
-
-**Pillar conflict priority**: After pillars are locked, ask one short follow-up:
-"If two pillars conflict, which one wins first?" Present the locked pillar names
-as ordered options and let the user rank them or describe a custom priority.
-Record this as the initial conflict-resolution order in
-`design/gdd/game-pillars.md`.
-
 **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." Create or update the initial `design/gdd/game-pillars.md` directly from the locked pillars, then proceed to Phase 5.
+- `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." Create or update the initial `design/gdd/game-pillars.md` directly from the locked pillars, then 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 custom-agent delegation in parallel before moving to Phase 5. Issue both subagent requests simultaneously — do not wait for one before starting the other.**
+**After pillars and anti-pillars are agreed, spawn BOTH `creative-director` AND `art-director` via Codex custom-agent delegation in parallel before moving to Phase 5. Issue both custom-agent 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, pillar conflict priority,
+  Pass: full pillar set with design tests, anti-pillars, core fantasy, unique hook.
-  core fantasy, unique hook.
-  Also pass whether `design/gdd/game-pillars.md` already exists and whether its
-  contents match the locked pillar set. This file is required for `/brainstorm`:
-  if it already exists and still matches the locked pillars, the subagent reviews
-  it in place and avoids rewriting for churn; if the file is missing, stale, or
-  incomplete, the subagent creates or updates it from
-  `../../references/studio-docs/templates/game-pillars.md`. The initial version
-  only needs the brainstorm-level material: core fantasy, unique hook, target
-  MDA aesthetics, 3-5 pillars, design tests, anti-pillars, conflict priority,
-  and a validation checklist.
 
 - **`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 structured prompt:
+Collect both verdicts, then present them together using one Codex
-- Tab **"Pillars"**: present creative-director feedback. Options mirror the standard CD-PILLARS handling — `Lock in as-is` / `Revise [specific pillar]` / `Discuss further`.
+`request_user_input` call with up to two questions:
-- 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`.
+- Question **"Pillars"**: present creative-director feedback. Options mirror the standard CD-PILLARS handling — `Lock in` / `Revise one` / `Discuss`.
+- Question **"Visual"**: present the art-director's 2-3 named visual direction options. If there are three named directions, use those three options and rely on the Codex free-form Other path for combine/custom answers. If there are only two named directions, use those two plus `Combine`.
 
 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.
 
@@ -274,13 +300,13 @@ who this game is actually for:
 
 Ground the concept in reality:
 
-- **Target platform**: Use a structured prompt when available — "What platforms are you targeting for this game?"
+- **Target platform**: Use Codex `request_user_input` — "What platforms are you targeting for this game?"
-  Options: `PC (Steam / Epic)` / `Mobile (iOS / Android)` / `Console` / `Web / Browser` / `Multiple platforms`
+  Options: `PC` / `Mobile` / `Console/Web`. Use the Codex free-form Other path for multiple platforms or a specific store target.
   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 a structured prompt when available — "Do you already have an engine you work in?"
+- **Engine experience**: Use Codex `request_user_input` — "Do you already have an engine you work in?"
-  Options: `Godot` / `Unity` / `Unreal Engine 5` / `No preference — help me decide`
+  Options: `Godot` / `Unity` / `Unreal`. Use the Codex free-form Other path for "No preference" or another engine.
   - 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?
@@ -314,20 +340,10 @@ Present the assessment to the user. If UNREALISTIC, offer to adjust the MVP defi
 
 ---
 
-4. **Generate the brainstorm documents**:
+4. **Generate the game concept document** using the template at
-
+   `../../references/studio-docs/templates/game-concept.md`. Fill in ALL sections from the
-   - Generate or update `design/gdd/game-pillars.md` using
+   brainstorm conversation, including the MDA analysis, player motivation
-     `../../references/studio-docs/templates/game-pillars.md`. This file is
+   profile, and flow state design sections.
-     created during `/brainstorm`, even if it starts lightweight. If review mode
-     is `full`, the `creative-director` subagent owns this write during
-     CD-PILLARS. If review mode is `lean` or `solo`, the main brainstorm workflow
-     writes the initial version directly after pillars are locked.
-   - Generate `design/gdd/game-concept.md` using
-     `../../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.
-   - In `design/gdd/game-concept.md`, summarize the locked pillars and link to
-     `design/gdd/game-pillars.md` as the detailed pillar source of truth.
 
    **Include a Visual Identity Anchor section** in the game concept document with:
    - The selected visual direction name
@@ -338,21 +354,20 @@ Present the assessment to the user. If UNREALISTIC, offer to adjust the MVP defi
    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 a structured prompt or direct chat question for write approval:
+5. Use Codex `request_user_input` for write approval:
-- Prompt: "Brainstorm documents are ready. May I write them to `design/gdd/game-concept.md` and `design/gdd/game-pillars.md`?"
+- Prompt: "Game concept is ready. May I write it to `design/gdd/game-concept.md`?"
-- Options: `[A] Yes — write them` / `[B] Not yet — revise a section first`
+- Options: `[A] Yes — write it` / `[B] Not yet — revise a section first`
 
-If [B]: ask which section to revise using a structured prompt with options: `Elevator Pitch` / `Core Fantasy & Unique Hook` / `Pillars` / `Core Loop` / `MVP Definition` / `Scope Tiers` / `Risks` / `Something else — I'll describe`
+If [B]: ask which area to revise using Codex `request_user_input` with 2-3
+category options such as `Identity`, `Loop`, and `Scope/Risks`, then ask a
+follow-up question if the category needs narrowing. Use the Codex free-form
+Other path for a custom section.
 
-After revising, show the updated section as a diff or clear before/after, then ask — "Ready to write the updated brainstorm documents?"
+After revising, show the updated section as a diff or clear before/after, then use Codex `request_user_input` — "Ready to write the updated concept document?"
-Options: `[A] Yes — write them` / `[B] Revise another section`
+Options: `[A] Yes — write it` / `[B] Revise another section`
 Repeat until the user selects [A].
 
-If yes, generate `design/gdd/game-pillars.md` using
+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.
-`../../references/studio-docs/templates/game-pillars.md` and
-`design/gdd/game-concept.md` using
-`../../references/studio-docs/templates/game-concept.md`, fill both from the
-brainstorm conversation, and write the files, 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.
 
@@ -379,7 +394,7 @@ brainstorm conversation, and write the files, creating directories as needed.
    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 paths.
+   primary player type, engine recommendation, biggest risk, and file path.
 
 Verdict: **COMPLETE** — game concept created and handed off for next steps.
 

skills/brainstorm/SKILL.md

@@ -15,13 +15,10 @@ the current project does not already have those agents installed in
 `python3 scripts/install_codex_runtime.py <target-project>` from the plugin root
 first.
 
-Review mode controls review-gate intensity, not all custom-agent usage:
+Review mode follows the Claude reference flow: `full` runs the `/brainstorm`
-`full` runs key director/lead gates, `lean` runs only PHASE-GATE checks such as
+director gates, `lean` skips those ordinary per-skill gates, and `solo` skips
-`/gate-check`, and `solo` skips director review gates.
+all director gates.
 
-`/brainstorm` writes two brainstorm-stage artifacts:
+`/brainstorm` writes `design/gdd/game-concept.md`. It defines and records game
-`design/gdd/game-concept.md` and `design/gdd/game-pillars.md`. In
+pillars inside that concept document; it does not create
-`--review full` mode, `/brainstorm` calls the `creative-director` custom agent
+`design/gdd/game-pillars.md` as a separate artifact.
-during the CD-PILLARS gate and gives that subagent responsibility for creating
-or updating `design/gdd/game-pillars.md`. In `lean` or `solo` mode, the main
-brainstorm workflow writes the initial pillar document directly.

standards/design-docs.md

@@ -7,11 +7,10 @@ paths:
 
 These rules apply to per-system GDDs under `design/gdd/**`.
 `design/gdd/game-concept.md` uses
-`references/studio-docs/templates/game-concept.md`. In full `/brainstorm`
+`references/studio-docs/templates/game-concept.md` and is not a per-system GDD.
-review mode, `design/gdd/game-pillars.md` is created or updated through the
+If `design/gdd/game-pillars.md` exists, it uses
-`creative-director` subagent during CD-PILLARS. In lean or solo mode, the main
+`references/studio-docs/templates/game-pillars.md` and is also not a
-brainstorm workflow creates the initial version directly. It uses
+per-system GDD.
-`references/studio-docs/templates/game-pillars.md`.
 
 - 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