wxm/codex-game-studios
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Align brainstorm workflow with Codex input schema

Browse Source
This commit is contained in:
wxm
2026-05-18 19:42:51 -07:00
parent 0c4227cba6
commit 445d86c300
11 changed files with 1192 additions and 349 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
README.md
View File

@@ -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`
and `design/gdd/game-pillars.md`.
- `$brainstorm` guides game concept ideation into `design/gdd/game-concept.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.
- `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.
- `full`: all gates active — every workflow step reviewed.
- `lean`: PHASE-GATEs only (`/gate-check`) — per-skill gates skipped.
- `solo`: no director gates anywhere.
## Runtime Setup

20
project-template/AGENTS.md
View File

@@ -43,16 +43,12 @@ production/review-mode.txt
Allowed values:
- `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.
- `full` — all gates active; every workflow step is reviewed.
- `lean` — PHASE-GATEs only (`/gate-check`); per-skill gates are skipped.
- `solo` — no director gates anywhere.
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.
In `full` mode, the `creative-director` review gate participates in creating or
updating the pillar document.
Game pillars and anti-pillars are defined during `/brainstorm` and recorded
inside `design/gdd/game-concept.md`. A separate `design/gdd/game-pillars.md`
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.

86
references/studio-docs/director-gates.md
View File

@@ -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
custom agents, and all key Tier 2 leads. Any skill, team orchestrator, or
workflow may invoke these gates.
**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.
---
@@ -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
`.codex/agents/<agent-name>.toml`. The target project should also have a root
`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.
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 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.
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.
@@ -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 |
| `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 |
| `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:**
@@ -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"
- lean → skip ordinary per-skill review gates; only run PHASE-GATE checks
(CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE)
- 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
```
@@ -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.
- `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`
- `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 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
all subagent requests before waiting for any result. Collect all verdicts before
proceeding.
Spawn all [N] agents simultaneously via Codex custom-agent delegation — issue all custom-agent requests before
waiting for any result. Collect all verdicts before 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).
> 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."
> [list] (needs sharpening), or REJECT (weak — pillars do not carry weight)."
**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
added later, invoke it with the same Codex custom-agent delegation pattern used
for Tier 1 agents.
specialist's feasibility sign-off is needed. Tier 2 leads use Sonnet (default).
---
@@ -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

338
references/studio-docs/templates/game-pillars.md
View File

@@ -1,247 +1,313 @@
# 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]
- **Approved By**: creative-director
- **Status**: [Draft / Under Review / Approved]
---
## Purpose
## What Are Game Pillars?
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 this game's identity.
Every design, art, audio, narrative, and technical decision must serve at least
one pillar. If a feature doesn't serve a pillar, it doesn't belong in the game.
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.
**Why pillars matter**: In a typical development cycle, the team makes thousands
of small creative decisions. Pillars ensure all those decisions push in the same
direction, creating a coherent player experience rather than a collection of
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
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.]
> [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 — the answer to "why would someone choose THIS game?"
>
> Strong core fantasies are visceral and immediate:
> - "You are a lone survivor building a new life in a hostile wilderness"
> - "You command a civilization across millennia"
> - "You explore a vast, beautiful world at your own pace"
> - "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] |
| 2 | [Aesthetic] | [Specific delivery mechanism] |
| 3 | [Aesthetic] | [Specific delivery mechanism] |
| Not targeted | [Aesthetic] | [Why this is not a priority] |
| 1 | [e.g., Challenge] | [Specific delivery mechanism] |
| 2 | [e.g., Discovery] | [Specific delivery mechanism] |
| 3 | [e.g., Fantasy] | [Specific delivery mechanism] |
| 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,
Discovery, Expression, Submission.
**Aesthetics reference** (Hunicke, LeBlanc, Zubek):
- **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] | [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]
### 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] |
| 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] |
| **Game Design** | [How this constrains and inspires mechanics] | [Concrete example] |
| **Art** | [How this constrains and inspires visuals] | [Concrete example] |
| **Audio** | [How this constrains and inspires sound/music] | [Concrete example] |
| **Narrative** | [How this constrains and inspires story/writing] | [Concrete example] |
| **Engineering** | [Technical implications and priorities] | [Concrete example] |
### Serving This Pillar
- [Concrete feature or decision that embodies this pillar]
#### Serving This Pillar
- [Concrete example of a feature/decision that embodies this pillar]
- [Another example]
### Violating This Pillar
- [Plausible feature or decision that would betray the pillar]
#### Violating This Pillar
- [Concrete example of what would betray this pillar — things we must never do]
- [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] |
| 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
| **Game Design** | [Constraint/inspiration] | [Example] |
| **Art** | [Constraint/inspiration] | [Example] |
| **Audio** | [Constraint/inspiration] | [Example] |
| **Narrative** | [Constraint/inspiration] | [Example] |
| **Engineering** | [Constraint/inspiration] | [Example] |
#### 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] |
| 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
| **Game Design** | [Constraint/inspiration] | [Example] |
| **Art** | [Constraint/inspiration] | [Example] |
| **Audio** | [Constraint/inspiration] | [Example] |
| **Narrative** | [Constraint/inspiration] | [Example] |
| **Engineering** | [Constraint/inspiration] | [Example] |
#### 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
pillar count between 3 and 5.
[Same structure as Pillars 1-3]
### 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
ideas that would dilute the core fantasy.
Anti-pillars are equally important as pillars — they prevent scope creep and
keep the vision focused. Every "no" protects the "yes."
- **NOT [thing]**: [Why this is excluded, what pillar it would compromise, and
what it would cost.]
- **NOT [thing]**: [Why excluded.]
- **NOT [thing]**: [Why excluded.]
Great anti-pillars are things the team might actually want to do. "NOT a racing
game" is obvious and useless. "NOT an open-world game" is useful if the genre
could plausibly support it.
- **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] |
| 2 | [Second priority pillar] | [Rationale] |
| 3 | [Third priority pillar] | [Rationale] |
| 1 | [Highest priority pillar] | [Why this wins when it conflicts with others] |
| 2 | [Second priority] | [Why] |
| 3 | [Third priority] | [Why] |
**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.
**Resolution Process**:
1. Identify which pillars are in tension
2. Consult the priority ranking above
3. If the lower-priority pillar can be served partially without compromising the
higher-priority one, do so
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] |
| Competence | [Pillar name] | [Mastery, feedback, skill growth] |
| Relatedness | [Pillar name] | [Connection, belonging, emotional bond] |
| **Autonomy** (meaningful choice, player agency) | [Pillar name] | [How this pillar creates autonomy] |
| **Competence** (mastery, skill growth, clear feedback) | [Pillar name] | [How this pillar creates competence] |
| **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 2] | [Specific learning] | [Our twist] | [Pillar] |
| [Game 3] | [Specific learning] | [Our twist] | [Pillar] |
| [Game 1] | [Specific mechanic, feeling, or approach] | [Our twist] | [Pillar name] |
| [Game 2] | [What we learn] | [Our twist] | [Pillar name] |
| [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
- [ ] 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
Before finalizing the pillars, verify:
- [ ] **Count**: 3-5 pillars (no more, no fewer)
- [ ] **Falsifiable**: Each pillar makes a claim that could be wrong
- [ ] **Constraining**: Each pillar forces saying "no" to some plausible ideas
- [ ] **Cross-departmental**: Each pillar has implications for design, art, audio, narrative, AND engineering
- [ ] **Design-tested**: Each pillar has a concrete design test that resolves a real decision
- [ ] **Anti-pillars defined**: At least 3 explicit "this game is NOT" statements
- [ ] **Priority-ranked**: Clear order for resolving conflicts between pillars
- [ ] **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`
- [ ] Use these pillars when writing system GDDs
- [ ] Revisit after major prototype learnings or milestone pivots
- [ ] Get pillar approval from creative-director
- [ ] Distribute to all department leads for sign-off
- [ ] 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.*

139
runtime/agents/art-director.toml
View File

File diff suppressed because one or more lines are too long

362
runtime/agents/creative-director.toml
View File

File diff suppressed because one or more lines are too long

167
runtime/agents/producer.toml
View File

File diff suppressed because one or more lines are too long

159
runtime/agents/technical-director.toml
View File

File diff suppressed because one or more lines are too long

233
skills/brainstorm/DETAILS.md
View File

@@ -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
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.
**Use Codex `request_user_input`** 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
the structured prompt or chat question to capture the decision with concise
labels.
Write full creative analysis in conversation text first, then call
`request_user_input` to capture the decision with concise 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:
- 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)
Bundle these into one Codex `request_user_input` call with three questions:
If the UI supports grouping fields, use exactly these group names. If not,
ask the three questions one at a time.
```json
{
"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
capture the selection.
Present all three. Then use Codex `request_user_input` to 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:
```
structured decision prompt(
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"
```json
{
"questions": [
{
"header": "Concept",
"id": "concept_choice",
"question": "Which concept is the strongest starting point?",
"options": [
{"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.
- `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.
- `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 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,
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.
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 structured prompt:
- 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`.
Collect both verdicts, then present them together using one Codex
`request_user_input` call with up to two questions:
- 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?"
Options: `PC (Steam / Epic)` / `Mobile (iOS / Android)` / `Console` / `Web / Browser` / `Multiple platforms`
- **Target platform**: Use Codex `request_user_input` — "What platforms are you targeting for this game?"
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?"
Options: `Godot` / `Unity` / `Unreal Engine 5` / `No preference — help me decide`
- **Engine experience**: Use Codex `request_user_input` — "Do you already have an engine you work in?"
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**:
- 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.
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
@@ -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:
- 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`
5. Use Codex `request_user_input` 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 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?"
Options: `[A] Yes — write them` / `[B] Revise another section`
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 it` / `[B] Revise another section`
Repeat until the user selects [A].
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.
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.
@@ -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.

15
skills/brainstorm/SKILL.md
View File

@@ -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:
`full` runs key director/lead gates, `lean` runs only PHASE-GATE checks such as
`/gate-check`, and `solo` skips director review gates.
Review mode follows the Claude reference flow: `full` runs the `/brainstorm`
director gates, `lean` skips those ordinary per-skill gates, and `solo` skips
all director 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.
`/brainstorm` writes `design/gdd/game-concept.md`. It defines and records game
pillars inside that concept document; it does not create
`design/gdd/game-pillars.md` as a separate artifact.

9
standards/design-docs.md
View File

@@ -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`
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`.
`references/studio-docs/templates/game-concept.md` and is not a per-system GDD.
If `design/gdd/game-pillars.md` exists, it uses
`references/studio-docs/templates/game-pillars.md` and is also not a
per-system GDD.
- 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