完善 brainstorm 支柱文档与审查强度规则
This commit is contained in:
@@ -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`.
|
||||
Reference in New Issue
Block a user