完善 brainstorm 支柱文档与审查强度规则
This commit is contained in:
17
README.md
17
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`
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
247
references/studio-docs/templates/game-pillars.md
Normal file
247
references/studio-docs/templates/game-pillars.md
Normal file
@@ -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`.
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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"
|
||||
|
||||
Reference in New Issue
Block a user