mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 10:17:06 +00:00
DonchitosandClaude Opus 5
d05699707f
`project.yaml` at the repo root is now the single source of truth for a project's configuration, replacing `production/stage.txt`, `production/review-mode.txt` and `.claude/docs/technical-preferences.md` (all three still read as a fallback; nothing is force-deleted). **`modes.rigor` — one question instead of six.** `minimal`, `standard` or `full` fronts six knobs: `modes.workflow`, `docs.density`, `qa.level`, `modes.story_granularity`, `modes.review_mode` and `team.size`. It defaults to `minimal`, which is a change from 1.0's behaviour: the heavier tier was measured costing several times more to reach working code without producing a better result, and returning nothing when a fresh developer inherited the project. Pin `modes.rigor: standard` to keep 1.0's process level. Also in this release: - `/settings` to view or change any setting, and `project.local.yaml` for per-developer preferences that should not be committed. - `system_overrides` to hold one system to a higher standard than the rest of the project, and `testing.strict` to set per test type whether missing evidence blocks a story or warns. - A story that changes anything the player sees is not closed until the game has been launched, observed, and a screenshot retained in `production/qa/evidence/`. A parse check is not a run. This holds at every rigor level, including `minimal`, where automated tests are waived but the look is not. - The code root is engine-specific and enforced as such: Godot `src/`, Unity `Assets/`, Unreal `Source/<Module>/`. Two of the three will not build a project laid out any other way. - Migration tooling for existing projects: `.claude/scripts/migrate-v1-config.sh` converts a 1.0 layout, non-destructively by default, with a report to review before `--finalize` deletes anything. - Ask-before-write holds regardless of personal automation settings. Upgrading from 1.0 or earlier: see UPGRADING.md. Full list of changes: CHANGELOG.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016xvzG3i7pWQg4LjyDwWMXd
200 lines
7.9 KiB
Markdown
200 lines
7.9 KiB
Markdown
# 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:**
|
|
The skill does not ask which gate to check when the current stage is determinable.
|
|
It DOES use AskUserQuestion to confirm the auto-detected transition before running
|
|
full checks — that is a confirmation step, not a gate selection. Assertions for
|
|
Case 3 must 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.
|