diff --git a/README.md b/README.md
index e2f426c..876224a 100644
--- a/README.md
+++ b/README.md
@@ -10,14 +10,27 @@ skills expose the runtime workflows directly. Do not use a global
 - Skills:
   - `$using-codex-game-studios` explains the plugin workflow and entry points.
   - `$setup-runtime` installs bundled director agents into a target game project.
-  - `$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/`
-- References: `references/studio-docs/director-gates.md`, `references/studio-docs/templates/game-concept.md`
+- References: `references/studio-docs/director-gates.md`, `references/studio-docs/templates/game-concept.md`, `references/studio-docs/templates/game-pillars.md`
 - Standards: `standards/design-docs.md`
 - Marketplace: `.agents/plugins/marketplace.json`
 - No hooks, rules, MCP servers, or app integrations yet
 
+## Review Intensity
+
+`production/review-mode.txt` controls review-gate intensity:
+
+- `full`: all key director / lead review gates call their custom agents.
+- `lean`: only PHASE-GATE review gates such as `/gate-check` call directors;
+  ordinary per-skill review gates are skipped.
+- `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
 
 To install the bundled custom agents into a game project, invoke `$setup-runtime`
diff --git a/references/studio-docs/director-gates.md b/references/studio-docs/director-gates.md
index 5b6f0f0..741dc6c 100644
--- a/references/studio-docs/director-gates.md
+++ b/references/studio-docs/director-gates.md
@@ -32,8 +32,14 @@ profile text into a generic default agent.
 
 ## Review Modes
 
-Review intensity controls whether director gates run. It can be set globally
-(persists across sessions) or overridden per skill run.
+Review intensity controls whether director and lead **review gates** run. It is
+not a global switch for all custom-agent or subagent usage: a future team
+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.
@@ -45,14 +51,14 @@ 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
+/architecture-decision --review solo     → skips review 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 |
+| `full` | All key director / lead review gates call their custom agents | 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 |
+| `solo` | All director review gates are skipped | Game jams, prototypes, maximum speed |
 
 **Check pattern — apply before every gate spawn:**
 
@@ -63,8 +69,9 @@ Before spawning gate [GATE-ID]:
 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)
+- solo → skip all director / lead review gates. Note: "[GATE-ID] skipped — Solo mode"
+- lean → skip ordinary per-skill review gates; only run PHASE-GATE checks
+         (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE)
          Note: "[GATE-ID] skipped — Lean mode"
 - full → spawn as normal
 ```
@@ -79,9 +86,12 @@ Apply the resolved mode:
 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
+- `full` → **spawn all key director / lead review gates** as described by the skill.
+- `lean` → **spawn only PHASE-GATE review gates** such as `/gate-check`
+  (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE). Skip ordinary
+  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:
@@ -146,8 +156,15 @@ 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
@@ -155,7 +172,18 @@ 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
 
diff --git a/references/studio-docs/templates/game-pillars.md b/references/studio-docs/templates/game-pillars.md
new file mode 100644
index 0000000..ba631c4
--- /dev/null
+++ b/references/studio-docs/templates/game-pillars.md
@@ -0,0 +1,247 @@
+# Game Pillars: [Game Title]
+
+## Document Status
+
+- **Version**: 1.0
+- **Last Updated**: [Date]
+- **Owner**: creative-director
+- **Status**: Draft / Under Review / Approved
+
+> **Creative Director Review (CD-PILLARS)**: [APPROVED date / CONCERNS accepted date / REVISED date]
+
+---
+
+## Purpose
+
+This document is the source of truth for the game's creative pillars. It is
+created during `/brainstorm` once the user locks the pillars. The first version
+can be lightweight; later workflows may deepen the cross-department implications
+and validation details as the project matures.
+
+Pillars are the 3-5 non-negotiable principles that define the game's identity.
+Every design, art, audio, narrative, production, and technical decision should
+serve at least one pillar. If a feature does not serve a pillar, it probably
+does not belong in the game.
+
+---
+
+## Core Fantasy
+
+[What power, experience, or feeling does the player get from this game? This is
+the emotional promise, not a feature list.]
+
+---
+
+## Unique Hook
+
+[Like X, and also Y. The hook should make the game distinguishable from its
+closest comparables in one sentence.]
+
+---
+
+## Target MDA Aesthetics
+
+Rank the aesthetics this game is intentionally trying to deliver.
+
+| Rank | Aesthetic | How This Game Delivers It |
+| ---- | ---- | ---- |
+| 1 | [Challenge / Discovery / Fantasy / etc.] | [Specific delivery mechanism] |
+| 2 | [Aesthetic] | [Specific delivery mechanism] |
+| 3 | [Aesthetic] | [Specific delivery mechanism] |
+| Not targeted | [Aesthetic] | [Why this is not a priority] |
+
+Reference aesthetics: Sensation, Fantasy, Narrative, Challenge, Fellowship,
+Discovery, Expression, Submission.
+
+---
+
+## Pillar Summary
+
+| Pillar | One-Sentence Definition | Primary Design Test |
+| ---- | ---- | ---- |
+| [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.]
+
+**Target Aesthetics Served**: [Which MDA aesthetics this pillar supports.]
+
+**Design Test**: [A concrete decision this pillar resolves.]
+
+### Cross-Department Implications
+
+| Department | This Pillar Says | Example |
+| ---- | ---- | ---- |
+| Design | [How it constrains mechanics and rules] | [Concrete example] |
+| Art | [How it constrains visuals] | [Concrete example] |
+| Audio | [How it constrains sound/music] | [Concrete example] |
+| Narrative | [How it constrains story/writing] | [Concrete example] |
+| Engineering | [Technical priorities or constraints] | [Concrete example] |
+| Production | [Scope and scheduling implications] | [Concrete example] |
+
+### Serving This Pillar
+
+- [Concrete feature or decision that embodies this pillar]
+- [Another example]
+
+### Violating This Pillar
+
+- [Plausible feature or decision that would betray the pillar]
+- [Another example]
+
+---
+
+## Pillar 2: [Name]
+
+**One-Sentence Definition**: [A clear, falsifiable statement.]
+
+**Target Aesthetics Served**: [MDA aesthetics.]
+
+**Design Test**: [A concrete decision this pillar resolves.]
+
+### Cross-Department Implications
+
+| Department | This Pillar Says | Example |
+| ---- | ---- | ---- |
+| Design | [Constraint or inspiration] | [Example] |
+| Art | [Constraint or inspiration] | [Example] |
+| Audio | [Constraint or inspiration] | [Example] |
+| Narrative | [Constraint or inspiration] | [Example] |
+| Engineering | [Constraint or inspiration] | [Example] |
+| Production | [Constraint or inspiration] | [Example] |
+
+### Serving This Pillar
+
+- [Example]
+- [Example]
+
+### Violating This Pillar
+
+- [Example]
+- [Example]
+
+---
+
+## Pillar 3: [Name]
+
+**One-Sentence Definition**: [A clear, falsifiable statement.]
+
+**Target Aesthetics Served**: [MDA aesthetics.]
+
+**Design Test**: [A concrete decision this pillar resolves.]
+
+### Cross-Department Implications
+
+| Department | This Pillar Says | Example |
+| ---- | ---- | ---- |
+| Design | [Constraint or inspiration] | [Example] |
+| Art | [Constraint or inspiration] | [Example] |
+| Audio | [Constraint or inspiration] | [Example] |
+| Narrative | [Constraint or inspiration] | [Example] |
+| Engineering | [Constraint or inspiration] | [Example] |
+| Production | [Constraint or inspiration] | [Example] |
+
+### Serving This Pillar
+
+- [Example]
+- [Example]
+
+### Violating This Pillar
+
+- [Example]
+- [Example]
+
+---
+
+## Optional Additional Pillars
+
+Use this section only if the game needs a fourth or fifth pillar. Keep the total
+pillar count between 3 and 5.
+
+---
+
+## Anti-Pillars
+
+Anti-pillars define what this game is not. Good anti-pillars block tempting
+ideas that would dilute the core fantasy.
+
+- **NOT [thing]**: [Why this is excluded, what pillar it would compromise, and
+  what it would cost.]
+- **NOT [thing]**: [Why excluded.]
+- **NOT [thing]**: [Why excluded.]
+
+---
+
+## Pillar Conflict Priority
+
+When two pillars conflict, resolve the conflict in this order.
+
+| Priority | Pillar | Why It Wins |
+| ---- | ---- | ---- |
+| 1 | [Highest priority pillar] | [Rationale] |
+| 2 | [Second priority pillar] | [Rationale] |
+| 3 | [Third priority pillar] | [Rationale] |
+
+**Resolution process**:
+
+1. Identify which pillars are in tension.
+2. Check the priority table.
+3. Preserve the lower-priority pillar only where it does not weaken the higher-priority one.
+4. If the conflict is fundamental, escalate to `creative-director` for pillar revision.
+
+---
+
+## Player Motivation Alignment
+
+Use Self-Determination Theory as a sanity check.
+
+| Need | Which Pillar Serves It | How |
+| ---- | ---- | ---- |
+| Autonomy | [Pillar name] | [Meaningful choices or agency] |
+| Competence | [Pillar name] | [Mastery, feedback, skill growth] |
+| Relatedness | [Pillar name] | [Connection, belonging, emotional bond] |
+
+---
+
+## Reference Games and Inspirations
+
+| 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 2] | [Specific learning] | [Our twist] | [Pillar] |
+| [Game 3] | [Specific learning] | [Our twist] | [Pillar] |
+
+**Non-game inspirations**: [Films, books, music, art, real-world experiences.]
+
+---
+
+## Validation Checklist
+
+- [ ] 3-5 pillars total
+- [ ] Each pillar is falsifiable
+- [ ] Each pillar constrains real design choices
+- [ ] Each pillar has a design test
+- [ ] Each pillar has cross-department implications
+- [ ] At least 3 anti-pillars are defined
+- [ ] Pillar conflict priority is explicit
+- [ ] Top MDA aesthetics are covered
+- [ ] Autonomy, competence, and relatedness have been considered
+- [ ] Every pillar traces back to the core fantasy
+
+---
+
+## Next Steps
+
+- [ ] Keep this document linked from `design/gdd/game-concept.md`
+- [ ] Use these pillars when writing system GDDs
+- [ ] Revisit after major prototype learnings or milestone pivots
+
+---
+
+This document lives at `design/gdd/game-pillars.md`.
diff --git a/skills/brainstorm/DETAILS.md b/skills/brainstorm/DETAILS.md
index 00c0b2e..c50f7d5 100644
--- a/skills/brainstorm/DETAILS.md
+++ b/skills/brainstorm/DETAILS.md
@@ -11,6 +11,12 @@ 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/`. Before running
    any `full` review-mode gate, verify the target project has the matching
    `.codex/agents/<agent-name>.toml` files installed. If they are missing, run
@@ -203,15 +209,36 @@ If the user selects B, C, or D, make the revision, then use a structured prompt
 
 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." 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.
+- `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.
+- `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.
 - `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.**
 
 - **`creative-director`** — gate **CD-PILLARS** (`../../references/studio-docs/director-gates.md`)
-  Pass: full pillar set with design tests, anti-pillars, core fantasy, unique hook.
+  Pass: full pillar set with design tests, anti-pillars, pillar conflict priority,
+  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.
@@ -285,10 +312,20 @@ Present the assessment to the user. If UNREALISTIC, offer to adjust the MVP defi
 
 ---
 
-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.
+4. **Generate the brainstorm documents**:
+
+   - Generate or update `design/gdd/game-pillars.md` using
+     `../../references/studio-docs/templates/game-pillars.md`. This file is
+     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
@@ -300,16 +337,20 @@ Present the assessment to the user. If UNREALISTIC, offer to adjust the MVP defi
    move" decision before it can be forgotten between sessions.
 
 5. Use a structured prompt or direct chat question 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`
+- Prompt: "Brainstorm documents are ready. May I write them to `design/gdd/game-concept.md` and `design/gdd/game-pillars.md`?"
+- Options: `[A] Yes — write them` / `[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`
 
-After revising, show the updated section as a diff or clear before/after, then ask — "Ready to write the updated concept document?"
-Options: `[A] Yes — write it` / `[B] Revise another section`
+After revising, show the updated section as a diff or clear before/after, then ask — "Ready to write the updated brainstorm documents?"
+Options: `[A] Yes — write them` / `[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.
+If yes, generate `design/gdd/game-pillars.md` using
+`../../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.
 
@@ -336,7 +377,7 @@ If yes, generate the document using the template at `../../references/studio-doc
    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.
+   primary player type, engine recommendation, biggest risk, and file paths.
 
 Verdict: **COMPLETE** — game concept created and handed off for next steps.
 
diff --git a/skills/brainstorm/SKILL.md b/skills/brainstorm/SKILL.md
index 8865244..139dbdd 100644
--- a/skills/brainstorm/SKILL.md
+++ b/skills/brainstorm/SKILL.md
@@ -10,3 +10,14 @@ Run the Codex Game Studios brainstorm workflow.
 Before acting, read `DETAILS.md` for the full workflow. Apply project guidance from `AGENTS.md` and use `../../standards/` for path-specific standards.
 
 Director gates use the bundled custom agents from `../../runtime/agents/`. If the current project does not already have those agents installed in `.codex/agents/`, run `$setup-runtime` first.
+
+Review mode controls review-gate intensity, not all custom-agent usage:
+`full` runs key director/lead gates, `lean` runs only PHASE-GATE checks such as
+`/gate-check`, and `solo` skips director review gates.
+
+`/brainstorm` writes two brainstorm-stage artifacts:
+`design/gdd/game-concept.md` and `design/gdd/game-pillars.md`. In
+`--review full` mode, `/brainstorm` calls the `creative-director` custom agent
+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.
diff --git a/skills/using-codex-game-studios/SKILL.md b/skills/using-codex-game-studios/SKILL.md
index 988cd5d..e52e01a 100644
--- a/skills/using-codex-game-studios/SKILL.md
+++ b/skills/using-codex-game-studios/SKILL.md
@@ -14,6 +14,16 @@ Codex Game Studios is a game-production plugin built around plugin-discovered sk
 - Use `runtime/agents/` as the plugin source of bundled custom agents.
 - Use `references/` and `standards/` only when the active workflow points to them.
 
+## Review Intensity
+
+`production/review-mode.txt` controls review-gate intensity, not whether agents
+exist or whether future team workflows may use subagents for core work:
+
+- `full` — all key director / lead review gates call their custom agents.
+- `lean` — only PHASE-GATE review gates such as `/gate-check` call directors;
+  ordinary per-skill review gates are skipped.
+- `solo` — all director review gates are skipped.
+
 ## Design Rule
 
 Do not rely on a global `~/.codex/skills/codex-game-studio` bridge. The installed plugin exposes its skills through `.codex-plugin/plugin.json` with `"skills": "./skills/"`, matching the normal Codex plugin layout.
diff --git a/standards/design-docs.md b/standards/design-docs.md
index 33ea617..4b45b4b 100644
--- a/standards/design-docs.md
+++ b/standards/design-docs.md
@@ -5,6 +5,14 @@ paths:
 
 # Design Document Rules
 
+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`
+review mode, `design/gdd/game-pillars.md` is created or updated through the
+`creative-director` subagent during CD-PILLARS. In lean or solo mode, the main
+brainstorm workflow creates the initial version directly. It uses
+`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
 - Edge cases must explicitly state what happens, not just "handle gracefully"