| 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: workflow-selection | systems-design | technical-setup | pre-production | production | polish | release] [--review full|lean|solo] |
| user-invocable | true |
| allowed-tools | Read, Glob, Grep, Bash, Write, Task, question |
| model | opencode-go/kimi-k2.6 |
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:
- Exploration — Pre-workflow: rapid prototyping multiple ideas (/explore)
- Concept — Brainstorming, game concept document
- Systems Design — Mapping systems, writing GDDs
- Technical Setup — Engine config, architecture decisions
- Pre-Production — Prototyping, vertical slice validation
- Production — Feature development (Epic/Feature/Task tracking active)
- Polish — Performance, playtesting, bug fixing
- Release — Launch prep, certification
Special gate: workflow-selection — Only valid from the Exploration stage.
When it passes, it sets both production/workflow-mode.txt (hybrid or full) and
production/stage.txt (Concept). See the Workflow Selection gate below.
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):
- If
--review [full|lean|solo] was passed → use that
- Else read
production/review-mode.txt → use that value
- 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
/gate-check workflow-selection — run workflow selection (only valid from exploration stage)
-
No argument: Auto-detect current stage using the same heuristics as
/project-stage-detect, then confirm with the user before running:
Use question:
- 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: Workflow Selection, Concept → Systems Design, Systems Design → Technical Setup, Technical Setup → Pre-Production, Pre-Production → Production, Production → Polish, Polish → Release)
Special case — exploration stage: If auto-detect returns exploration, the only valid
gate is workflow-selection. Skip the confirmation widget and proceed directly to the
Workflow Selection gate.
2. Phase Gate Definitions
Gate: Workflow Selection (Exploration → Hybrid or Full)
This is a pre-workflow gate. It does not validate artifacts — it helps the user
decide which development workflow fits their project after prototyping ideas with
/explore. Unlike all other gates, this gate writes TWO files on PASS:
production/workflow-mode.txt and production/stage.txt.
Run this when: production/stage.txt reads exploration, or explicitly with
/gate-check workflow-selection.
Required Artifacts:
Decision Interview
Skip artifact scanning — this gate is human-driven. Use question to ask
each question. Present one at a time, tally the score, then recommend. Record
the user's answers but do not write them to a file — the output is the
recommendation.
Question 1 — Team size:
- Prompt: "How many people are working on this project?"
- Options:
Solo — Just me (score: 0)Small team — 2-5 people (score: 1)Medium team — 6-10 people (score: 2)Large team — 10+ people (score: 3)
Question 2 — Timeline:
- Prompt: "What's your target timeline to a shippable game?"
- Options:
Short — Under 3 months (score: 0)Medium — 3-6 months (score: 1)Long — 6-12 months (score: 2)Extended — 12+ months (score: 3)
Question 3 — Design clarity:
- Prompt: "How well-defined is your game design at this point?"
- Options:
Rough concept — A theme and a mechanic, but no details (score: 0)Some systems — Core loop and 2-3 major systems sketched (score: 1)Mostly designed — Core systems, economy, and progression mapped (score: 2)Fully documented — Full GDDs ready to build from (score: 3)
Question 4 — External requirements:
- Prompt: "Do you have publisher, investor, or platform requirements?"
- Options:
None — Self-funded, no external obligations (score: 0)Informal — A publisher is interested but no contract yet (score: 1)Contractual — Signed deal with milestone deliverables (score: 2)Multi-platform — Strict cert requirements across platforms (score: 3)
Question 5 — Team experience:
- Prompt: "What's your team's experience level with shipping games?"
- Options:
First game — No shipped titles (score: 0)Small games — Shipped jam games or small commercial titles (score: 1)Experienced — Shipped 1-3 commercial titles (score: 2)Veteran — Shipped 3+ commercial titles (score: 3)
Scoring
After all 5 questions, calculate the total score (0-15):
- Score 0-5: Recommend Hybrid workflow — lightweight discovery phase,
then production with reduced agent roster. Best for small teams, unknown
designs, and short timelines.
- Score 6-10: Recommend Hybrid with upgrade path — start with Hybrid,
but be ready to upgrade to Full OCGS as scope grows. Set workflow-mode to
hybrid but note the upgrade triggers.
- Score 11-15: Recommend Full OCGS workflow — formal GDDs, ADRs,
full quality gates, and the complete agent roster. Best for larger teams,
funded projects, and long timelines.
Present the recommendation:
## Workflow Selection Result
**Score**: [N]/15
**Recommended workflow**: [Hybrid / Hybrid with upgrade path / Full OCGS]
**Reasoning**:
- Team size ([answer]) → weight toward [workflow]
- Timeline ([answer]) → weight toward [workflow]
- Design clarity ([answer]) → weight toward [workflow]
- External requirements ([answer]) → weight toward [workflow]
- Team experience ([answer]) → weight toward [workflow]
### Next Step
- **If Hybrid**: Begin your concept document with `/concept-brainstorm` or jump straight
into `/hybrid-prototype` with your winning idea.
- **If Full OCGS**: Run `/concept-brainstorm [winning-idea]` to formalize your concept,
then `/setup-engine` to configure the engine.
User Confirmation
Use question to confirm:
- Prompt: "Recommended: [Hybrid / Full OCGS]. Does this match your intuition?"
- Options:
Yes — proceed with [recommended workflow]No — I prefer the [other workflow] insteadNot sure yet — I want to explore more ideas first
Apply the Decision
When the user confirms (Yes or No), write both files:
production/workflow-mode.txt — write hybrid or full (single line)production/stage.txt — write Concept (single line)
Always ask before writing: "May I update production/workflow-mode.txt to
[workflow] and production/stage.txt to Concept?"
If "Not sure yet", do not write anything. Advise: "Run /explore [next-idea]
to prototype more ideas, then return here."
Gate: Concept → Systems Design
Required Artifacts:
Quality Checks:
Gate: Systems Design → Technical Setup
Required Artifacts:
Quality Checks:
Gate: Technical Setup → Pre-Production
Required Artifacts:
Quality Checks:
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):
Gate: Pre-Production → Production
Required Artifacts:
Quality Checks:
Vertical Slice Validation (FAIL if any item is NO):
Note: If any Vertical Slice Validation item is FAIL, the verdict is automatically FAIL
regardless of other checks. Advancing without a validated Vertical Slice is the #1 cause of
production failure in game development (per GDC postmortem data from 155 projects).
Gate: Production → Polish
Required Artifacts:
Quality Checks:
Gate: Polish → Release
Required Artifacts:
Quality Checks:
3. Run the Gate Check
Before running artifact checks, read docs/consistency-failures.md if it exists.
Extract entries whose Domain matches the target phase (e.g., if checking
Systems Design → Technical Setup, pull entries in Economy, Combat, or any GDD domain;
if checking Technical Setup → Pre-Production, pull entries in Architecture, Engine).
Carry these as context — recurring conflict patterns in the target domain warrant
increased scrutiny on those specific checks.
For each item in the target gate:
Artifact Checks
- Use
Glob and Read to verify files exist and have meaningful content
- Don't just check existence — verify the file has real content (not just a template header)
- For code checks, verify directory structure and file counts
Systems Design → Technical Setup gate — cross-GDD review check:
Use Glob('design/gdd/gdd-cross-review-*.md') to find the /review-all-gdds report.
If no file matches, mark the "cross-GDD review report exists" artifact as FAIL and
surface it prominently: "No /review-all-gdds report found in design/gdd/. Run
/review-all-gdds before advancing to Technical Setup."
If a file is found, read it and check the verdict line: a FAIL verdict means the
cross-GDD consistency check failed and must be resolved before advancing.
Quality Checks
- For test checks: Run the test suite via
Bash if a test runner is configured
- For design review checks:
Read the GDD and check for the 8 required sections
- For performance checks:
Read technical-preferences.md and compare against any
profiling data in tests/performance/ or recent /perf-profile output
- For localization checks:
Grep for hardcoded strings in src/
Cross-Reference Checks
- Compare
design/gdd/ documents against src/ implementations
- Check that every system referenced in architecture docs has corresponding code
- Verify sprint plans reference real work items
4. Collaborative Assessment
For items that can't be automatically verified, ask the user:
- "I can't automatically verify that the core loop plays well. Has it been playtested?"
- "No playtest report found. Has informal testing been done?"
- "Performance profiling data isn't available. Would you like to run
/perf-profile?"
Never assume PASS for unverifiable items. Mark them as MANUAL CHECK NEEDED.
4b. Director Panel Assessment
Skip for Workflow Selection gate: This gate is pre-workflow — no directors
are assigned yet. Proceed directly to the verdict output with only the artifact
and decision interview results.
For all other gates: Before generating the final verdict, spawn all four
directors as parallel subagents via Task using the parallel gate protocol
from docs/framework/director-gates.md. Issue all four Task calls
simultaneously — do not wait for one before starting the next.
Spawn in parallel:
creative-director — gate CD-PHASE-GATE (docs/framework/director-gates.md)technical-director — gate TD-PHASE-GATE (docs/framework/director-gates.md)producer — gate PR-PHASE-GATE (docs/framework/director-gates.md)art-director — gate AD-PHASE-GATE (docs/framework/director-gates.md)
Pass to each: target phase name, list of artifacts present, and the context fields listed in that gate's definition.
Collect all four responses, then present the Director Panel summary:
## Director Panel Assessment
Creative Director: [READY / CONCERNS / NOT READY]
[feedback]
Technical Director: [READY / CONCERNS / NOT READY]
[feedback]
Producer: [READY / CONCERNS / NOT READY]
[feedback]
Art Director: [READY / CONCERNS / NOT READY]
[feedback]
Apply to the verdict:
- Any director returns NOT READY → verdict is minimum FAIL (user may override with explicit acknowledgement)
- Any director returns CONCERNS → verdict is minimum CONCERNS
- All four READY → eligible for PASS (still subject to artifact and quality checks from Section 3)
5. Output the Verdict
## Gate Check: [Current Phase] → [Target Phase]
**Date**: [date]
**Checked by**: gate-check skill
### Required Artifacts: [X/Y present]
- [x] design/gdd/game-concept.md — exists, 2.4KB
- [ ] docs/architecture/ — MISSING (no ADRs found)
- [x] production/sprints/ — exists, 1 sprint plan
### Quality Checks: [X/Y passing]
- [x] GDD has 8/8 required sections
- [ ] Tests — FAILED (3 failures in tests/unit/)
- [?] Core loop playtested — MANUAL CHECK NEEDED
### Blockers
1. **No Architecture Decision Records** — Run `/architecture-decision` to create one
covering core system architecture before entering production.
2. **3 test failures** — Fix failing tests in tests/unit/ before advancing.
### Recommendations
- [Priority actions to resolve blockers]
- [Optional improvements that aren't blocking]
### Verdict: [PASS / CONCERNS / FAIL]
- **PASS**: All required artifacts present, all quality checks passing
- **CONCERNS**: Minor gaps exist but can be addressed during the next phase
- **FAIL**: Critical blockers must be resolved before advancing
5a. Chain-of-Verification
Skip for Workflow Selection gate: The decision interview is human-driven
and scored transparently. No artifact quality checks need verification — the
score and recommendation are self-evident. Proceed directly to the verdict.
For all other gates: After drafting the verdict in Phase 5, challenge it
before finalising.
Step 1 — Generate 5 challenge questions designed to disprove the verdict:
For a PASS draft:
- "Which quality checks did I verify by actually reading a file, vs. inferring they passed?"
- "Are there MANUAL CHECK NEEDED items I marked PASS without user confirmation?"
- "Did I confirm all listed artifacts have real content, not just empty headers?"
- "Could any blocker I dismissed as minor actually prevent the phase from succeeding?"
- "Which single check am I least confident in, and why?"
For a CONCERNS draft:
- "Could any listed CONCERN be elevated to a blocker given the project's current state?"
- "Is the concern resolvable within the next phase, or does it compound over time?"
- "Did I soften any FAIL condition into a CONCERN to avoid a harder verdict?"
- "Are there artifacts I didn't check that could reveal additional blockers?"
- "Do all the CONCERNS together create a blocking problem even if each is minor alone?"
For a FAIL draft:
- "Have I accurately separated hard blockers from strong recommendations?"
- "Are there any PASS items I was too lenient about?"
- "Am I missing any additional blockers the user should know about?"
- "Can I provide a minimal path to PASS — the specific 3 things that must change?"
- "Is the fail condition resolvable, or does it indicate a deeper design problem?"
Step 2 — Answer each question independently.
Do NOT reference the draft verdict text — re-check specific files or ask the user.
Step 3 — Revise if needed:
- If any answer reveals a missed blocker → upgrade verdict (PASS→CONCERNS or CONCERNS→FAIL)
- If any answer reveals an over-stated blocker → downgrade only if citing specific evidence
- If answers are consistent → confirm verdict unchanged
Step 4 — Note the verification in the final report output:
Chain-of-Verification: [N] questions checked — verdict [unchanged | revised from X to Y]
6. Update Stage on PASS
When the verdict is PASS and the user confirms they want to advance:
-
For Workflow Selection gate: Write TWO files.
production/workflow-mode.txt with the selected workflow (hybrid or full),
and production/stage.txt with Concept.
echo -n "[hybrid|full]" > production/workflow-mode.txt
echo -n "Concept" > production/stage.txt
-
For all other gates: Write the new stage name to production/stage.txt
(single line, no trailing newline).
Always ask before writing — specify both files for workflow-selection:
- "Gate passed. May I update
production/stage.txt to 'Production'?"
- "Gate passed. May I set
production/workflow-mode.txt to 'hybrid' and production/stage.txt to 'Concept'?"
7. Closing Next-Step Widget
After the verdict is presented and any stage.txt update is complete, close with a structured next-step prompt using question.
Tailor the options to the gate that just ran:
For workflow-selection PASS:
Gate passed. What would you like to do next?
[If hybrid] [A] Run /concept-brainstorm [winning-idea] — formalize your concept
[B] Run /hybrid-prototype [winning-idea] — jump straight into prototyping
[C] Stop here for this session
[If full] [A] Run /concept-brainstorm [winning-idea] — formalize your concept
[B] Run /setup-engine — choose and configure your engine
[C] Stop here for this session
For systems-design PASS:
Gate passed. What would you like to do next?
[A] Run /create-architecture — produce your master architecture blueprint and ADR work plan (recommended next step)
[B] Design more GDDs first — return here when all MVP systems are complete
[C] Stop here for this session
Note for systems-design PASS: /create-architecture is the required next step before writing any ADRs. It produces the master architecture document and a prioritized list of ADRs to write. Running /architecture-decision without this step means writing ADRs without a blueprint — skip it at your own risk.
For technical-setup PASS:
Gate passed. What would you like to do next?
[A] Start Pre-Production — begin prototyping the Vertical Slice
[B] Write more ADRs first — run /architecture-decision [next-system]
[C] Stop here for this session
For all other gates, offer the two most logical next steps for that phase plus "Stop here".
8. Follow-Up Actions
Based on the verdict, suggest specific next steps:
- No explore prototypes yet? →
/explore [idea-name] to prototype ideas before workflow selection
- Workflow not yet selected? →
/gate-check workflow-selection to choose Hybrid or Full OCGS
- Selected Hybrid but no concept? →
/concept-brainstorm [winning-idea] to formalize, then /hybrid-prototype to build
- Selected Full OCGS but no engine? →
/setup-engine [engine-name] to configure the engine
- No art bible? →
/art-bible to create the visual identity specification
- Art bible exists but no asset specs? →
/asset-spec system:[name] to generate per-asset visual specs and generation prompts from approved GDDs
- No game concept? →
/concept-brainstorm to create one
- No systems index? →
/map-systems to decompose the concept into systems
- Missing design docs? →
/reverse-document or delegate to game-designer
- Small design change needed? →
/quick-design for changes under ~4 hours (bypasses full GDD pipeline)
- No UX specs? →
/ux-design [screen name] to author specs, or /team-ui [feature] for full pipeline
- UX specs not reviewed? →
/ux-review [file] or /ux-review all to validate
- No accessibility requirements doc? → Use
question to offer to create it now:
- Prompt: "The gate requires
design/accessibility-requirements.md. Shall I create it from the template?"
- Options:
Create it now — I'll choose an accessibility tier, I'll create it myself, Skip for now
- If "Create it now": use a second
question to ask for the tier:
- Prompt: "Which accessibility tier fits this project?"
- Options:
Basic — remapping + subtitles only (lowest effort), Standard — Basic + colorblind modes + scalable UI, Comprehensive — Standard + motor accessibility + full settings menu, Exemplary — Comprehensive + external audit + full customization
- Then write
design/accessibility-requirements.md using the template at docs/framework/templates/accessibility-requirements.md, filling in the chosen tier. Confirm: "May I write design/accessibility-requirements.md?"
- No interaction pattern library? →
/ux-design patterns to initialize it
- GDDs not cross-reviewed? →
/review-all-gdds (run after all MVP GDDs are individually approved)
- Cross-GDD consistency issues? → fix flagged GDDs, then re-run
/review-all-gdds
- No test framework? →
/test-setup to scaffold the framework for your engine
- No QA plan for current sprint? →
/qa-plan sprint to generate one before implementation begins
- Missing ADRs? →
/architecture-decision for individual decisions
- No master architecture doc? →
/create-architecture for the full blueprint
- ADRs missing engine compatibility sections? → Re-run
/architecture-decision
or manually add Engine Compatibility sections to existing ADRs
- Missing control manifest? →
/create-control-manifest (requires Accepted ADRs)
- Missing epics? →
/create-epics layer: foundation then /create-epics layer: core (requires control manifest)
- Missing stories for an epic? →
/create-stories [epic-slug] (run after each epic is created)
- Stories not implementation-ready? →
/story-readiness to validate stories before developers pick them up
- Tests failing? → delegate to
lead-programmer or qa-tester
- No playtest data? →
/playtest-report
- Less than 3 playtest sessions? → Run more playtests before advancing. Use
/playtest-report to structure findings.
- No Difficulty Curve doc? → Consider creating one at
design/difficulty-curve.md before polish
- No player journey document? → create
design/player-journey.md using the player journey template
- Need a quick sprint check? →
/sprint-status for current sprint progress snapshot
- Performance unknown? →
/perf-profile
- Not localized? →
/localize
- Ready for release? →
/launch-checklist
Collaborative Protocol
This skill follows the collaborative design principle:
- Scan first: Check all artifacts and quality gates
- Ask about unknowns: Don't assume PASS for things you can't verify
- Present findings: Show the full checklist with status
- User decides: The verdict is a recommendation — the user makes the final call
- Get approval: "May I write this gate check report to production/gate-checks/?"
Never block a user from advancing — the verdict is advisory. Document the risks
and let the user decide whether to proceed despite concerns.
