/gate-check

name: gate-check
description: "Validate readiness to advance between development phases. Produces a PASS/CONCERNS/FAIL verdict with specific blockers and required artifacts. Use when user says 'are we ready to move to X', 'can we advance to production', 'check if we can start the next phase', 'pass the gate'."
argument-hint: "[target-phase: systems-design | technical-setup | pre-production | production | polish | release] [--review full|lean|solo]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Bash, Write, Task, AskUserQuestion
model: opus

Phase Gate Validation

This skill validates whether the project is ready to advance to the next development phase. It checks for required artifacts, quality standards, and blockers.

**Distinct from `/project-stage-detect`**: That skill is diagnostic ("where are we?"). This skill is prescriptive ("are we ready to advance?" with a formal verdict).

Production Stages (7)

The project progresses through these stages:

1. **Concept** — Brainstorming, game concept document 2. **Systems Design** — Mapping systems, writing GDDs 3. **Technical Setup** — Engine config, architecture decisions 4. **Pre-Production** — Prototyping, vertical slice validation 5. **Production** — Feature development (Epic/Feature/Task tracking active) 6. **Polish** — Performance, playtesting, bug fixing 7. **Release** — Launch prep, certification

**When a gate passes**, write the new stage name to `production/stage.txt` (single line, e.g. `Production`). This updates the status line immediately.

---

1. Parse Arguments

**Target phase:** `$ARGUMENTS[0]` (blank = auto-detect current stage, then validate next transition)

Also resolve the review mode (once, store for all gate spawns this run): 1. If `--review [full|lean|solo]` was passed → use that 2. Else read `production/review-mode.txt` → use that value 3. Else → default to `lean`

Note: in `solo` mode, director spawns (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE) are skipped — gate-check becomes artifact-existence checks only. In `lean` mode, all four directors still run (phase gates are the purpose of lean mode).

• **With argument**: `/gate-check production` — validate readiness for that specific phase
• **No argument**: Auto-detect current stage using the same heuristics as

`/project-stage-detect`, then **confirm with the user before running**:

Use `AskUserQuestion`:

• Prompt: "Detected stage: **[current stage]**. Running gate for [Current] → [Next] transition. Is this correct?"
• Options:
• `[A] Yes — run this gate`
• `[B] No — pick a different gate` (if selected, show a second widget listing all gate options: Concept → Systems Design, Systems Design → Technical Setup, Technical Setup → Pre-Production, Pre-Production → Production, Production → Polish, Polish → Release)

Do not skip this confirmation step when no argument is provided.

---

2. Phase Gate Definitions

Gate: Concept → Systems Design

**Required Artifacts:**

• [ ] `design/gdd/game-concept.md` exists and has content
• [ ] Game pillars defined (in concept doc or `design/gdd/game-pillars.md`)
• [ ] Visual Identity Anchor section exists in `design/gdd/game-concept.md` (from brainstorm Phase 4 art-director output)

**Recommended (not blocking):**

• [ ] Concept prototype exists in `prototypes/` with a REPORT.md showing PROCEED verdict

(`/prototype [core-mechanic]`) — skipping this means GDDs may be written for an idea that hasn't been played. Acceptable if the concept is proven by other means.

**Quality Checks:**

• [ ] Game concept has been reviewed (`/design-review` verdict not MAJOR REVISION NEEDED)
• [ ] Core loop is described and understood
• [ ] Target audience is identified
• [ ] Visual Identity Anchor contains a one-line visual rule and at least 2 supporting visual principles

---

Gate: Systems Design → Technical Setup

**Required Artifacts:**

• [ ] Systems index exists at `design/gdd/systems-index.md` with at least MVP systems enumerated
• [ ] All MVP-tier GDDs exist in `design/gdd/` and individually pass `/design-review`
• [ ] A cross-GDD review report exists in `design/gdd/` (from `/review-all-gdds`)

**Quality Checks:**

• [ ] All MVP GDDs pass individual design review (8 required sections, no MAJOR REVISION NEEDED verdict)
• [ ] `/review-all-gdds` verdict is not FAIL (cross-GDD consistency and design theory checks pass)
• [ ] All cross-GDD consistency issues flagged by `/review-all-gdds` are resolved or explicitly accepted
• [ ] System dependencies are mapped in the systems index and are bidirectionally consistent
• [ ] MVP priority tier is defined
• [ ] No stale GDD references flagged (older GDDs updated to reflect decisions made in later GDDs)

---

Gate: Technical Setup → Pre-Production

**Required Artifacts:**

• [ ] Engine chosen (CLAUDE.md Technology Stack is not `[CHOOSE]`)
• [ ] Technical preferences configured (`.claude/docs/technical-preferences.md` populated)
• [ ] Art bible exists at `design/art/art-bible.md` with at least Sections 1–4 (Visual Identity Foundation)
• [ ] At least 3 Architecture Decision Records in `docs/architecture/` covering

Foundation-layer systems (scene management, event architecture, save/load)

• [ ] Engine reference docs exist in `docs/engine-reference/[engine]/`
• [ ] Test framework initialized: `tests/unit/` and `tests/integration/` directories exist
• [ ] CI/CD test workflow exists at `.github/workflows/tests.yml` (or equivalent)
• [ ] At least one example test file exists to confirm the framework is functional
• [ ] Master architecture document exists at `docs/architecture/architecture.md`
• [ ] Architecture traceability index exists at `docs/architecture/requirements-traceability.md`
• [ ] `/architecture-review` has been run (a review report file exists in `docs/architecture/`)
• [ ] `design/accessibility-requirements.md` exists with accessibility tier committed
• [ ] `design/ux/interaction-patterns.md` exists (pattern library