Files
pixelheros/CCGS Skill Testing Framework/skills/gate/gate-check.md
2026-05-15 14:52:29 +08:00

8.0 KiB

Skill Test Spec: /gate-check

Skill Summary

/gate-check validates whether the project is ready to advance to the next development phase. It checks for required artifacts, runs quality checks, asks the user about unverifiable items, and produces a PASS/CONCERNS/FAIL verdict. On PASS with user confirmation, it writes the new stage name to production/stage.txt. It governs all 6 phase transitions and is the most critical gate-keeping skill in the pipeline.


Static Assertions (Structural)

Verified automatically by /skill-test static — no fixture needed.

  • Has required frontmatter fields: name, description, argument-hint, user-invocable, allowed-tools
  • Has ≥2 phase headings (numbered Phase N or ## sections)
  • Contains verdict keywords: PASS, CONCERNS, FAIL
  • Contains "May I write" collaborative protocol language
  • Has a next-step handoff at the end (Follow-Up Actions section)

Test Cases

Case 1: Happy Path — All Concept artifacts present, advancing to Systems Design

Fixture:

  • design/gdd/game-concept.md exists, has content including all required sections
  • design/gdd/game-pillars.md exists (or pillars defined within concept doc)
  • No systems index yet (which is correct for this stage)

Input: /gate-check systems-design

Expected behavior:

  1. Skill reads design/gdd/game-concept.md and verifies it has content
  2. Skill checks for game pillars (in concept or separate file)
  3. Skill checks quality items (core loop described, target audience identified)
  4. Skill outputs structured checklist with all items marked
  5. Skill presents PASS/CONCERNS/FAIL verdict
  6. If PASS: skill asks "May I update production/stage.txt to 'Systems Design'?"

Assertions:

  • Skill uses Glob or Read to verify design/gdd/game-concept.md exists before marking it checked
  • Output includes a "Required Artifacts" section with check status per item
  • Output includes a "Quality Checks" section with check status per item
  • Output includes a "Verdict" line with one of PASS / CONCERNS / FAIL
  • Skill asks about unverifiable quality items (e.g., "Has this been reviewed?") rather than assuming PASS
  • Skill asks "May I write" before updating production/stage.txt
  • Skill does NOT write production/stage.txt without explicit user confirmation

Case 2: Failure Path — Missing required artifacts for Concept → Systems Design

Fixture:

  • design/gdd/game-concept.md does NOT exist
  • No game pillars document exists
  • design/gdd/ directory is empty or absent

Input: /gate-check systems-design

Expected behavior:

  1. Skill attempts to read design/gdd/game-concept.md — file not found
  2. Skill marks required artifact as missing (not present)
  3. Skill outputs FAIL verdict
  4. Skill lists blocker: "No game concept document found"
  5. Skill suggests remediation: run /brainstorm to create one

Assertions:

  • Verdict is FAIL (not PASS or CONCERNS) when required artifacts are missing
  • Output explicitly names design/gdd/game-concept.md as missing
  • Output includes a "Blockers" section with at least 1 item
  • Output recommends /brainstorm as the remediation action
  • Skill does NOT write production/stage.txt when verdict is FAIL

Case 3: No Argument — Auto-detect current stage

Fixture:

  • production/stage.txt contains Concept
  • design/gdd/game-concept.md exists with content
  • No systems index yet

Input: /gate-check (no argument)

Expected behavior:

  1. Skill reads production/stage.txt to determine current stage
  2. Skill determines the next gate is Concept → Systems Design
  3. Skill proceeds with the Systems Design gate checks
  4. Output clearly states which transition is being validated

Assertions:

  • Skill reads production/stage.txt (or uses project-stage-detect heuristics) to determine current stage
  • Output header names both current and target phases (e.g., "Gate Check: Concept → Systems Design")
  • Skill does not ask the user which gate to check if current stage is determinable

Case 4: Edge Case — Manual check items flagged correctly

Fixture:

  • All required artifacts for Concept → Systems Design are present
  • No playtest or review record exists (can't auto-verify quality checks)

Input: /gate-check systems-design

Expected behavior:

  1. Skill verifies all artifact files exist
  2. Skill encounters quality check: "Game concept reviewed (not MAJOR REVISION NEEDED)"
  3. Since no review record exists, skill marks item as MANUAL CHECK NEEDED
  4. Skill asks the user: "Has the game concept been reviewed for design quality?"
  5. Skill waits for user input before finalizing verdict

Assertions:

  • Items that cannot be auto-verified are marked [?] MANUAL CHECK NEEDED rather than assumed PASS
  • Skill uses a question to the user for at least one unverifiable quality item
  • Skill does not mark unverifiable items as PASS by default


Case 5: Director Gate — lean vs full vs solo mode

Fixture:

  • production/session-state/review-mode.txt exists (or equivalent state file)
  • All required artifacts for the target gate are present
  • design/gdd/game-concept.md exists

Case 5a — full mode:

  • review-mode.txt contains full

Input: /gate-check systems-design (with full mode active)

Expected behavior:

  1. Skill reads review mode — determines full
  2. Skill spawns all 4 PHASE-GATE director prompts in parallel:
    • CD-PHASE-GATE (creative-director)
    • TD-PHASE-GATE (technical-director)
    • PR-PHASE-GATE (producer)
    • AD-PHASE-GATE (art-director)
  3. If one director returns CONCERNS → overall gate verdict is at minimum CONCERNS
  4. All 4 verdicts are collected before producing final output

Assertions (5a):

  • Skill reads review-mode before deciding which directors to spawn
  • All 4 PHASE-GATE director prompts are spawned (not just 1 or 2)
  • Directors are spawned in parallel (simultaneous, not sequential)
  • A CONCERNS verdict from any one director propagates to overall verdict
  • Verdict is NOT auto-PASS if any director returns CONCERNS or REJECT

Case 5b — solo mode:

  • review-mode.txt contains solo

Input: /gate-check systems-design (with solo mode active)

Expected behavior:

  1. Skill reads review mode — determines solo
  2. Each director is noted as skipped: "[CD-PHASE-GATE] skipped — Solo mode"
  3. Gate verdict is derived from artifact/quality checks only
  4. No director gates spawn

Assertions (5b):

  • No director gates are spawned in solo mode
  • Each skipped gate is explicitly noted in output: "[GATE-ID] skipped — Solo mode"
  • Verdict is based on artifact and quality checks only

Note on Case 3 correction: The Case 3 assertions previously stated "Skill does not ask the user which gate to check if current stage is determinable." This is correct. However, the skill DOES use AskUserQuestion to confirm the auto-detected transition before running full checks — this is a confirmation step, not a gate selection. Assertions for Case 3 should not treat this confirmation as a failure.


Protocol Compliance

  • Uses "May I write" before updating production/stage.txt
  • Presents the full checklist report before asking for write approval
  • Ends with a "Follow-Up Actions" section listing next steps per verdict
  • Never advances the stage without explicit user confirmation
  • Never auto-creates production/stage.txt if it doesn't exist without asking

Coverage Notes

  • The Production → Polish and Polish → Release gates are not covered here because they require complex multi-artifact setups (sprint plans, playtest data, QA sign-off); these are deferred to dedicated follow-up specs.
  • The "CONCERNS" verdict path (minor gaps, not blocking) is not explicitly tested here; it falls between Case 1 and Case 2 and follows the same pattern.
  • The Vertical Slice validation block (Pre-Production → Production gate) is not covered because it requires a playable build context that cannot be expressed as a document fixture.