gate-check
Skill19 starsChanged 7 months agoMITView on GitHub
Validate readiness to advance between development phases. Produces a PASS/CONCERNS/FAIL verdict with specific blockers and required artifacts.
We split this skill into the rules it gives an agent
8 rules. 0 are common, 6 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 18 edited versions we read keep these.
6
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 144
Use Glob and Read to verify files exist and have meaningful content
- Distinctive: line 145
Don't just check existence — verify the file has real content (not just a template header)
- Distinctive: line 157
Check that every system referenced in architecture docs has corresponding code
- Distinctive: line 158
Verify sprint plans reference real work items
- Distinctive: line 211
When the verdict is PASS and the user confirms they want to advance:
- Very specific: line 213
Write the new stage name to production/stage.txt (single line, no trailing newline)
- Distinctive: line 245
Scan first: Check all artifacts and quality gates
- Distinctive: line 246
Ask about unknowns: Don't assume PASS for things you can't verify
“Common” is measured: kept by at least 6 in 10 of the 18 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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/Task 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:
design/gdd/game-concept.mdexists and has content- Game pillars defined (in concept doc or
design/gdd/game-pillars.md)
Quality Checks:
- Game concept has been reviewed (
/design-reviewverdict not MAJOR REVISION NEEDED) - Core loop is described and understood
- Target audience is identified
Gate: Systems Design → Technical Setup
Required Artifacts:
- Systems index exists at
design/gdd/systems-index.mdwith at least MVP systems enumerated - At least 1 GDD in
design/gdd/(beyond game-concept.md and systems-index.md)
Quality Checks:
- GDD(s) pass design review (8 required sections present)
- System dependencies are mapped in the systems index
- MVP priority tier is defined
Gate: Technical Setup → Pre-Production
Required Artifacts:
- Engine chosen (CLAUDE.md Technology Stack is not
[CHOOSE]) - Technical preferences configured (
.claude/docs/technical-preferences.mdpopulated) - At least 1 Architecture Decision Record in
docs/architecture/ - Engine reference docs exist in
docs/engine-reference/
Quality Checks:
- Architecture decisions cover core systems (rendering, input, state management)
- Technical preferences have naming conventions and performance budgets set
Gate: Pre-Production → Production
Required Artifacts:
- At least 1 prototype in
prototypes/with a README - First sprint plan exists in
production/sprints/ - All MVP-tier GDDs from systems index are complete
Quality Checks:
- Prototype validates the core loop hypothesis
- Sprint plan references real work items from GDDs
- Vertical slice scope is defined
Gate: Production → Polish
Required Artifacts:
src/has active code organized into subsystems- All core mechanics from GDD are implemented (cross-reference
design/gdd/withsrc/) - Main gameplay path is playable end-to-end
- Test files exist in
tests/ - At least 1 playtest report (or
/playtest-reporthas been run)
Quality 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 GDD acceptance criteria)
- Performance is within budget (check technical-preferences.md targets)
Gate: Polish → Release
Required Artifacts:
- All features from milestone plan are implemented
- Content is complete (all levels, assets, dialogue referenced in design docs exist)
- Localization strings are externalized (no hardcoded player-facing text in
src/) - QA test plan exists
- Balance data has been reviewed (
/balance-checkrun) - Release checklist completed (
/release-checklistor/launch-checklistrun) - Store metadata prepared (if applicable)
- Changelog / patch notes drafted
Quality Checks:
- Full QA pass signed off by
qa-lead - All tests passing
- 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
3. Run the Gate Check
For each item in the target gate:
Artifact Checks
- Use
GlobandReadto 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
Bashif a test runner is configured - For design review checks:
Readthe GDD and check for the 8 required sections - For performance checks:
Readtechnical-preferences.md and compare against any profiling data intests/performance/or recent/perf-profileoutput - For localization checks:
Grepfor hardcoded strings insrc/
Cross-Reference Checks
- Compare
design/gdd/documents againstsrc/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 advancing6. Update Stage on PASS
When the verdict is PASS and the user confirms they want to advance:
- Write 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.txtAlways 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? →
/brainstormto create one - No systems index? →
/map-systemsto decompose the concept into systems - Missing design docs? →
/reverse-documentor delegate togame-designer - Missing ADRs? →
/architecture-decision - Tests failing? → delegate to
lead-programmerorqa-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.
Other versions19 projects use a version of this.
Word for word · 0
None found.
Edited · 10
- Donchitos/Claude-Code-Game-Studios★ 27k18% same
- striderZA/OpenCodeGameStudios★ 9317% same
- tranhieutt/software_development_department★ 7147% same
- dawn840705/codex-code-studios★ 1716% same
- lilangMax/ClaudeCodeGameStudios★ 830% same
- hongyuanc/codex-game-studios★ 523% same
- dawn840705/claude-code-studios★ 117% same
- HunLuanZhiZhu/Game-Studios-Plugin★ 125% same
- scotidev/GameDevStudio★ 199% same
- venus2099/codex-game-studios★ 118% same
Wrote their own version · 9
- pixel-cellar/Claude-Code-Game-Studios★ 324same name
- supernovae-st/nika★ 96same name
- cenconq25/claude-code-app-studio★ 40same name
- phj128/autoworker★ 18same name
- CodePhobiia/claude-roblox-game-studio★ 9same name
- timjrobinson/Claude-Code-Construction-Manager★ 4same name
- ailess-lab/CCFG★ 2same name
- nuncaeslupus/literary-critic★ 0same name
- ShiningPlague/shiningplague-studio★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use soak-test, team-live-ops and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
lilangMaxSkillsoak-test
Generate a soak test protocol for extended play sessions. Defines what to observe, measure, and log during long play sessions to surface slow leaks, fatigue effects, and edge cases that only appear after sustained play. Primarily used in Polish and Release phases.
Also in 9 projects that use this
lilangMaxSkillteam-live-ops
Orchestrate the live-ops team for post-launch content planning: coordinates live-ops-designer, economy-designer, analytics-engineer, community-manager, writer, and narrative-director to design and plan a season, event, or live content update.
Also in 9 projects that use this
MRCalderon3DSkillart-bible
Define a visual direction that artists, UI, technical art, and marketing can execute consistently.
Also in 10 projects that use this
- +9 more from lilangMax
In this repository37 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- architecture-decisionSkill
- asset-auditSkill
- balance-checkSkill
- brainstormSkill
- bug-reportSkill
- changelogSkill
- code-reviewSkill
- design-reviewSkill
- design-systemSkill
- estimateSkill
- hotfixSkill
- launch-checklistSkill
- localizeSkill
- map-systemsSkill
- milestone-reviewSkill
- onboardSkill
- patch-notesSkill
- perf-profileSkill
- playtest-reportSkill
- project-stage-detectSkill
- prototypeSkill
- release-checklistSkill
- retrospectiveSkill
- reverse-documentSkill
- scope-checkSkill
- setup-engineSkill
- sprint-planSkill
- startSkill
- team-audioSkill
- team-combatSkill
- team-levelSkill
- team-narrativeSkill
- team-polishSkill
- team-releaseSkill
- team-uiSkill
- tech-debtSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

