807 lines
32 KiB
Markdown
807 lines
32 KiB
Markdown
# Director Gates — Shared Review Pattern
|
|
|
|
This document defines the standard gate prompts for all director and lead reviews
|
|
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 3 Tier 1 directors,
|
|
all key Tier 2 leads. Any skill, team orchestrator, or workflow may invoke these gates.
|
|
|
|
---
|
|
|
|
## How to Use This Document
|
|
|
|
In any skill, replace an inline director prompt with a reference:
|
|
|
|
```
|
|
Spawn `creative-director` via Task using gate **CD-PILLARS** from
|
|
`.claude/docs/director-gates.md`.
|
|
```
|
|
|
|
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 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.
|
|
|
|
**Per-run override**: any gate-using skill accepts `--review [full|lean|solo]` as an
|
|
argument. This overrides the global config for that run only.
|
|
|
|
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
|
|
```
|
|
|
|
| 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 |
|
|
|
|
**Check pattern — apply before every gate spawn:**
|
|
|
|
```
|
|
Before spawning gate [GATE-ID]:
|
|
1. If skill was called with --review [mode], use that
|
|
2. Else read production/review-mode.txt
|
|
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)
|
|
Note: "[GATE-ID] skipped — Lean mode"
|
|
- full → spawn as normal
|
|
```
|
|
|
|
---
|
|
|
|
## Invocation Pattern (copy into any skill)
|
|
|
|
**MANDATORY: Resolve review mode before every gate spawn.** Never spawn a gate without checking. The resolved mode is determined once per skill run:
|
|
1. If skill was called with `--review [mode]`, use that
|
|
2. Else read `production/review-mode.txt`
|
|
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
|
|
|
|
```
|
|
# Apply mode check, then:
|
|
Spawn `[agent-name]` via Task:
|
|
- Gate: [GATE-ID] (see .claude/docs/director-gates.md)
|
|
- Context: [fields listed under that gate]
|
|
- Await the verdict before proceeding.
|
|
```
|
|
|
|
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] agents simultaneously via Task — issue all Task calls before
|
|
waiting for any result. Collect all verdicts before proceeding.
|
|
```
|
|
|
|
---
|
|
|
|
## Standard Verdict Format
|
|
|
|
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 `AskUserQuestion` — options: `Revise flagged items` / `Accept and proceed` / `Discuss further` |
|
|
| **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
|
|
strictest verdict — one NOT READY overrides all READY verdicts.
|
|
|
|
---
|
|
|
|
## Recording Gate Outcomes
|
|
|
|
After a gate resolves, record the verdict in the relevant document's status header:
|
|
|
|
```markdown
|
|
> **[Director] Review ([GATE-ID])**: APPROVED [date] / CONCERNS (accepted) [date] / REVISED [date]
|
|
```
|
|
|
|
For phase gates, record in `docs/architecture/architecture.md` or
|
|
`production/session-state/active.md` as appropriate.
|
|
|
|
---
|
|
|
|
## Tier 1 — Creative Director Gates
|
|
|
|
Agent: `creative-director` | Model tier: Opus | Domain: Vision, pillars, player experience
|
|
|
|
---
|
|
|
|
### CD-PILLARS — Pillar Stress Test
|
|
|
|
**Trigger**: After game pillars and anti-pillars are defined (brainstorm Phase 4,
|
|
or any time pillars are revised)
|
|
|
|
**Context to pass**:
|
|
- Full pillar set with names, definitions, and design tests
|
|
- Anti-pillars list
|
|
- Core fantasy statement
|
|
- Unique hook ("Like X, AND ALSO Y")
|
|
|
|
**Prompt**:
|
|
> "Review these game pillars. Are they falsifiable — could a real design decision
|
|
> actually fail this pillar? Do they create meaningful tension with each other? Do
|
|
> 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)."
|
|
|
|
**Verdicts**: APPROVE / CONCERNS / REJECT
|
|
|
|
---
|
|
|
|
### CD-GDD-ALIGN — GDD Pillar Alignment Check
|
|
|
|
**Trigger**: After a system GDD is authored (design-system, quick-design, or any
|
|
workflow that produces a GDD)
|
|
|
|
**Context to pass**:
|
|
- GDD file path
|
|
- Game pillars (from `design/gdd/game-concept.md` or `design/gdd/game-pillars.md`)
|
|
- MDA aesthetics target for this game
|
|
- System's stated Player Fantasy section
|
|
|
|
**Prompt**:
|
|
> "Review this system GDD for pillar alignment. Does every section serve the stated
|
|
> pillars? Are there mechanics or rules that contradict or weaken a pillar? Does
|
|
> the Player Fantasy section match the game's core fantasy? Return APPROVE, CONCERNS
|
|
> [specific sections with issues], or REJECT [pillar violations that must be
|
|
> redesigned before this system is implementable]."
|
|
|
|
**Verdicts**: APPROVE / CONCERNS / REJECT
|
|
|
|
---
|
|
|
|
### CD-SYSTEMS — Systems Decomposition Vision Check
|
|
|
|
**Trigger**: After the systems index is written by `/map-systems` — validates the
|
|
complete system set before GDD authoring begins
|
|
|
|
**Context to pass**:
|
|
- Systems index path (`design/gdd/systems-index.md`)
|
|
- Game pillars and core fantasy (from `design/gdd/game-concept.md`)
|
|
- Priority tier assignments (MVP / Vertical Slice / Alpha / Full Vision)
|
|
- Any high-risk or bottleneck systems identified in the dependency map
|
|
|
|
**Prompt**:
|
|
> "Review this systems decomposition against the game's design pillars. Does the
|
|
> full set of MVP-tier systems collectively deliver the core fantasy? Are there
|
|
> systems whose mechanics don't serve any stated pillar — indicating they may be
|
|
> scope creep? Are there pillar-critical player experiences that have no system
|
|
> assigned to deliver them? Are any systems missing that the core loop requires?
|
|
> Return APPROVE (systems serve the vision), CONCERNS [specific gaps or
|
|
> misalignments with their pillar implications], or REJECT [fundamental gaps —
|
|
> the decomposition misses critical design intent and must be revised before GDD
|
|
> authoring begins]."
|
|
|
|
**Verdicts**: APPROVE / CONCERNS / REJECT
|
|
|
|
---
|
|
|
|
### CD-NARRATIVE — Narrative Consistency Check
|
|
|
|
**Trigger**: After narrative GDDs, lore documents, dialogue specs, or world-building
|
|
documents are authored (team-narrative, design-system for story systems, writer
|
|
deliverables)
|
|
|
|
**Context to pass**:
|
|
- Document file path(s)
|
|
- Game pillars
|
|
- Narrative direction brief or tone guide (if exists at `design/narrative/`)
|
|
- Any existing lore that the new document references
|
|
|
|
**Prompt**:
|
|
> "Review this narrative content for consistency with the game's pillars and
|
|
> established world rules. Does the tone match the game's established voice? Are
|
|
> there contradictions with existing lore or world-building? Does the content serve
|
|
> the player experience pillar? Return APPROVE, CONCERNS [specific inconsistencies],
|
|
> or REJECT [contradictions that break world coherence]."
|
|
|
|
**Verdicts**: APPROVE / CONCERNS / REJECT
|
|
|
|
---
|
|
|
|
### CD-PLAYTEST — Player Experience Validation
|
|
|
|
**Trigger**: After playtest reports are generated (`/playtest-report`), or after
|
|
any session that produces player feedback
|
|
|
|
**Context to pass**:
|
|
- Playtest report file path
|
|
- Game pillars and core fantasy statement
|
|
- The specific hypothesis being tested
|
|
|
|
**Prompt**:
|
|
> "Review this playtest report against the game's design pillars and core fantasy.
|
|
> Is the player experience matching the intended fantasy? Are there systematic issues
|
|
> that represent pillar drift — mechanics that feel fine in isolation but undermine
|
|
> the intended experience? Return APPROVE (core fantasy is landing), CONCERNS [gaps
|
|
> between intended and actual experience], or REJECT [core fantasy is not present —
|
|
> redesign needed before further playtesting]."
|
|
|
|
**Verdicts**: APPROVE / CONCERNS / REJECT
|
|
|
|
---
|
|
|
|
### CD-PHASE-GATE — Creative Readiness at Phase Transition
|
|
|
|
**Trigger**: Always at `/gate-check` — spawn in parallel with TD-PHASE-GATE and PR-PHASE-GATE
|
|
|
|
**Context to pass**:
|
|
- Target phase name
|
|
- List of all artifacts present (file paths)
|
|
- Game pillars and core fantasy
|
|
|
|
**Prompt**:
|
|
> "Review the current project state for [target phase] gate readiness from a
|
|
> creative direction perspective. Are the game pillars faithfully represented in
|
|
> all design artifacts? Does the current state preserve the core fantasy? Are there
|
|
> any design decisions across GDDs or architecture that compromise the intended
|
|
> player experience? Return READY, CONCERNS [list], or NOT READY [blockers]."
|
|
|
|
**Verdicts**: READY / CONCERNS / NOT READY
|
|
|
|
---
|
|
|
|
## Tier 1 — Technical Director Gates
|
|
|
|
Agent: `technical-director` | Model tier: Opus | Domain: Architecture, engine risk, performance
|
|
|
|
---
|
|
|
|
### TD-SYSTEM-BOUNDARY — System Boundary Architecture Review
|
|
|
|
**Trigger**: After `/map-systems` Phase 3 dependency mapping is agreed but before
|
|
GDD authoring begins — validates that the system structure is architecturally
|
|
sound before teams invest in writing GDDs against it
|
|
|
|
**Context to pass**:
|
|
- Systems index path (or the dependency map summary if index not yet written)
|
|
- Layer assignments (Foundation / Core / Feature / Presentation / Polish)
|
|
- The full dependency graph (what each system depends on)
|
|
- Any bottleneck systems flagged (many dependents)
|
|
- Any circular dependencies found and their proposed resolutions
|
|
|
|
**Prompt**:
|
|
> "Review this systems decomposition from an architectural perspective before GDD
|
|
> authoring begins. Are the system boundaries clean — does each system own a
|
|
> distinct concern with minimal overlap? Are there God Object risks (systems doing
|
|
> too much)? Does the dependency ordering create implementation-sequencing problems?
|
|
> Are there implicit shared-state problems in the proposed boundaries that will
|
|
> cause tight coupling when implemented? Are any Foundation-layer systems actually
|
|
> dependent on Feature-layer systems (inverted dependency)? Return APPROVE
|
|
> (boundaries are architecturally sound — proceed to GDD authoring), CONCERNS
|
|
> [specific boundary issues to address in the GDDs themselves], or REJECT
|
|
> [fundamental boundary problems — the system structure will cause architectural
|
|
> issues and must be restructured before any GDD is written]."
|
|
|
|
**Verdicts**: APPROVE / CONCERNS / REJECT
|
|
|
|
---
|
|
|
|
### TD-FEASIBILITY — Technical Feasibility Assessment
|
|
|
|
**Trigger**: After biggest technical risks are identified during scope/feasibility
|
|
(brainstorm Phase 6, quick-design, or any early-stage concept with technical unknowns)
|
|
|
|
**Context to pass**:
|
|
- Concept's core loop description
|
|
- Platform target
|
|
- Engine choice (or "undecided")
|
|
- List of identified technical risks
|
|
|
|
**Prompt**:
|
|
> "Review these technical risks for a [genre] game targeting [platform] using
|
|
> [engine or 'undecided engine']. Flag any HIGH risk items that could invalidate
|
|
> the concept as described, any risks that are engine-specific and should influence
|
|
> the engine choice, and any risks that are commonly underestimated by solo
|
|
> developers. Return VIABLE (risks are manageable), CONCERNS [list with mitigation
|
|
> suggestions], or HIGH RISK [blockers that require concept or scope revision]."
|
|
|
|
**Verdicts**: VIABLE / CONCERNS / HIGH RISK
|
|
|
|
---
|
|
|
|
### TD-ARCHITECTURE — Architecture Sign-Off
|
|
|
|
**Trigger**: After the master architecture document is drafted (`/create-architecture`
|
|
Phase 7), and after any major architecture revision
|
|
|
|
**Context to pass**:
|
|
- Architecture document path (`docs/architecture/architecture.md`)
|
|
- Technical requirements baseline (TR-IDs and count)
|
|
- ADR list with statuses
|
|
- Engine knowledge gap inventory
|
|
|
|
**Prompt**:
|
|
> "Review this master architecture document for technical soundness. Check: (1) Is
|
|
> every technical requirement from the baseline covered by an architectural decision?
|
|
> (2) Are all HIGH risk engine domains explicitly addressed or flagged as open
|
|
> questions? (3) Are the API boundaries clean, minimal, and implementable? (4) Are
|
|
> Foundation layer ADR gaps resolved before implementation begins? Return APPROVE,
|
|
> CONCERNS [list], or REJECT [blockers that must be resolved before coding starts]."
|
|
|
|
**Verdicts**: APPROVE / CONCERNS / REJECT
|
|
|
|
---
|
|
|
|
### TD-ADR — Architecture Decision Review
|
|
|
|
**Trigger**: After an individual ADR is authored (`/architecture-decision`), before
|
|
it is marked Accepted
|
|
|
|
**Context to pass**:
|
|
- ADR file path
|
|
- Engine version and knowledge gap risk level for the domain
|
|
- Related ADRs (if any)
|
|
|
|
**Prompt**:
|
|
> "Review this Architecture Decision Record. Does it have a clear problem statement
|
|
> and rationale? Are the rejected alternatives genuinely considered? Does the
|
|
> Consequences section acknowledge the trade-offs honestly? Is the engine version
|
|
> stamped? Are post-cutoff API risks flagged? Does it link to the GDD requirements
|
|
> it covers? Return APPROVE, CONCERNS [specific gaps], or REJECT [the decision is
|
|
> underspecified or makes unsound technical assumptions]."
|
|
|
|
**Verdicts**: APPROVE / CONCERNS / REJECT
|
|
|
|
---
|
|
|
|
### TD-ENGINE-RISK — Engine Version Risk Review
|
|
|
|
**Trigger**: When making architecture decisions that touch post-cutoff engine APIs,
|
|
or before finalizing any engine-specific implementation approach
|
|
|
|
**Context to pass**:
|
|
- The specific API or feature being used
|
|
- Engine version and LLM knowledge cutoff (from `docs/engine-reference/[engine]/VERSION.md`)
|
|
- Relevant excerpt from breaking-changes or deprecated-apis docs
|
|
|
|
**Prompt**:
|
|
> "Review this engine API usage against the version reference. Is this API present
|
|
> in [engine version]? Has its signature, behaviour, or namespace changed since the
|
|
> LLM knowledge cutoff? Are there known deprecations or post-cutoff alternatives?
|
|
> Return APPROVE (safe to use as described), CONCERNS [verify before implementing],
|
|
> or REJECT [API has changed — provide corrected approach]."
|
|
|
|
**Verdicts**: APPROVE / CONCERNS / REJECT
|
|
|
|
---
|
|
|
|
### TD-PHASE-GATE — Technical Readiness at Phase Transition
|
|
|
|
**Trigger**: Always at `/gate-check` — spawn in parallel with CD-PHASE-GATE and PR-PHASE-GATE
|
|
|
|
**Context to pass**:
|
|
- Target phase name
|
|
- Architecture document path (if exists)
|
|
- Engine reference path
|
|
- ADR list
|
|
|
|
**Prompt**:
|
|
> "Review the current project state for [target phase] gate readiness from a
|
|
> technical direction perspective. Is the architecture sound for this phase? Are
|
|
> all high-risk engine domains addressed? Are performance budgets realistic and
|
|
> documented? Are Foundation-layer decisions complete enough to begin implementation?
|
|
> Return READY, CONCERNS [list], or NOT READY [blockers]."
|
|
|
|
**Verdicts**: READY / CONCERNS / NOT READY
|
|
|
|
---
|
|
|
|
## Tier 1 — Producer Gates
|
|
|
|
Agent: `producer` | Model tier: Opus | Domain: Scope, timeline, dependencies, production risk
|
|
|
|
---
|
|
|
|
### PR-SCOPE — Scope and Timeline Validation
|
|
|
|
**Trigger**: After scope tiers are defined (brainstorm Phase 6, quick-design, or
|
|
any workflow that produces an MVP definition and timeline estimate)
|
|
|
|
**Context to pass**:
|
|
- Full vision scope description
|
|
- MVP definition
|
|
- Timeline estimate
|
|
- Team size (solo / small team / etc.)
|
|
- Scope tiers (what ships if time runs out)
|
|
|
|
**Prompt**:
|
|
> "Review this scope estimate. Is the MVP achievable in the stated timeline for
|
|
> the stated team size? Are the scope tiers correctly ordered by risk — does each
|
|
> tier deliver a shippable product if work stops there? What is the most likely
|
|
> cut point under time pressure, and is it a graceful fallback or a broken product?
|
|
> Return REALISTIC (scope matches capacity), OPTIMISTIC [specific adjustments
|
|
> recommended], or UNREALISTIC [blockers — timeline or MVP must be revised]."
|
|
|
|
**Verdicts**: REALISTIC / OPTIMISTIC / UNREALISTIC
|
|
|
|
---
|
|
|
|
### PR-SPRINT — Sprint Feasibility Review
|
|
|
|
**Trigger**: Before finalising a sprint plan (`/sprint-plan`), and after any
|
|
mid-sprint scope change
|
|
|
|
**Context to pass**:
|
|
- Proposed sprint story list (titles, estimates, dependencies)
|
|
- Team capacity (hours available)
|
|
- Current sprint backlog debt (if any)
|
|
- Milestone constraints
|
|
|
|
**Prompt**:
|
|
> "Review this sprint plan for feasibility. Is the story load realistic for the
|
|
> available capacity? Are stories correctly ordered by dependency? Are there hidden
|
|
> dependencies between stories that could block the sprint mid-way? Are any stories
|
|
> underestimated given their technical complexity? Return REALISTIC (plan is
|
|
> achievable), CONCERNS [specific risks], or UNREALISTIC [sprint must be
|
|
> descoped — identify which stories to defer]."
|
|
|
|
**Verdicts**: REALISTIC / CONCERNS / UNREALISTIC
|
|
|
|
---
|
|
|
|
### PR-MILESTONE — Milestone Risk Assessment
|
|
|
|
**Trigger**: At milestone review (`/milestone-review`), at mid-sprint retrospectives,
|
|
or when a scope change is proposed that affects the milestone
|
|
|
|
**Context to pass**:
|
|
- Milestone definition and target date
|
|
- Current completion percentage
|
|
- Blocked stories count
|
|
- Sprint velocity data (if available)
|
|
|
|
**Prompt**:
|
|
> "Review this milestone status. Based on current velocity and blocked story count,
|
|
> will this milestone hit its target date? What are the top 3 production risks
|
|
> between now and the milestone? Are there scope items that should be cut to protect
|
|
> the milestone date vs. items that are non-negotiable? Return ON TRACK, AT RISK
|
|
> [specific mitigations], or OFF TRACK [date must slip or scope must cut — provide
|
|
> both options]."
|
|
|
|
**Verdicts**: ON TRACK / AT RISK / OFF TRACK
|
|
|
|
---
|
|
|
|
### PR-EPIC — Epic Structure Feasibility Review
|
|
|
|
**Trigger**: After epics are defined by `/create-epics`, before stories are
|
|
broken out — validates the epic structure is producible before `/create-stories`
|
|
is invoked
|
|
|
|
**Context to pass**:
|
|
- Epic definition file paths (all epics just created)
|
|
- Epic index path (`production/epics/index.md`)
|
|
- Milestone timeline and target dates
|
|
- Team capacity (solo / small team / size)
|
|
- Layer being epiced (Foundation / Core / Feature / etc.)
|
|
|
|
**Prompt**:
|
|
> "Review this epic structure for production feasibility before story breakdown
|
|
> begins. Are the epic boundaries scoped appropriately — could each epic realistically
|
|
> complete before a milestone deadline? Are epics correctly ordered by system
|
|
> dependency — does any epic require another epic's output before it can start?
|
|
> Are any epics underscoped (too small, should merge) or overscoped (too large,
|
|
> should split into 2-3 focused epics)? Are the Foundation-layer epics scoped to
|
|
> allow Core-layer epics to begin at the start of the next sprint after Foundation
|
|
> completes? Return REALISTIC (epic structure is producible), CONCERNS [specific
|
|
> structural adjustments before stories are written], or UNREALISTIC [epics must
|
|
> be split, merged, or reordered — story breakdown cannot begin until resolved]."
|
|
|
|
**Verdicts**: REALISTIC / CONCERNS / UNREALISTIC
|
|
|
|
---
|
|
|
|
### PR-PHASE-GATE — Production Readiness at Phase Transition
|
|
|
|
**Trigger**: Always at `/gate-check` — spawn in parallel with CD-PHASE-GATE and TD-PHASE-GATE
|
|
|
|
**Context to pass**:
|
|
- Target phase name
|
|
- Sprint and milestone artifacts present
|
|
- Team size and capacity
|
|
- Current blocked story count
|
|
|
|
**Prompt**:
|
|
> "Review the current project state for [target phase] gate readiness from a
|
|
> production perspective. Is the scope realistic for the stated timeline and team
|
|
> size? Are dependencies properly ordered so the team can actually execute in
|
|
> sequence? Are there milestone or sprint risks that could derail the phase within
|
|
> the first two sprints? Return READY, CONCERNS [list], or NOT READY [blockers]."
|
|
|
|
**Verdicts**: READY / CONCERNS / NOT READY
|
|
|
|
---
|
|
|
|
## Tier 1 — Art Director Gates
|
|
|
|
Agent: `art-director` | Model tier: Sonnet | Domain: Visual identity, art bible, visual production readiness
|
|
|
|
---
|
|
|
|
### AD-CONCEPT-VISUAL — Visual Identity Anchor
|
|
|
|
**Trigger**: After game pillars are locked (brainstorm Phase 4), in parallel with CD-PILLARS
|
|
|
|
**Context to pass**:
|
|
- Game concept (elevator pitch, core fantasy, unique hook)
|
|
- Full pillar set with names, definitions, and design tests
|
|
- Target platform (if known)
|
|
- Any reference games or visual touchstones mentioned by the user
|
|
|
|
**Prompt**:
|
|
> "Based on these game pillars and core concept, propose 2-3 distinct visual identity
|
|
> directions. For each direction provide: (1) a one-line visual rule that could guide
|
|
> all visual decisions (e.g., 'everything must move', 'beauty is in the decay'), (2)
|
|
> mood and atmosphere targets, (3) shape language (sharp/rounded/organic/geometric
|
|
> emphasis), (4) color philosophy (palette direction, what colors mean in this world).
|
|
> Be specific — avoid generic descriptions. One direction should directly serve the
|
|
> primary design pillar. Name each direction. Recommend which best serves the stated
|
|
> pillars and explain why."
|
|
|
|
**Verdicts**: CONCEPTS (multiple valid options — user selects) / STRONG (one direction clearly dominant) / CONCERNS (pillars don't provide enough direction to differentiate visual identity yet)
|
|
|
|
---
|
|
|
|
### AD-ART-BIBLE — Art Bible Sign-Off
|
|
|
|
**Trigger**: After the art bible is drafted (`/art-bible`), before asset production begins
|
|
|
|
**Context to pass**:
|
|
- Art bible path (`design/art/art-bible.md`)
|
|
- Game pillars and core fantasy
|
|
- Platform and performance constraints (from `.claude/docs/technical-preferences.md` if configured)
|
|
- Visual identity anchor chosen during brainstorm (from `design/gdd/game-concept.md`)
|
|
|
|
**Prompt**:
|
|
> "Review this art bible for completeness and internal consistency. Does the color
|
|
> system match the mood targets? Does the shape language follow from the visual
|
|
> identity statement? Are the asset standards achievable within the platform
|
|
> constraints? Does the character design direction give artists enough to work from
|
|
> without over-specifying? Are there contradictions between sections? Would an
|
|
> outsourcing team be able to produce assets from this document without additional
|
|
> briefing? Return APPROVE (art bible is production-ready), CONCERNS [specific
|
|
> sections needing clarification], or REJECT [fundamental inconsistencies that must
|
|
> be resolved before asset production begins]."
|
|
|
|
**Verdicts**: APPROVE / CONCERNS / REJECT
|
|
|
|
---
|
|
|
|
### AD-PHASE-GATE — Visual Readiness at Phase Transition
|
|
|
|
**Trigger**: Always at `/gate-check` — spawn in parallel with CD-PHASE-GATE, TD-PHASE-GATE, and PR-PHASE-GATE
|
|
|
|
**Context to pass**:
|
|
- Target phase name
|
|
- List of all art/visual artifacts present (file paths)
|
|
- Visual identity anchor from `design/gdd/game-concept.md` (if present)
|
|
- Art bible path if it exists (`design/art/art-bible.md`)
|
|
|
|
**Prompt**:
|
|
> "Review the current project state for [target phase] gate readiness from a visual
|
|
> direction perspective. Is the visual identity established and documented at the
|
|
> level this phase requires? Are the right visual artifacts in place? Would visual
|
|
> teams be able to begin their work without visual direction gaps that cause costly
|
|
> rework later? Are there visual decisions that are being deferred past their latest
|
|
> responsible moment? Return READY, CONCERNS [specific visual direction gaps that
|
|
> could cause production rework], or NOT READY [visual blockers that must exist
|
|
> before this phase can succeed — specify what artifact is missing and why it
|
|
> matters at this stage]."
|
|
|
|
**Verdicts**: READY / CONCERNS / NOT READY
|
|
|
|
---
|
|
|
|
## Tier 2 — Lead Gates
|
|
|
|
These gates are invoked by orchestration skills and senior skills when a domain
|
|
specialist's feasibility sign-off is needed. Tier 2 leads use Sonnet (default).
|
|
|
|
---
|
|
|
|
### LP-FEASIBILITY — Lead Programmer Implementation Feasibility
|
|
|
|
**Trigger**: After the master architecture document is written (`/create-architecture`
|
|
Phase 7b), or when a new architectural pattern is proposed
|
|
|
|
**Context to pass**:
|
|
- Architecture document path
|
|
- Technical requirements baseline summary
|
|
- ADR list with statuses
|
|
|
|
**Prompt**:
|
|
> "Review this architecture for implementation feasibility. Flag: (a) any decisions
|
|
> that would be difficult or impossible to implement with the stated engine and
|
|
> language, (b) any missing interface definitions that programmers would need to
|
|
> invent themselves, (c) any patterns that create avoidable technical debt or
|
|
> that contradict standard [engine] idioms. Return FEASIBLE, CONCERNS [list], or
|
|
> INFEASIBLE [blockers that make this architecture unimplementable as written]."
|
|
|
|
**Verdicts**: FEASIBLE / CONCERNS / INFEASIBLE
|
|
|
|
---
|
|
|
|
### LP-CODE-REVIEW — Lead Programmer Code Review
|
|
|
|
**Trigger**: After a dev story is implemented (`/dev-story`, `/story-done`), or
|
|
as part of `/code-review`
|
|
|
|
**Context to pass**:
|
|
- Implementation file paths
|
|
- Story file path (for acceptance criteria)
|
|
- Relevant GDD section
|
|
- ADR that governs this system
|
|
|
|
**Prompt**:
|
|
> "Review this implementation against the story acceptance criteria and governing
|
|
> ADR. Does the code match the architecture boundary definitions? Are there
|
|
> violations of the coding standards or forbidden patterns? Is the public API
|
|
> testable and documented? Are there any correctness issues against the GDD rules?
|
|
> Return APPROVE, CONCERNS [specific issues], or REJECT [must be revised before merge]."
|
|
|
|
**Verdicts**: APPROVE / CONCERNS / REJECT
|
|
|
|
---
|
|
|
|
### QL-STORY-READY — QA Lead Story Readiness Check
|
|
|
|
**Trigger**: Before a story is accepted into a sprint — invoked by `/create-stories`,
|
|
`/story-readiness`, and `/sprint-plan` during story selection
|
|
|
|
**Context to pass**:
|
|
- Story file path
|
|
- Story type (Logic / Integration / Visual/Feel / UI / Config/Data)
|
|
- Acceptance criteria list (verbatim from the story)
|
|
- The GDD requirement (TR-ID and text) the story covers
|
|
|
|
**Prompt**:
|
|
> "Review this story's acceptance criteria for testability before it enters the
|
|
> sprint. Are all criteria specific enough that a developer would know unambiguously
|
|
> when they are done? For Logic-type stories: can every criterion be verified with
|
|
> an automated test? For Integration stories: is each criterion observable in a
|
|
> controlled test environment? Flag criteria that are too vague to implement
|
|
> against, and flag criteria that require a full game build to test (mark these
|
|
> DEFERRED, not BLOCKED). Return ADEQUATE (criteria are implementable as written),
|
|
> GAPS [specific criteria needing refinement], or INADEQUATE [criteria are too
|
|
> vague — story must be revised before sprint inclusion]."
|
|
|
|
**Verdicts**: ADEQUATE / GAPS / INADEQUATE
|
|
|
|
---
|
|
|
|
### QL-TEST-COVERAGE — QA Lead Test Coverage Review
|
|
|
|
**Trigger**: After implementation stories are complete, before marking an epic
|
|
done, or at `/gate-check` Production → Polish
|
|
|
|
**Context to pass**:
|
|
- List of implemented stories with story types (Logic / Integration / Visual / UI / Config)
|
|
- Test file paths in `tests/`
|
|
- GDD acceptance criteria for the system
|
|
|
|
**Prompt**:
|
|
> "Review the test coverage for these implementation stories. Are all Logic stories
|
|
> covered by passing unit tests? Are Integration stories covered by integration
|
|
> tests or documented playtests? Are the GDD acceptance criteria each mapped to at
|
|
> least one test? Are there untested edge cases from the GDD Edge Cases section?
|
|
> Return ADEQUATE (coverage meets standards), GAPS [specific missing tests], or
|
|
> INADEQUATE [critical logic is untested — do not advance]."
|
|
|
|
**Verdicts**: ADEQUATE / GAPS / INADEQUATE
|
|
|
|
---
|
|
|
|
### ND-CONSISTENCY — Narrative Director Consistency Check
|
|
|
|
**Trigger**: After writer deliverables (dialogue, lore, item descriptions) are
|
|
authored, or when a design decision has narrative implications
|
|
|
|
**Context to pass**:
|
|
- Document or content file path(s)
|
|
- Narrative bible or tone guide path (if exists)
|
|
- Relevant world-building rules
|
|
- Character or faction profiles affected
|
|
|
|
**Prompt**:
|
|
> "Review this narrative content for internal consistency and adherence to
|
|
> established world rules. Are character voices consistent with their established
|
|
> profiles? Does the lore contradict any established facts? Is the tone consistent
|
|
> with the game's narrative direction? Return APPROVE, CONCERNS [specific
|
|
> inconsistencies to fix], or REJECT [contradictions that break the narrative
|
|
> foundation]."
|
|
|
|
**Verdicts**: APPROVE / CONCERNS / REJECT
|
|
|
|
---
|
|
|
|
### AD-VISUAL — Art Director Visual Consistency Review
|
|
|
|
**Trigger**: After art direction decisions are made, when new asset types are
|
|
introduced, or when a tech art decision affects visual style
|
|
|
|
**Context to pass**:
|
|
- Art bible path (if exists at `design/art/art-bible.md`)
|
|
- The specific asset type, style decision, or visual direction being reviewed
|
|
- Reference images or style descriptions
|
|
- Platform and performance constraints
|
|
|
|
**Prompt**:
|
|
> "Review this visual direction decision for consistency with the established art
|
|
> style and production constraints. Does it match the art bible? Is it achievable
|
|
> within the platform's performance budget? Are there asset pipeline implications
|
|
> that create technical risk? Return APPROVE, CONCERNS [specific adjustments], or
|
|
> REJECT [style violation or production risk that must be resolved first]."
|
|
|
|
**Verdicts**: APPROVE / CONCERNS / REJECT
|
|
|
|
---
|
|
|
|
## Parallel Gate Protocol
|
|
|
|
When a workflow requires multiple directors at the same checkpoint (most common
|
|
at `/gate-check`), spawn all agents simultaneously:
|
|
|
|
```
|
|
Spawn in parallel (issue all Task calls 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
|
|
4. art-director → gate AD-PHASE-GATE
|
|
|
|
Collect all four verdicts, then apply escalation rules:
|
|
- Any NOT READY / REJECT → overall verdict minimum FAIL
|
|
- Any CONCERNS → overall verdict minimum CONCERNS
|
|
- All READY / APPROVE → eligible for PASS (still subject to artifact checks)
|
|
```
|
|
|
|
---
|
|
|
|
## Adding New Gates
|
|
|
|
When a new gate is needed for a new skill or workflow:
|
|
|
|
1. Assign a gate ID: `[DIRECTOR-PREFIX]-[DESCRIPTIVE-SLUG]`
|
|
- Prefixes: `CD-` `TD-` `PR-` `LP-` `QL-` `ND-` `AD-`
|
|
- Add new prefixes for new agents: `audio-director` → `AU-`, `ux-designer` → `UX-`
|
|
2. Add the gate under the appropriate director section with all five fields:
|
|
Trigger, Context to pass, Prompt, Verdicts, and any special handling notes
|
|
3. Reference it in skills by ID only — never copy the prompt text into the skill
|
|
|
|
---
|
|
|
|
## Gate Coverage by Stage
|
|
|
|
| Stage | Required Gates | Optional Gates |
|
|
|-------|---------------|----------------|
|
|
| **Concept** | CD-PILLARS, AD-CONCEPT-VISUAL | TD-FEASIBILITY, PR-SCOPE |
|
|
| **Systems Design** | TD-SYSTEM-BOUNDARY, CD-SYSTEMS, PR-SCOPE, CD-GDD-ALIGN (per GDD) | ND-CONSISTENCY, AD-VISUAL |
|
|
| **Technical Setup** | TD-ARCHITECTURE, TD-ADR (per ADR), LP-FEASIBILITY, AD-ART-BIBLE | TD-ENGINE-RISK |
|
|
| **Pre-Production** | PR-EPIC, QL-STORY-READY (per story), PR-SPRINT, all four PHASE-GATEs (via gate-check) | CD-PLAYTEST |
|
|
| **Production** | LP-CODE-REVIEW (per story), QL-STORY-READY, PR-SPRINT (per sprint), QL-TEST-COVERAGE (per sprint close-out) | PR-MILESTONE, AD-VISUAL |
|
|
| **Polish** | QL-TEST-COVERAGE, CD-PLAYTEST, PR-MILESTONE | AD-VISUAL |
|
|
| **Release** | All four PHASE-GATEs (via gate-check) | QL-TEST-COVERAGE |
|