gate-check

User Guide

• When to use: Validate readiness to advance between development phases. Produces a PASS/CONCERNS/FAIL verdict with specific blockers and required artifacts. Supports both game and general product domains — auto-detects domain from the concept document.
• Inputs: Command arguments: /gate-check [target-phase] [--review full|lean|solo]. Game phases: systems-design | technical-setup | pre-production | production | polish | release. Product phases: specification | architecture | pre-implementation | implementation | verification | release; project artifacts referenced below; user decisions and approvals before writes.
• Outputs: Primary artifacts, reports, or conversation guidance described below; write files only after user approval.
• Memory-bank writes: memory_bank/t0_core/current_state.md, memory_bank/t3_archive/gate_runs/, memory_bank/t3_archive/gate_runs/gate-[phase]-[YYYY-MM-DD].md.
• Next steps: Follow the workflow hand-off or next-step guidance below; recommendations do not auto-run and require explicit user command/approval.

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).

Domain detection. The concept document at design/cdd/ reveals the domain:

• 游戏专用: game-concept.md exists — game stage names and game-specific checks
• 通用产品: product-concept.md exists — product stage names and product-specific checks

Sections below are marked [通用场景] (both domains), [游戏专用] (game-domain), or [通用产品] (product-domain).

Production Stages (7)

[通用场景] The project progresses through these stages. Stage names vary by domain:

[游戏专用] Game stages:

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

[通用产品] Product stages:

1. Concept — Ideation, product concept document, constitution
2. Specification — Mapping modules, writing CDDs
3. Architecture — Stack config, architecture decisions
4. Pre-Implementation — Prototyping, user validation
5. Implementation — Feature development
6. Verification — Performance, user testing, bug fixing
7. Release — Launch prep, deployment validation

Gate policy: governed advisory. The gate must run before normal advancement; PASS may update production/stage.txt after user confirmation, CONCERNS may update it only with a recorded risk note, and FAIL does not update it unless the user explicitly overrides with a risk note.

Required source of truth: workflow/workflow-catalog.yaml is the only source for normal-progression blockers. A required: true catalog step can be a missing-artifact blocker. Optional steps, later-phase steps, and required_when steps outside the active gate can only appear as CONCERNS or follow-up actions unless a quality failure directly invalidates the current phase goal.

Boundary clarifications:

• [Game] design/art/art-bible.md is a Concept optional artifact, not a Technical Setup blocker.
• [Product] design/ux/interaction-patterns.md is a Pre-Production required_when artifact, not an Architecture blocker.
• [Product] design/ux/surface-profile.md records N/A decisions for product surface artifacts when applicability is ambiguous.
• /qa-plan is optional during Production by default; missing QA plans or /team-qa sign-off become release-readiness concerns unless the project has explicitly opted into strict QA.
• [Product] one user-test/workflow validation is required before Implementation; three cumulative product validation sessions are required before Release during Polish / Verification.

---

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. Supports both game phase names (systems-design, technical-setup, pre-production, production, polish, release) and product phase names (specification, architecture, pre-implementation, implementation, verification, release). The skill auto-detects the domain from the concept document at design/cdd/.

• 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] ([domain]). 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 appropriate to the detected domain: [游戏专用] Concept → Systems Design, Systems Design → Technical Setup, Technical Setup → Pre-Production, Pre-Production → Production, Production → Polish, Polish → Release. [通用产品] Concept → Specification, Specification → Architecture, Architecture → Pre-Implementation, Pre-Implementation → Implementation, Implementation → Verification, Verification → Release)

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

---

2. Phase Gate Definitions

For every gate below, normal-progression required artifacts are generated from workflow/workflow-catalog.yaml into workflow/generated/gate-required-artifacts.md.

Before checking a gate, read the generated file and use the section matching the active transition and domain. Do not add hand-written required artifact rows in this skill; hand-authored content belongs under Quality / Risk Checks.

Gate: Concept → Systems Design / Specification

[通用场景] This gate validates readiness to move from concept exploration to structured design.

[游戏专用] Game: Concept → Systems Design

Required Artifacts: Use workflow/generated/gate-required-artifacts.md, section Game: Concept -> Systems Design.

Quality Checks:

• Game concept has been reviewed (/design-review verdict not MAJOR REVISION NEEDED)
• Core loop is described and understood
• Target audience is identified
• Core thesis captures what the game IS and is NOT

[通用产品] Product: Concept → Specification

Required Artifacts: Use workflow/generated/gate-required-artifacts.md, section Product: Concept -> Specification.

Quality Checks:

• Product concept has been reviewed (/design-review verdict not MAJOR REVISION NEEDED)
• User journey is described and understood
• Target audience is identified (primary user persona + JTBD statement)
• Core thesis captures what the product IS and is NOT

---

Gate: Systems Design → Technical Setup / Specification → Architecture

[通用场景] This gate validates readiness to move from design to architecture. Checks are shared across both game and product domains.

Required Artifacts: Use workflow/generated/gate-required-artifacts.md, section Game: Systems Design -> Technical Setup or Product: Specification -> Architecture.

Quality Checks:

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

---

Gate: Technical Setup → Pre-Production / Architecture → Pre-Implementation

[通用场景] This gate validates readiness to move from architecture to the build phase. Domain-specific checks apply for game vs product projects.

[游戏专用] Game: Technical Setup → Pre-Production

Catalog Required Artifacts: Use workflow/generated/gate-required-artifacts.md, section Game: Technical Setup -> Pre-Production.

Quality / Risk Checks:

• Architecture decisions cover core systems (rendering, input, state management)
• Technical preferences have naming conventions and performance budgets set
• Accessibility tier is defined and documented (even "Basic" is acceptable — undefined is not)
• Game art bible status is recorded as optional Concept follow-up if design/art/art-bible.md is missing
• All ADRs have an Engine Compatibility section with engine version stamped
• All ADRs have a CDD Requirements Addressed section with explicit CDD linkage
• No ADR references APIs listed in the engine deprecated APIs reference under docs/engine-reference/[engine]/
• All HIGH RISK engine domains (per VERSION.md) have been explicitly addressed in the architecture document or flagged as open questions
• Architecture traceability gaps are recorded as CONCERNS unless they make a Foundation ADR impossible to implement safely

ADR Circular Dependency Check: For all ADRs in docs/architecture/, read each ADR's "ADR Dependencies" / "Depends On" section. Build a dependency graph (ADR-A → ADR-B means A depends on B). If any cycle is detected (e.g. A→B→A, or A→B→C→A):

• Flag as FAIL: "Circular ADR dependency: [ADR-X] → [ADR-Y] → [ADR-X]. Neither can reach Accepted while the cycle exists. Remove one 'Depends On' edge to break the cycle."

Engine Validation (read docs/engine-reference/[engine]/VERSION.md first):

• ADRs that touch post-cutoff engine APIs are flagged with Knowledge Risk: HIGH/MEDIUM
• /architecture-review engine audit shows no deprecated API usage
• All ADRs agree on the same engine version (no stale version references)

---

[通用产品] Product: Architecture → Pre-Implementation

Before checking design artifacts, classify the product surface from design/cdd/product-concept.md and standards/technical-preferences.md: API-only, CLI-only, SDK/library, Web UI, desktop/mobile/admin UI, internal headless service, or multi-surface product. Apply the conditional artifact rules below. Do not fail an API-only, CLI-only, SDK/library, or internal headless product for missing design/design-system.md.

Catalog Required Artifacts: Use workflow/generated/gate-required-artifacts.md, section Product: Architecture -> Pre-Implementation.

Quality / Risk Checks:

• Architecture decisions cover core modules (auth, data access, API framework, logging)
• Technical preferences have naming conventions and performance budgets set
• Accessibility tier is defined and documented
• Product surface profile is recorded in the gate report (API-only, CLI-only, SDK/library, UI-heavy, internal headless, or multi-surface)
• Product interaction patterns are recorded as a Pre-Production required_when follow-up for API, CLI, SDK/library, UI, docs-driven, or other consumer surfaces
• UI-heavy products record design/design-system.md as a Pre-Production or UX handoff concern, not an Architecture blocker
• Product style guide remains optional unless public brand, docs imagery, screenshots, diagrams, marketing/release visuals, or visual tone are in scope
• All ADRs have a Technology Compatibility section with stack version stamped
• All ADRs have a CDD Requirements Addressed section with explicit CDD linkage
• No ADR references APIs listed in the stack deprecated APIs reference under docs/reference/[stack]/
• All HIGH RISK stack domains (per VERSION.md) have been explicitly addressed in the architecture document or flagged as open questions
• Architecture traceability gaps are recorded as CONCERNS unless they make a Foundation ADR impossible to implement safely

ADR Circular Dependency Check: For all ADRs in docs/architecture/, build a dependency graph. If any cycle is detected, flag as FAIL.

Stack Validation (read docs/reference/[stack]/VERSION.md first):

• ADRs that touch post-cutoff APIs are flagged with Knowledge Risk: HIGH/MEDIUM
• /architecture-review audit shows no deprecated API usage
• All ADRs agree on the same stack version (no stale version references)

Gate: Pre-Production → Production / Pre-Implementation → Implementation

[通用场景] This gate validates readiness to begin full-scale feature development. Game projects require Vertical Slice validation; product projects require MVP validation.

[游戏专用] Game: Pre-Production → Production

Catalog Required Artifacts: Use workflow/generated/gate-required-artifacts.md, section Game: Pre-Production -> Production.

Quality / Risk Checks:

• Core loop fun is validated — playtest data confirms the central mechanic is enjoyable, not just functional. Explicitly check the Vertical Slice playtest report.
• UX specs cover key screens such as main menu, core gameplay HUD, and pause menu when those surfaces are in the current CDD scope
• UX specs cover all UI Requirements sections from MVP-tier CDDs
• Interaction pattern library documents patterns used in key screens
• Accessibility tier from design/accessibility-requirements.md is addressed in all key screen UX specs
• Game art bible, character visual profiles, and HUD-specific docs are recorded as optional or feature-specific follow-up unless the current CDDs require them
• Epics cover Foundation and Core layers when those layers are in the current CDD/architecture scope
• Sprint plan references real story file paths from production/epics/ (not just CDDs — stories must embed CDD req ID + ADR reference)
• Vertical Slice is COMPLETE, not just scoped — the build demonstrates the full core loop end-to-end. At least one complete [start → challenge → resolution] cycle works.
• Architecture document has no unresolved open questions in Foundation or Core layers
• All ADRs have Engine Compatibility sections stamped with the engine version
• All ADRs have ADR Dependencies sections (even if all fields are "None")
• Manual validation confirms CDDs + architecture + epics are coherent (run /review-all-gdds and /architecture-review if not done recently)
• Core fantasy is delivered — at least one playtester independently described an experience that matches the Player Fantasy section of the core system CDDs (without being prompted).

Vertical Slice Validation (FAIL if any item is NO):

• A human has played through the core loop without developer guidance
• The game communicates what to do within the first 2 minutes of play
• No critical "fun blocker" bugs exist in the Vertical Slice build
• The core mechanic feels good to interact with (this is a subjective check — ask the user)

Note: If any Vertical Slice Validation item is FAIL, the verdict is automatically FAIL regardless of other checks. Advancing without a validated Vertical Slice creates high rework risk because later features are built on an unproven core loop.

---

[通用产品] Product: Pre-Implementation → Implementation

Apply design/ux/surface-profile.md when a product surface requirement is ambiguous or when any product UX artifact is marked N/A. API-only, CLI-only, SDK/library, and internal headless products are not blocked by missing design/design-system.md; UI-heavy and multi-surface UI products are.

Catalog Required Artifacts: Use workflow/generated/gate-required-artifacts.md, section Product: Pre-Implementation -> Implementation.

Quality / Risk Checks:

• Core interaction validated — user testing data confirms the central workflow solves the user's job, not just functional
• UX specs cover key product surfaces such as onboarding, core workflow, settings, API consumer journey, CLI flow, SDK integration path, or operator workflow when those surfaces are in scope
• UX specs cover all product surface requirements from MVP-tier CDDs: API consumer journeys, CLI flows, SDK integration paths, web/UI screens, or internal operator workflows as applicable
• Interaction pattern library documents patterns used in key screens, commands, endpoint examples, SDK snippets, or workflow handoffs as applicable
• UI-heavy products have design-system coverage for reusable components and states; API-only, CLI-only, SDK/library, and internal headless products record this as N/A rather than FAIL
• Product N/A decisions include surface evidence, reason, accepted-by, and date in design/ux/surface-profile.md
• Product brand/style guide is recorded as optional follow-up unless public brand, documentation imagery, screenshots, diagrams, marketing/release visuals, or visual tone are explicitly in scope
• Accessibility tier is addressed in all key screen UX specs
• Sprint plan references real story file paths from production/epics/ (not just CDDs — stories must embed CDD req ID + ADR reference)
• Epics cover Foundation and Core layers when those layers are in the current CDD/architecture scope
• MVP is COMPLETE, not just scoped — the build demonstrates the full core user journey end-to-end. At least one complete [task → completion → value] cycle works.
• Architecture document has no unresolved open questions in Foundation or Core layers
• All ADRs have Technology Compatibility sections stamped with the stack version
• All ADRs have ADR Dependencies sections (even if all fields are "None")
• Manual validation confirms CDDs + architecture + epics are coherent (run /review-all-gdds and /architecture-review if not done recently)
• Core promise is delivered — at least one user independently described an experience that matches the User Promise section of the core module CDDs (without being prompted).

MVP Validation (FAIL if any item is NO):

• A human has completed the core workflow without developer guidance
• The product communicates what to do within the first 2 minutes of use
• No critical "workflow blocker" bugs exist in the MVP build
• The core interaction feels satisfying to use (this is a subjective check — ask the user)

Note: If any MVP Validation item is FAIL, the verdict is automatically FAIL regardless of other checks. Advancing without a validated MVP creates high implementation risk because later features are built on an unproven core workflow and rework grows with each dependent feature.

Gate: Production → Polish / Implementation → Verification

[通用场景] This gate validates readiness to move from active development to quality assurance and polish.

[游戏专用] Game: Production → Polish

Catalog Required Artifacts: Use workflow/generated/gate-required-artifacts.md, section Game: Production -> Polish.

Quality / Risk Checks:

• Tests are passing (run test suite via Bash)
• No critical/blocker bugs in any bug tracker or known issues
• Core loop plays as designed (compare to CDD acceptance criteria)
• Fun hypothesis from Game Concept has been explicitly validated or revised
• Performance is within budget (check technical-preferences.md targets)
• Playtest findings have been reviewed and critical fun issues addressed (not just documented)
• Smoke check, /qa-plan, /team-qa, and additional playtest sessions are recorded as Production or Polish follow-up unless strict QA is explicitly enabled
• No "confusion loops" identified — no point in the game where >50% of playtesters got stuck without knowing why
• Difficulty curve matches the Difficulty Curve design doc (if one exists at design/difficulty-curve.md)
• All implemented screens have corresponding UX specs (no "designed in-code" screens)
• Interaction pattern library is up-to-date with all patterns used in implementation
• Accessibility compliance verified against committed tier in design/accessibility-requirements.md

---

[通用产品] Product: Implementation → Verification

Catalog Required Artifacts: Use workflow/generated/gate-required-artifacts.md, section Product: Implementation -> Verification.

Quality / Risk Checks:

• Tests are passing (run test suite via Bash)
• No critical/blocker bugs in any bug tracker or known issues
• Core workflow functions as designed (compare to CDD acceptance criteria)
• Core promise from Product Concept has been explicitly validated or revised
• Performance is within budget (check technical-preferences.md targets — latency, memory, throughput)
• User testing findings have been reviewed and critical UX issues addressed
• Smoke check, /qa-plan, /team-qa, and cumulative product validation sessions are recorded as Production or Polish follow-up unless strict QA is explicitly enabled
• No "confusion loops" identified — no point where >50% of users got stuck without knowing why
• All implemented screens have corresponding UX specs (no "designed in-code" screens)
• Interaction pattern library is up-to-date with all patterns used in implementation
• Accessibility compliance verified against committed tier in design/accessibility-requirements.md
• No hardcoded configuration values — all environment-specific settings externalized

Gate: Polish → Release / Verification → Release

[通用场景] This gate validates readiness to ship. Final quality, content, and legal checks.

[游戏专用] Game: Polish → Release

Catalog Required Step Evidence: Use workflow/generated/gate-required-artifacts.md, section Game: Polish -> Release.

Quality / Risk Checks:

• All features from the milestone plan are implemented or explicitly deferred
• Content is complete (all levels, assets, dialogue referenced in design docs exist) or explicitly deferred
• Localization strings are externalized (no hardcoded player-facing text in src/)
• All Must Have story test evidence is present (Logic/Integration: test files pass; Visual/Feel/UI: sign-off docs in production/qa/evidence/)
• No test regressions from previous sprint (test suite passes fully)
• QA plan, /team-qa sign-off, smoke check, balance review, store metadata, changelog, and patch notes are recorded as Release-phase follow-up or CONCERNS unless strict QA is explicitly enabled
• If strict QA is explicitly enabled, missing QA plan, missing QA sign-off, or failing smoke check is a blocker
• Next Release-phase step is /release-checklist, followed by /launch-checklist and /team-release
• Performance targets met across all target platforms
• No known critical, high, or medium-severity bugs
• Accessibility basics covered (remapping, text scaling if applicable)
• Localization verified for all target languages
• Legal requirements met (EULA, privacy policy, age ratings if applicable)
• Build compiles and packages cleanly

---

[通用产品] Product: Verification → Release

Catalog Required Step Evidence: Use workflow/generated/gate-required-artifacts.md, section Product: Verification -> Release.