| name | studio-gate-check |
| description | Check whether a project is ready to advance to the next development phase by verifying artifacts, quality evidence, manual unknowns, and advisory reviewer feedback. |
| category | studio |
| source | chronos-adapted |
| source_path | .claude/skills/gate-check/SKILL.md |
Studio Gate Check
Use this skill to assess whether a project is ready to move from one development phase to the next.
This skill is prescriptive: it answers "Are we ready to advance?" rather than "What phase are we in?"
Supported Stage Model
Use this generic stage sequence unless the repository defines its own equivalent:
- Concept
- Systems Design
- Technical Setup
- Pre-Production
- Production
- Polish
- Release
If the project uses different names, map them explicitly before continuing.
Phase 1 — Parse the Target Gate
If the user supplies a target phase, validate readiness for that transition.
If they do not, infer the current stage from available artifacts and confirm the inferred transition with AskUserQuestion before proceeding.
Do not skip that confirmation when the stage is inferred.
Phase 2 — Define Gate Requirements
For the target transition, build a checklist of:
- required artifacts
- quality checks
- cross-reference checks
- manual checks that cannot be automated
Use repository evidence first. If the project already documents phase criteria, prefer that over generic assumptions.
Default gate expectations
Concept → Systems Design
- concept brief exists
- pillars or design principles exist
- core loop and audience are defined
Systems Design → Technical Setup
- systems index exists
- MVP-level design docs exist
- design docs have been reviewed for internal consistency
Technical Setup → Pre-Production
- engine and technical baseline are chosen
- architecture docs and key decisions exist
- test framework exists
- at least minimal UX and accessibility intent exists
Pre-Production → Production
- playable prototype or vertical slice exists
- first sprint plan exists
- core design docs and architecture are coherent
- key playtest evidence exists
Production → Polish
- core gameplay path is playable end to end
- tests and QA evidence exist
- playtesting has identified and addressed major issues
Polish → Release
- features and content are complete
- regression checks pass
- release readiness artifacts exist
Phase 3 — Run the Checks
For each requirement:
Artifact checks
- verify file or directory existence
- verify content is meaningful, not just a placeholder
- verify counts or coverage when the gate implies more than one artifact
Quality checks
- run tests when the gate depends on test health
- read review reports, architecture notes, or design evidence where required
- compare implementation against plans when the gate depends on coherence
Cross-reference checks
- compare design docs with source structure
- compare sprint or milestone plans with actual work items
- compare architecture decisions with implementation patterns
Phase 4 — Handle Unknowns Collaboratively
Some checks cannot be proven automatically.
Ask the user directly for items such as:
- whether the core loop has been playtested
- whether the experience is fun enough to move on
- whether informal testing exists when no report file is present
- whether performance evidence exists when no profiling output is available
Never silently convert unknowns into passes.
Mark them as Manual Check Needed until confirmed.
Phase 5 — Optional Reviewer Panel
If the decision is high stakes, optionally spawn Task-based reviewers in parallel, such as:
- creative reviewer
- technical reviewer
- production reviewer
- visual or UX reviewer
Pass them:
- target phase
- artifact summary
- the most relevant context for their discipline
Treat reviewer outputs as advisory:
- any strong "not ready" signal should prevent a clean PASS
- concern-level feedback should raise the verdict floor to CONCERNS
Phase 6 — Draft the Verdict
Use this structure:
## Gate Check: [Current Phase] → [Target Phase]
### Required Artifacts
- [x] Present item
- [ ] Missing item
### Quality Checks
- [x] Passing item
- [ ] Failed item
- [?] Manual Check Needed
### Blockers
1. [Blocking issue]
### Recommendations
- [Priority action]
- [Optional improvement]
### Verdict
[PASS / CONCERNS / FAIL]
Verdict rules:
- PASS — required artifacts present and quality evidence is sufficient
- CONCERNS — advancement is possible but meaningful risks remain
- FAIL — critical blockers must be resolved first
Phase 7 — Challenge the Verdict
Before finalizing, generate several challenge questions intended to disprove the draft verdict.
Examples:
- Which checks were directly verified versus inferred?
- Did any unknowns get treated too generously?
- Are any "concerns" actually blocking in practice?
- What is the single weakest piece of evidence behind this verdict?
Answer the questions by re-checking evidence or asking the user. Revise the verdict if needed.
Include a short Chain-of-Verification note in the final output.
Phase 8 — Optional Stage Update
If the project tracks the current phase in a file and the verdict is PASS, ask before writing the new stage value.
Never update phase-tracking files without explicit user approval.
Phase 9 — Close with Next-Step Choices
After the verdict, give 2 or 3 sensible next-step options using AskUserQuestion when appropriate.
Examples:
- proceed to the next planning or implementation workflow
- fill the most important missing artifact
- stop for this session
Tailor the options to the gate that just ran.
Follow-Up Guidance
Base follow-up recommendations on what is missing.
Examples:
- missing concept work → brainstorm or concept review
- missing systems docs → system mapping and design docs
- missing architecture → architecture planning and decisions
- missing tests or QA → test setup, QA planning, or smoke checks
- missing prototype evidence → prototype and playtest workflows
Verdict: COMPLETE when the gate verdict, evidence, blockers, and next action are clear.
