studio-gate-check

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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:

1. Concept
2. Systems Design
3. Technical Setup
4. Pre-Production
5. Production
6. Polish
7. 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:

From islee23520/lux, MIT.

More from islee23520/lux