mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-06-27 13:01:50 +00:00
48 coordinated Claude Code subagents for indie game development: - 3 leadership agents (creative-director, technical-director, producer) - 10 department leads (game-designer, lead-programmer, art-director, etc.) - 23 specialist agents (gameplay, engine, AI, networking, UI, tools, etc.) - 12 engine-specific agents (Godot, Unity, Unreal with sub-specialists) Infrastructure: - 34 skills (slash commands) for workflows, reviews, and team orchestration - 8 hooks for commit validation, asset checks, session management - 11 path-scoped rules enforcing domain-specific standards - 28 templates for design docs, reports, and collaborative protocols Key features: - User-driven collaboration protocol (Question → Options → Decision → Draft → Approval) - Engine version awareness with knowledge-gap detection (Godot 4.6 pinned) - Phase gate system for development milestone validation - CLAUDE.md kept under 80 lines with extracted doc imports Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
210 lines
7.5 KiB
Markdown
210 lines
7.5 KiB
Markdown
---
|
|
name: gate-check
|
|
description: "Validate readiness to advance between development phases. Produces a PASS/CONCERNS/FAIL verdict with specific blockers and required artifacts."
|
|
argument-hint: "[target-phase: pre-production | production | alpha | beta | release]"
|
|
user-invocable: true
|
|
allowed-tools: Read, Glob, Grep, Bash
|
|
---
|
|
|
|
# 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).
|
|
|
|
---
|
|
|
|
## 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 → Pre-production
|
|
|
|
**Required Artifacts:**
|
|
- [ ] `design/gdd/game-concept.md` exists and has content
|
|
- [ ] Game pillars defined (in concept doc or `design/gdd/game-pillars.md`)
|
|
- [ ] Engine chosen (CLAUDE.md Technology Stack is not `[CHOOSE]`)
|
|
- [ ] Technical preferences configured (`.claude/docs/technical-preferences.md` populated)
|
|
|
|
**Quality Checks:**
|
|
- [ ] Game concept has been reviewed (`/design-review` verdict not MAJOR REVISION NEEDED)
|
|
- [ ] Core loop is described and understood
|
|
- [ ] Target audience is identified
|
|
|
|
---
|
|
|
|
### Gate: Pre-production → Production
|
|
|
|
**Required Artifacts:**
|
|
- [ ] At least 1 GDD in `design/gdd/` (beyond game-concept.md)
|
|
- [ ] At least 1 Architecture Decision Record in `docs/architecture/`
|
|
- [ ] At least 1 prototype in `prototypes/` with a README
|
|
- [ ] Engine reference docs exist in `docs/engine-reference/`
|
|
- [ ] First sprint plan exists in `production/sprints/`
|
|
|
|
**Quality Checks:**
|
|
- [ ] GDD(s) pass design review (8 required sections present)
|
|
- [ ] Prototype validates the core loop hypothesis
|
|
- [ ] Architecture decisions cover core systems (rendering, input, state management)
|
|
- [ ] Technical preferences have naming conventions and performance budgets set
|
|
|
|
---
|
|
|
|
### Gate: Production → Alpha
|
|
|
|
**Required Artifacts:**
|
|
- [ ] `src/` has active code organized into subsystems
|
|
- [ ] All core mechanics from GDD are implemented (cross-reference `design/gdd/` with `src/`)
|
|
- [ ] Main gameplay path is playable end-to-end
|
|
- [ ] Test files exist in `tests/`
|
|
- [ ] At least 1 playtest report (or `/playtest-report` has 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: Alpha → Beta
|
|
|
|
**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-check` run)
|
|
|
|
**Quality Checks:**
|
|
- [ ] All tests passing
|
|
- [ ] Performance targets met (frame rate, memory, load times)
|
|
- [ ] No critical or high-severity bugs
|
|
- [ ] Accessibility basics covered (remapping, text scaling if applicable)
|
|
- [ ] Save/load system works reliably
|
|
|
|
---
|
|
|
|
### Gate: Beta → Release
|
|
|
|
**Required Artifacts:**
|
|
- [ ] Release checklist completed (`/release-checklist` or `/launch-checklist` run)
|
|
- [ ] Store metadata prepared (if applicable)
|
|
- [ ] Changelog / patch notes drafted
|
|
- [ ] Post-launch support plan exists
|
|
|
|
**Quality Checks:**
|
|
- [ ] Full QA pass signed off by `qa-lead`
|
|
- [ ] Performance targets met across all target platforms
|
|
- [ ] No known critical, high, or medium-severity bugs
|
|
- [ ] 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 `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 `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.
|
|
|
|
---
|
|
|
|
## 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. Follow-Up Actions
|
|
|
|
Based on the verdict, suggest specific next steps:
|
|
|
|
- **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:
|
|
|
|
1. **Scan first**: Check all artifacts and quality gates
|
|
2. **Ask about unknowns**: Don't assume PASS for things you can't verify
|
|
3. **Present findings**: Show the full checklist with status
|
|
4. **User decides**: The verdict is a recommendation — the user makes the final call
|
|
5. **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.
|