| name | gate-check |
| description | Validate readiness to advance between development phases. Produces a PASS/CONCERNS/FAIL verdict with specific blockers and required artifacts. |
Gate Check
This is the Codex-adapted version of the original workflow. Use only .codex/ runtime assets when following it.
Arguments: [target-phase: systems-design | technical-setup | pre-production | production | polish | release]
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:
- 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/spawn_agent tracking active)
- Polish — Performance, playtesting, bug fixing
- 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
- 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 validate the NEXT phase transition
2. Phase Gate Definitions
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:
Gate: Pre-Production → Production
Required Artifacts:
Quality Checks:
Gate: Production → Polish
Required Artifacts:
Quality Checks:
Gate: Polish → Release
Required Artifacts:
Quality Checks:
3. Run the Gate Check
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
Quality Checks
- For test checks: Run the test suite via
shell 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.
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
6. Update Stage on PASS
When the verdict is PASS and the user confirms they want to advance:
- apply_patch the new stage name to
production/stage.txt (single line, no trailing newline)
- This immediately updates the status line for all future sessions
Example: if passing the "Pre-Production → Production" gate:
echo -n "Production" > production/stage.txt
Always ask before writing: "Gate passed. May I update production/stage.txt to 'Production'?"
7. Follow-Up Actions
Based on the verdict, suggest specific next steps:
- No game 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
- Missing ADRs? →
architecture-decision
- Tests failing? → delegate to
lead-programmer or qa-tester
- No playtest data? →
playtest-report
- 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.
