gate-check skill

!bash "${CLAUDESKILLDIR}/../../hooks/yaml-helper.sh" resolveconfig --keys reviewmode,workflow,qa.level,testing.strict,performance.enforce,team.size,project.stage,system_overrides

Resolved above — use as-is; --review overrides review_mode. No block → defaults in .claude/docs/config-resolution.md.

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:

1. Concept — Brainstorming, game concept document
2. Systems Design — Mapping systems, writing GDDs
3. Technical Setup — Engine config, architecture decisions
4. Pre-Production — Prototyping, vertical slice validation
5. Production — Feature development (Epic/Feature/Task tracking active)
6. Polish — Performance, playtesting, bug fixing
7. Release — Launch prep, certification

When a gate passes, update the stage in both project.yaml (set project.stage: ) AND write the new stage name to production/stage.txt (single line, e.g. Production). Dual-write keeps backward compatibility with hooks that haven't migrated yet. This updates the status line immediately.

1. Parse Arguments

Target phase: $ARGUMENTS[0] (blank = auto-detect current stage, then validate next transition)

Note: in solo mode, director spawns (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE) are skipped — gate-check becomes artifact-existence checks only. In lean mode, all four directors still run (phase gates are the purpose of lean mode).

workflow (per .claude/docs/workflow-modes.md):

gate-check runs project-wide, so it uses the project-level workflow for the gate's overall artifact checklist (the loaded gate file), AND consults workflowoverrides.systemoverrides. per-system when validating MVP GDDs — a system pinned to a higher tier must meet that tier's section count before the gate passes, regardless of the project-level workflow (see Section 2b, "Per-system overrides").

gate-check honors workflow but is exempt from automation. The artifact

checklist changes per tier; the collaborative prompting protocol (Section 8)

always applies — a phase gate is a deliberate human checkpoint, never auto-run.

qa.level: controls test enforcement at phase gates, where workflow controls which artifacts are required. modes.rigor sets both together; set qa.level explicitly to vary enforcement alone. At minimal, no test gates apply — the test-evidence / unit-test / smoke artifact items become non-required and the Section 3 testing.strict check is a no-op. At standard, Logic + Integration tests must pass. At full, a full coverage check + regression suite are required (coverage minimum from qa.coverage_minimum if set).

team.size: does not change how many directors spawn at a phase gate — panel width is workflow's axis (Section 4b). This value affects only the specialist depth within each director's review. individual uses the core specialist set; small the standard set; studio adds engine sub-specialists. It never skips a director — skipping directors is reviewmode's job. Both reviewmode and team.size are now fronted by modes.rigor — one rigor choice sets both — and each still overrides that axis when set explicitly (a full-rigor project gets the studio set; lighter tiers get individual).

/project-stage-detect, then confirm with the user before running:

• With argument: /gate-check production — validate readiness for that specific phase
• No argument: Auto-detect current stage using the same heuristics as

Use AskUserQuestion:

• Prompt: "Detected stage: [current stage]. Running gate for [Current] → [Next] transition. Is this correct?"
• Options:
• [A] Yes — run this gate
• [B] No — pick a different gate (if selected, show a second widget listing all gate options: Concept → Systems Design, Systems Design → Technical Setup, Technical Setup → Pre-Production, Pre-Production → Production, Production → Polish, Polish → Release)

Do not skip this confirmation step when no argument is provided.

2. Phase Gate Definitions

Each gate's checklist — required artifacts, quality checks, and its workflow-tier reductions — lives in its own file. Read only the row for the target phase transition; never load the others.

Each file states the full baseline first, then the standard and minimal reductions for that gate. Apply the tier resolved in Section 1.

2b. Workflow Tier Adjustment

Each gate file carries its own tier reductions (see Section 2). Two rules apply across all of them:

How to apply: run the loaded gate's checklist, then apply that file's tier

reduction for the tier resolved in Section 1. drop = not checked at this

tier; → recommended = absent surfaces as CONCERNS, never a Blocker; items

not named keep their baseline status. Reductions only ever relax a

requirement — the only thing that adds one is workflow_overrides (below).

**qa.level (Section 1) further relaxes the test items independently of the

tier:** at qa.level: minimal the test-evidence / unit-test items become

non-required at every workflow tier (so even workflow: full does not require

them); the Section 3 testing.strict check is then a no-op.

The smoke check is excluded from that relaxation, and is the floor.

qa.level relaxes per-story test evidence; a smoke check is build health,

not story evidence, and the two are already held apart on exactly this basis in

.claude/docs/coding-standards.md ("/smoke-check is a build-health gate, not

a per-story evidence gate ... This divergence is intentional"). So a gate file

that requires a smoke report keeps requiring it at every qa.level.

Without that exclusion the Production → Polish gate had **zero required

artifacts at rigor: minimal** and could not fail on artifacts by

construction: minimal reduced the gate to the smoke check alone, qa.level

then dropped the smoke check too, and one modes.rigor setting fires both. Two

agents found it independently on the same fixture.

**A gate with no required artifacts left must say so, and may not return

PASS.** After applying the tier reduction and the qa.level relaxation, count

what remains required. If the count is zero, report

NOT ASSESSED naming both reducers and the gate — *"Production → Polish at

workflow: minimal + qa.level: minimal leaves no required artifact; this

gate verified nothing"* — rather than a PASS earned by having nothing to check.

Per .claude/rules/skill-authoring.md obligation 1, a run that could not

assess its scope has not established that the scope is good, and obligation 3

requires the emptiness to be visible in the output rather than inferable from

a silent green.

**performance.enforce is likewise independent of the tier, and a tier