添加 claude code game studios 到项目
This commit is contained in:
panw
200
CCGS Skill Testing Framework/skills/gate/gate-check.md
Normal file
200
CCGS Skill Testing Framework/skills/gate/gate-check.md
Normal file
@@ -0,0 +1,200 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user