pan/pixelheros
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

添加 claude code game studios 到项目

Browse Source
This commit is contained in:
panw
2026-05-15 14:52:29 +08:00
parent dff559462d
commit a16fe4bff7
415 changed files with 78609 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

197
CCGS Skill Testing Framework/skills/authoring/architecture-decision.md Normal file
View File

@@ -0,0 +1,197 @@
# Skill Test Spec: /architecture-decision
## Skill Summary
`/architecture-decision` guides the user through section-by-section authoring of
a new Architecture Decision Record (ADR). Required sections are: Status, Context,
Decision, Consequences, Alternatives, and Related ADRs. The skill also stamps the
engine version reference from `docs/engine-reference/` into the ADR for traceability.
In `full` review mode, TD-ADR (technical-director) and LP-FEASIBILITY
(lead-programmer) gate agents spawn after the draft is complete. If both gates
return APPROVED, the ADR status is set to Accepted. In `lean` or `solo` mode,
both gates are skipped and the ADR is written with Status: Proposed. The skill
asks "May I write" per section during authoring. ADRs are written to
`docs/architecture/adr-NNN-[name].md`.
---
## 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
- [ ] Contains verdict keywords: ACCEPTED, PROPOSED, CONCERNS
- [ ] Contains "May I write" collaborative protocol language (per-section approval)
- [ ] Has a next-step handoff at the end
- [ ] Documents gate behavior: TD-ADR + LP-FEASIBILITY in full mode; skipped in lean/solo
- [ ] Documents that ADR status is Accepted (full, gates approve) or Proposed (otherwise)
- [ ] Mentions engine version stamp from `docs/engine-reference/`
---
## Director Gate Checks
In `full` mode: TD-ADR (technical-director) and LP-FEASIBILITY (lead-programmer)
spawn after the ADR draft is complete. If both return APPROVED, ADR Status is set
to Accepted. If either returns CONCERNS or FAIL, ADR stays Proposed.
In `lean` mode: both gates are skipped. ADR is written with Status: Proposed.
Output notes: "TD-ADR skipped — lean mode" and "LP-FEASIBILITY skipped — lean mode".
In `solo` mode: both gates are skipped. ADR is written with Status: Proposed.
---
## Test Cases
### Case 1: Happy Path — New ADR for rendering approach, full mode, gates approve
**Fixture:**
- `docs/architecture/` exists with no existing ADR for rendering
- `docs/engine-reference/[engine]/VERSION.md` exists
- `production/session-state/review-mode.txt` contains `full`
**Input:** `/architecture-decision rendering-approach`
**Expected behavior:**
1. Skill guides user through each required section (Status, Context, Decision, Consequences, Alternatives, Related ADRs)
2. Engine version is stamped into the ADR from `docs/engine-reference/`
3. For each section: draft shown, "May I write this section?" asked, approved
4. After all sections: TD-ADR and LP-FEASIBILITY gates spawn in parallel
5. Both gates return APPROVED
6. ADR Status is set to Accepted
7. Skill writes `docs/architecture/adr-NNN-rendering-approach.md`
8. `docs/architecture/tr-registry.yaml` updated if new TR-IDs are defined
**Assertions:**
- [ ] All 6 required sections are authored and written
- [ ] Engine version reference is stamped in the ADR
- [ ] TD-ADR and LP-FEASIBILITY spawn in parallel (not sequentially)
- [ ] ADR Status is Accepted when both gates return APPROVED in full mode
- [ ] "May I write" is asked per section during authoring
- [ ] File is written to `docs/architecture/adr-NNN-[name].md`
---
### Case 2: Failure Path — TD-ADR returns CONCERNS
**Fixture:**
- ADR draft is complete (all sections filled)
- `production/session-state/review-mode.txt` contains `full`
- TD-ADR gate returns CONCERNS: "The decision does not address [specific concern]"
**Input:** `/architecture-decision [topic]`
**Expected behavior:**
1. TD-ADR gate spawns and returns CONCERNS with specific feedback
2. Skill surfaces the concerns to the user
3. ADR Status remains Proposed (not Accepted)
4. User is asked: revise the decision to address concerns, or accept as Proposed
5. ADR is written with Status: Proposed if concerns are not resolved
**Assertions:**
- [ ] TD-ADR concerns are shown to the user verbatim
- [ ] ADR Status is Proposed (not Accepted) when TD-ADR returns CONCERNS
- [ ] Skill does NOT set Status: Accepted while CONCERNS are unresolved
- [ ] User is given the option to revise and re-run the gate
---
### Case 3: Lean Mode — Both gates skipped; ADR written as Proposed
**Fixture:**
- `production/session-state/review-mode.txt` contains `lean`
- ADR draft is authored for a new technical decision
**Input:** `/architecture-decision [topic]`
**Expected behavior:**
1. Skill guides user through all 6 sections
2. After draft is complete: both TD-ADR and LP-FEASIBILITY are skipped
3. Output notes: "TD-ADR skipped — lean mode" and "LP-FEASIBILITY skipped — lean mode"
4. ADR is written with Status: Proposed (not Accepted, since gates did not approve)
5. "May I write" is still asked before the final file write
**Assertions:**
- [ ] Both gate skip notes appear in output
- [ ] ADR Status is Proposed (not Accepted) in lean mode
- [ ] "May I write" is still asked before writing the file
- [ ] Skill writes the ADR after user approval
---
### Case 4: Edge Case — ADR already exists for this topic
**Fixture:**
- `docs/architecture/` contains an existing ADR covering the same topic
- The existing ADR has Status: Accepted
**Input:** `/architecture-decision [same-topic]`
**Expected behavior:**
1. Skill detects an existing ADR covering the same topic
2. Skill asks: "An ADR for [topic] already exists ([filename]). Update it, or create a new superseding ADR?"
3. User selects update or supersede
4. Skill does NOT silently create a duplicate ADR
**Assertions:**
- [ ] Skill detects the existing ADR before authoring begins
- [ ] User is offered update or supersede options — no silent duplicate
- [ ] If update: skill opens the existing ADR for section-by-section revision
- [ ] If supersede: new ADR references the superseded one in Related ADRs section
---
### Case 5: Director Gate — Status set correctly based on mode and gate outcome
**Fixture:**
- ADR draft is complete
- Two scenarios: (a) full mode, both gates APPROVED; (b) full mode, one gate CONCERNS
**Full mode, both APPROVED:**
- ADR Status is set to Accepted
**Assertions (both approved):**
- [ ] ADR frontmatter/header shows `Status: Accepted`
- [ ] Both TD-ADR and LP-FEASIBILITY appear as APPROVED in output
**Full mode, one gate returns CONCERNS:**
- ADR Status stays Proposed
**Assertions (CONCERNS):**
- [ ] ADR frontmatter/header shows `Status: Proposed`
- [ ] Concerns are listed in output
- [ ] Skill does NOT set Status: Accepted when any gate returns CONCERNS
**Lean/solo mode:**
- ADR Status is always Proposed regardless of content quality
**Assertions (lean/solo):**
- [ ] ADR Status is Proposed in lean mode
- [ ] ADR Status is Proposed in solo mode
- [ ] No gate output appears in lean or solo mode
---
## Protocol Compliance
- [ ] All 6 required sections authored before gate review
- [ ] Engine version stamped in ADR from `docs/engine-reference/`
- [ ] "May I write" asked per section during authoring
- [ ] TD-ADR and LP-FEASIBILITY spawn in parallel in full mode
- [ ] Skipped gates noted by name and mode in lean/solo output
- [ ] ADR Status: Accepted only when full mode AND both gates APPROVED
- [ ] Ends with next-step handoff: `/architecture-review` or `/create-control-manifest`
---
## Coverage Notes
- ADR numbering (auto-incrementing NNN) is not independently fixture-tested —
the skill reads existing ADR filenames to assign the next number.
- Related ADRs section linking (supersedes / related-to) is tested structurally
via Case 4 but not all link types are individually verified.
- The TR-registry update (when new TR-IDs are defined in the ADR) is part of the
write phase — tested implicitly via Case 1.

185
CCGS Skill Testing Framework/skills/authoring/art-bible.md Normal file
View File

@@ -0,0 +1,185 @@
# Skill Test Spec: /art-bible
## Skill Summary
`/art-bible` is a guided, section-by-section art bible authoring skill. It
produces a comprehensive visual direction document covering: Visual Style overview,
Color Palette, Typography, Character Design Rules, Environment Style, and UI
Visual Language. The skill follows the skeleton-first pattern: creates the file
with all section headers immediately, then fills each section through discussion
and writes each to disk after user approval.
In `full` review mode, the AD-ART-BIBLE director gate (art director) runs after
the draft is complete and before any section is written. In `lean` and `solo`
modes, AD-ART-BIBLE is skipped and only user approval is required. The verdict
is COMPLETE when all sections are written.
---
## 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
- [ ] Contains verdict keyword: COMPLETE
- [ ] Contains "May I write" language per section
- [ ] Documents the AD-ART-BIBLE director gate and its mode behavior
- [ ] Has a next-step handoff (e.g., `/asset-spec` or `/design-system`)
---
## Director Gate Checks
| Gate ID | Trigger condition | Mode guard |
|--------------|--------------------------------|-----------------------|
| AD-ART-BIBLE | After draft is complete | full only (not lean/solo) |
---
## Test Cases
### Case 1: Happy Path — Full mode, art bible drafted, AD-ART-BIBLE approves
**Fixture:**
- No existing `design/art-bible.md`
- `production/session-state/review-mode.txt` contains `full`
- `design/gdd/game-concept.md` exists with visual tone described
**Input:** `/art-bible`
**Expected behavior:**
1. Skill creates skeleton `design/art-bible.md` with all section headers
2. Skill discusses and drafts each section with user collaboration
3. After all sections are drafted, AD-ART-BIBLE gate is invoked (art director review)
4. AD-ART-BIBLE returns APPROVED
5. Skill asks "May I write section [N] to `design/art-bible.md`?" per section
6. All sections written after approval; verdict is COMPLETE
**Assertions:**
- [ ] Skeleton file is created first (before any section content is written)
- [ ] AD-ART-BIBLE gate is invoked in full mode after draft is complete
- [ ] Gate approval precedes the "May I write" section asks
- [ ] All sections are present in the final file
- [ ] Verdict is COMPLETE
---
### Case 2: AD-ART-BIBLE Returns CONCERNS — Section revised before writing
**Fixture:**
- Art bible draft complete
- `production/session-state/review-mode.txt` contains `full`
- AD-ART-BIBLE gate returns CONCERNS: "Color palette clashes with the dark
atmospheric tone described in the game concept"
**Input:** `/art-bible`
**Expected behavior:**
1. AD-ART-BIBLE gate returns CONCERNS with specific feedback about palette
2. Skill surfaces feedback to user: "Art director has concerns about the color palette"
3. Skill returns to the Color Palette section for revision
4. User and skill revise the palette to align with game concept tone
5. AD-ART-BIBLE is not re-invoked (user decides to proceed after revision)
6. Revised section is written after "May I write" approval; verdict is COMPLETE
**Assertions:**
- [ ] CONCERNS are shown to user before any section is written
- [ ] Skill returns to the affected section for revision (not all sections)
- [ ] Revised content (not original) is written to file
- [ ] Verdict is COMPLETE after revision and approval
---
### Case 3: Lean Mode — AD-ART-BIBLE Skipped, Written With User Approval Only
**Fixture:**
- No existing art bible
- `production/session-state/review-mode.txt` contains `lean`
**Input:** `/art-bible`
**Expected behavior:**
1. Skill reads review mode — determines `lean`
2. Skill drafts all sections with user collaboration
3. AD-ART-BIBLE gate is skipped: output notes "[AD-ART-BIBLE] skipped — lean mode"
4. Skill asks user for direct approval of each section
5. Sections are written after user confirmation; verdict is COMPLETE
**Assertions:**
- [ ] AD-ART-BIBLE gate is NOT invoked in lean mode
- [ ] Skip is explicitly noted: "[AD-ART-BIBLE] skipped — lean mode"
- [ ] User approval is still required per section (gate skip ≠ approval skip)
- [ ] Verdict is COMPLETE
---
### Case 4: Existing Art Bible — Retrofit Mode
**Fixture:**
- `design/art-bible.md` already exists with all sections populated
- User wants to update the Character Design Rules section
**Input:** `/art-bible`
**Expected behavior:**
1. Skill reads existing art bible and detects all sections populated
2. Skill offers retrofit: "Art bible exists — which section would you like to update?"
3. User selects Character Design Rules
4. Skill drafts updated content; in full mode, AD-ART-BIBLE is invoked for the
revised section before writing
5. Skill asks "May I write Character Design Rules to `design/art-bible.md`?"
6. Only that section is updated; other sections preserved; verdict is COMPLETE
**Assertions:**
- [ ] Existing art bible is detected and retrofit is offered
- [ ] Only the selected section is updated
- [ ] In full mode: AD-ART-BIBLE gate runs even for single-section retrofit
- [ ] Other sections are preserved
- [ ] Verdict is COMPLETE
---
### Case 5: Solo Mode — AD-ART-BIBLE Skipped, Noted in Output
**Fixture:**
- No existing art bible
- `production/session-state/review-mode.txt` contains `solo`
**Input:** `/art-bible`
**Expected behavior:**
1. Skill reads review mode — determines `solo`
2. Art bible is drafted and written with only user approval
3. AD-ART-BIBLE gate is skipped: output notes "[AD-ART-BIBLE] skipped — solo mode"
4. No director agents are spawned
5. Verdict is COMPLETE
**Assertions:**
- [ ] AD-ART-BIBLE gate is NOT invoked in solo mode
- [ ] Skip is explicitly noted with "solo mode" label
- [ ] No director agents of any kind are spawned
- [ ] Verdict is COMPLETE
---
## Protocol Compliance
- [ ] Creates skeleton file immediately with all section headers
- [ ] Discusses and drafts one section at a time
- [ ] AD-ART-BIBLE gate runs in full mode after all sections are drafted
- [ ] AD-ART-BIBLE is skipped in lean and solo modes — noted by name
- [ ] Asks "May I write section [N]" per section
- [ ] Verdict is COMPLETE when all sections are written
---
## Coverage Notes
- The case where AD-ART-BIBLE returns REJECT (not just CONCERNS) is not
separately tested; the skill would block writing and ask the user how to
proceed (revise or override).
- The Typography section is listed as a required art bible section but its
specific content requirements are not assertion-tested here.
- The art bible feeds into `/asset-spec` — this relationship is noted in the
handoff but not tested as part of this skill's spec.

187
CCGS Skill Testing Framework/skills/authoring/create-architecture.md Normal file
View File

@@ -0,0 +1,187 @@
# Skill Test Spec: /create-architecture
## Skill Summary
`/create-architecture` guides the user through section-by-section authoring of a
technical architecture document. It uses a skeleton-first approach — the file is
created with all required section headers before any content is filled. Each
section is discussed, drafted, and written individually after user approval. If an
architecture document already exists, the skill offers retrofit mode to update
specific sections.
In `full` review mode, TD-ARCHITECTURE (technical-director) and LP-FEASIBILITY
(lead-programmer) spawn after the complete draft is finished. In `lean` or `solo`
mode, both gates are skipped. The skill writes to `docs/architecture/architecture.md`.
---
## 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
- [ ] Contains verdict keywords: APPROVED, NEEDS REVISION, MAJOR REVISION NEEDED
- [ ] Contains "May I write" collaborative protocol language (per-section approval)
- [ ] Has a next-step handoff at the end (`/architecture-review` or `/create-control-manifest`)
- [ ] Documents skeleton-first approach
- [ ] Documents gate behavior: TD-ARCHITECTURE + LP-FEASIBILITY in full mode; skipped in lean/solo
- [ ] Documents retrofit mode for existing architecture documents
---
## Director Gate Checks
In `full` mode: TD-ARCHITECTURE (technical-director) and LP-FEASIBILITY
(lead-programmer) spawn in parallel after all sections are drafted and before
any final approval write.
In `lean` mode: both gates are skipped. Output notes:
"TD-ARCHITECTURE skipped — lean mode" and "LP-FEASIBILITY skipped — lean mode".
In `solo` mode: both gates are skipped with equivalent notes.
---
## Test Cases
### Case 1: Happy Path — New architecture doc, skeleton-first, full mode gates approve
**Fixture:**
- No existing `docs/architecture/architecture.md`
- `docs/architecture/` contains Accepted ADRs for reference
- `production/session-state/review-mode.txt` contains `full`
**Input:** `/create-architecture`
**Expected behavior:**
1. Skill creates skeleton `docs/architecture/architecture.md` with all required section headers
2. For each section: drafts content, shows draft, asks "May I write [section]?", writes after approval
3. After all sections are drafted: TD-ARCHITECTURE and LP-FEASIBILITY spawn in parallel
4. Both gates return APPROVED
5. Final "May I confirm architecture is complete?" asked
6. Session state updated
**Assertions:**
- [ ] Skeleton file is created with all section headers before any content is written
- [ ] "May I write [section]?" asked per section during authoring
- [ ] TD-ARCHITECTURE and LP-FEASIBILITY spawn in parallel (not sequentially)
- [ ] Both gates complete before the final completion confirmation
- [ ] Verdict is APPROVED when both gates return APPROVED
- [ ] Next-step handoff to `/architecture-review` or `/create-control-manifest` is present
---
### Case 2: Failure Path — TD-ARCHITECTURE returns MAJOR REVISION
**Fixture:**
- Architecture doc is fully drafted (all sections)
- `production/session-state/review-mode.txt` contains `full`
- TD-ARCHITECTURE gate returns MAJOR REVISION: "[specific structural issue]"
**Input:** `/create-architecture`
**Expected behavior:**
1. All sections are drafted and written
2. TD-ARCHITECTURE gate runs and returns MAJOR REVISION with specific feedback
3. Skill surfaces the feedback to the user
4. Architecture is NOT marked as finalized
5. User is asked: revise the flagged sections, or accept the document as a draft
**Assertions:**
- [ ] Architecture is NOT marked finalized when TD-ARCHITECTURE returns MAJOR REVISION
- [ ] Gate feedback is shown to the user with specific issue descriptions
- [ ] User is given the option to revise specific sections
- [ ] Skill does NOT auto-finalize despite MAJOR REVISION feedback
---
### Case 3: Lean Mode — Both gates skipped; architecture written with user approval only
**Fixture:**
- No existing architecture doc
- `production/session-state/review-mode.txt` contains `lean`
**Input:** `/create-architecture`
**Expected behavior:**
1. Skeleton file is created
2. All sections are authored and written per-section with user approval
3. After completion: TD-ARCHITECTURE and LP-FEASIBILITY are skipped
4. Output notes: "TD-ARCHITECTURE skipped — lean mode" and "LP-FEASIBILITY skipped — lean mode"
5. Architecture is considered complete based on user approval alone
**Assertions:**
- [ ] Both gate skip notes appear in output
- [ ] Architecture document is written with only user approval in lean mode
- [ ] Skill does NOT block completion because gates were skipped
- [ ] Next-step handoff is still present
---
### Case 4: Retrofit Mode — Existing architecture doc, user updates a section
**Fixture:**
- `docs/architecture/architecture.md` already exists with all sections populated
**Input:** `/create-architecture`
**Expected behavior:**
1. Skill detects existing architecture doc and reads its current content
2. Skill offers retrofit mode: "Architecture doc already exists. Which section would you like to update?"
3. User selects a section
4. Skill authors only that section, asks "May I write [section]?"
5. Only the selected section is updated — other sections unchanged
**Assertions:**
- [ ] Skill detects and reads the existing architecture doc before offering retrofit
- [ ] User is asked which section to update — not asked to rewrite the whole document
- [ ] Only the selected section is updated
- [ ] Other sections are not modified during a retrofit session
---
### Case 5: Director Gate — Architecture references a Proposed ADR; flagged as risk
**Fixture:**
- Architecture doc is being authored
- One section references or depends on an ADR that has `Status: Proposed`
- `production/session-state/review-mode.txt` contains `full`
**Input:** `/create-architecture`
**Expected behavior:**
1. Skill authors all sections
2. During authoring, skill detects a reference to a Proposed ADR
3. Skill flags: "Note: [section] references ADR-NNN which is Proposed — this is a risk until the ADR is accepted"
4. Risk flag is embedded in the relevant section's content
5. TD-ARCHITECTURE and LP-FEASIBILITY still run — they are informed of the Proposed ADR risk
**Assertions:**
- [ ] Proposed ADR reference is detected and flagged during section authoring
- [ ] Risk note is embedded in the architecture document section
- [ ] TD-ARCHITECTURE and LP-FEASIBILITY still spawn (the risk does not block the gates)
- [ ] Risk flag names the specific ADR number and title
---
## Protocol Compliance
- [ ] Skeleton file created with all section headers before any content is written
- [ ] "May I write [section]?" asked per section during authoring
- [ ] TD-ARCHITECTURE and LP-FEASIBILITY spawn in parallel in full mode
- [ ] Skipped gates noted by name and mode in lean/solo output
- [ ] Proposed ADR references flagged as risks in the document
- [ ] Ends with next-step handoff: `/architecture-review` or `/create-control-manifest`
---
## Coverage Notes
- The required section list for architecture documents is defined in the skill
body and in the `/architecture-review` skill — not re-enumerated here.
- Engine version stamping in the architecture doc (parallel to ADR stamping)
is part of the authoring workflow — tested implicitly via Case 1.
- The retrofit mode for updating multiple sections in one session follows the
same per-section approval pattern — not independently tested for multi-section
retrofits.

192
CCGS Skill Testing Framework/skills/authoring/design-system.md Normal file
View File

@@ -0,0 +1,192 @@
# Skill Test Spec: /design-system
## Skill Summary
`/design-system` guides the user through section-by-section authoring of a Game
Design Document (GDD) for a single game system. All 8 required sections must be
authored: Overview, Player Fantasy, Detailed Rules, Formulas, Edge Cases,
Dependencies, Tuning Knobs, and Acceptance Criteria. The skill uses a
skeleton-first approach — it creates the GDD file with all 8 section headers
before filling any content — and writes each section individually after approval.
The CD-GDD-ALIGN gate (creative-director) runs in both `full` AND `lean` modes.
It is only skipped in `solo` mode. If an existing GDD file is found, the skill
offers a retrofit mode to update specific sections rather than rewriting the whole
document.
---
## 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
- [ ] Contains verdict keywords: APPROVED, NEEDS REVISION, MAJOR REVISION
- [ ] Contains "May I write" collaborative protocol language (per-section approval)
- [ ] Has a next-step handoff at the end
- [ ] Documents skeleton-first approach (file created with headers before content)
- [ ] Documents CD-GDD-ALIGN gate: active in full AND lean mode; skipped in solo only
- [ ] Documents retrofit mode for existing GDD files
---
## Director Gate Checks
In `full` mode: CD-GDD-ALIGN (creative-director) gate runs after each section is
drafted, before writing. If MAJOR REVISION is returned, the section must be
rewritten before proceeding.
In `lean` mode: CD-GDD-ALIGN still runs (this gate is NOT skipped in lean mode —
it runs in both full and lean). Only solo mode skips it.
In `solo` mode: CD-GDD-ALIGN is skipped. Output notes:
"CD-GDD-ALIGN skipped — solo mode". Sections are written with only user approval.
---
## Test Cases
### Case 1: Happy Path — New GDD, skeleton-first, CD-GDD-ALIGN in lean mode
**Fixture:**
- No existing GDD for the target system in `design/gdd/`
- `production/session-state/review-mode.txt` contains `lean`
**Input:** `/design-system [system-name]`
**Expected behavior:**
1. Skill creates skeleton file `design/gdd/[system-name].md` with all 8 section headers (empty bodies)
2. For each section: discusses with user, drafts content, shows draft
3. CD-GDD-ALIGN gate runs on each section draft (lean mode — gate is active)
4. Gate returns APPROVED for each section
5. "May I write [section]?" asked after gate approval
6. Section written to file after user approval
7. Process repeats for all 8 sections
**Assertions:**
- [ ] Skeleton file is created with all 8 section headers before any content is written
- [ ] CD-GDD-ALIGN runs on each section in lean mode (not skipped)
- [ ] "May I write" is asked per section (not once for all sections)
- [ ] Each section is written individually after gate + user approval
- [ ] All 8 sections are present in the final GDD file
---
### Case 2: Retrofit Mode — Existing GDD, update specific section
**Fixture:**
- `design/gdd/[system-name].md` already exists with all 8 sections populated
**Input:** `/design-system [system-name]`
**Expected behavior:**
1. Skill detects existing GDD file and reads its current content
2. Skill offers retrofit mode: "GDD already exists. Which section would you like to update?"
3. User selects a specific section (e.g., Formulas)
4. Skill authors only that section, runs CD-GDD-ALIGN, asks "May I write?"
5. Only the selected section is updated — other sections are not modified
**Assertions:**
- [ ] Skill detects and reads existing GDD before offering retrofit mode
- [ ] User is asked which section to update — not asked to rewrite the whole document
- [ ] Only the selected section is rewritten — others remain unchanged
- [ ] CD-GDD-ALIGN still runs on the updated section
- [ ] "May I write" is asked before updating the section
---
### Case 3: Director Gate — CD-GDD-ALIGN returns MAJOR REVISION
**Fixture:**
- New GDD being authored
- `production/session-state/review-mode.txt` contains `lean`
- CD-GDD-ALIGN gate returns MAJOR REVISION on the Player Fantasy section
**Input:** `/design-system [system-name]`
**Expected behavior:**
1. Player Fantasy section is drafted
2. CD-GDD-ALIGN gate runs and returns MAJOR REVISION with specific feedback
3. Skill surfaces the feedback to the user
4. Section is NOT written to file while MAJOR REVISION is unresolved
5. User rewrites the section in collaboration with the skill
6. CD-GDD-ALIGN runs again on the revised section
7. If revised section passes, "May I write?" is asked and section is written
**Assertions:**
- [ ] Section is NOT written when CD-GDD-ALIGN returns MAJOR REVISION
- [ ] Gate feedback is shown to the user before requesting revision
- [ ] CD-GDD-ALIGN runs again after the section is revised
- [ ] Skill does NOT auto-proceed to the next section while MAJOR REVISION is unresolved
---
### Case 4: Solo Mode — CD-GDD-ALIGN skipped; sections written with user approval only
**Fixture:**
- New GDD being authored
- `production/session-state/review-mode.txt` contains `solo`
**Input:** `/design-system [system-name]`
**Expected behavior:**
1. Skeleton file is created with 8 section headers
2. For each section: drafted, shown to user
3. CD-GDD-ALIGN is skipped — noted per section: "CD-GDD-ALIGN skipped — solo mode"
4. "May I write [section]?" asked after user reviews draft
5. Section written after user approval
6. No gate review at any stage
**Assertions:**
- [ ] "CD-GDD-ALIGN skipped — solo mode" noted for each section
- [ ] Sections are written after user approval alone (no gate required)
- [ ] Skill does NOT spawn any CD-GDD-ALIGN gate in solo mode
- [ ] Full GDD is written with only user approval in solo mode
---
### Case 5: Director Gate — Empty sections not written to file
**Fixture:**
- GDD authoring in progress
- User and skill discuss one section but do not produce any approved content
(e.g., discussion ends without a decision, or user says "skip for now")
**Input:** `/design-system [system-name]`
**Expected behavior:**
1. Section discussion produces no approved content
2. Skill does NOT write an empty or placeholder body to the section
3. The section header remains in the skeleton file but the body stays empty
4. Skill moves to the next section without writing the empty one
5. At the end, incomplete sections are listed and user is reminded to return to them
**Assertions:**
- [ ] Empty or unapproved sections are NOT written to the file
- [ ] Skeleton section header remains (preserves structure)
- [ ] Skill tracks and lists incomplete sections at the end of the session
- [ ] Skill does NOT write "TBD" or placeholder content without user approval
---
## Protocol Compliance
- [ ] Skeleton file created with all 8 headers before any content is written
- [ ] CD-GDD-ALIGN runs in both full AND lean mode (not just full)
- [ ] CD-GDD-ALIGN skipped only in solo mode — noted per section
- [ ] "May I write [section]?" asked per section (not once for the whole document)
- [ ] MAJOR REVISION from CD-GDD-ALIGN blocks section write until resolved
- [ ] Only approved, non-empty sections are written to the file
- [ ] Ends with next-step handoff: `/review-all-gdds` or `/map-systems next`
---
## Coverage Notes
- The 8 required sections are validated against the project's design document
standards defined in `CLAUDE.md` — not re-enumerated here.
- The skill's internal section-ordering logic (which section to author first) is
not independently tested — the order follows the standard GDD template.
- Pillar alignment checking within CD-GDD-ALIGN is evaluated holistically by
the gate agent — specific pillar checks are not fixture-tested here.

176
CCGS Skill Testing Framework/skills/authoring/quick-design.md Normal file
View File

@@ -0,0 +1,176 @@
# Skill Test Spec: /quick-design
## Skill Summary
`/quick-design` produces a lightweight design spec for features too small to
warrant a full 8-section GDD. The target scope is under 4 hours of design time
for a single-system feature. Instead of the full 8-section GDD format, the
quick-design spec uses a streamlined 3-section format: Overview, Rules, and
Acceptance Criteria.
The skill has no director gates — adding gate overhead would defeat the purpose
of a lightweight design tool. The skill asks "May I write" before writing the
design note to `design/quick-notes/[name].md`. If the feature scope is too large
for a quick-design, the skill redirects to `/design-system` instead.
---
## 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
- [ ] Contains verdict keywords: CREATED, BLOCKED, REDIRECTED
- [ ] Contains "May I write" collaborative protocol language (for quick-note file)
- [ ] Has a next-step handoff at the end
- [ ] Explicitly notes: no director gates (lightweight skill by design)
- [ ] Mentions scope check: redirects to `/design-system` if scope exceeds sub-4h threshold
---
## Director Gate Checks
No director gates — this skill spawns no director gate agents. The lightweight
nature of quick-design means director gate overhead is intentionally absent.
Full GDD review is not needed for sub-4-hour single-system features.
---
## Test Cases
### Case 1: Happy Path — Small UI change produces a 3-section spec
**Fixture:**
- No existing quick-note for the target feature
- Feature is clearly scoped: a single UI element change with no cross-system impact
**Input:** `/quick-design [feature-name]`
**Expected behavior:**
1. Skill asks scoping questions: what system, what change, what is the acceptance signal
2. Skill determines scope is within the sub-4h threshold
3. Skill drafts a 3-section spec: Overview, Rules, Acceptance Criteria
4. Draft is shown to user
5. "May I write `design/quick-notes/[name].md`?" is asked
6. File is written after approval
**Assertions:**
- [ ] Spec contains exactly 3 sections: Overview, Rules, Acceptance Criteria
- [ ] Draft is shown to user before "May I write" ask
- [ ] "May I write `design/quick-notes/[name].md`?" is asked before writing
- [ ] File is written to the correct path: `design/quick-notes/[name].md`
- [ ] Verdict is CREATED after successful write
---
### Case 2: Failure Path — Scope check fails; redirected to /design-system
**Fixture:**
- Feature described spans multiple systems or would take more than 4 hours of design time
(e.g., "redesign the entire combat system" or "new progression mechanic affecting all classes")
**Input:** `/quick-design [large-feature]`
**Expected behavior:**
1. Skill asks scoping questions
2. Skill determines scope exceeds the sub-4h / single-system threshold
3. Skill outputs: "This feature is too large for a quick-design. Use `/design-system [name]` for a full GDD."
4. Skill does NOT write a quick-note file
5. Verdict is REDIRECTED
**Assertions:**
- [ ] Skill detects the scope excess and stops before drafting
- [ ] Message explicitly names `/design-system` as the correct alternative
- [ ] No quick-note file is written
- [ ] Verdict is REDIRECTED (not CREATED or BLOCKED)
---
### Case 3: Edge Case — File already exists; offered to update
**Fixture:**
- `design/quick-notes/[name].md` already exists from a previous session
**Input:** `/quick-design [name]`
**Expected behavior:**
1. Skill detects existing quick-note file and reads its current content
2. Skill asks: "[name].md already exists. Update it, or create a new version?"
3. User selects update
4. Skill shows the existing spec and asks which section to revise
5. Updated spec is shown, "May I write?" asked, file updated after approval
**Assertions:**
- [ ] Skill detects and reads the existing file before offering to update
- [ ] User is offered update or create-new options — not auto-overwritten
- [ ] Only the revised section is updated (or the whole spec if user chooses full rewrite)
- [ ] "May I write" is asked before overwriting the existing file
---
### Case 4: Edge Case — No argument provided
**Fixture:**
- `design/quick-notes/` directory may or may not exist
**Input:** `/quick-design` (no argument)
**Expected behavior:**
1. Skill detects no argument is provided
2. Skill outputs a usage error: "No feature name specified. Usage: /quick-design [feature-name]"
3. Skill provides an example: `/quick-design pause-menu-settings`
4. No file is created
**Assertions:**
- [ ] Skill outputs a usage error when no argument is given
- [ ] A usage example is shown with the correct format
- [ ] No quick-note file is written
- [ ] Skill does NOT silently pick a feature name or default to any action
---
### Case 5: Director Gate — No gate spawned; explicitly noted for sub-4h features
**Fixture:**
- Feature is within scope for quick-design
- `production/session-state/review-mode.txt` exists with `full`
**Input:** `/quick-design [feature-name]`
**Expected behavior:**
1. Skill asks scoping questions and determines scope is within threshold
2. Skill does NOT read `production/session-state/review-mode.txt`
3. Skill does NOT spawn any director gate agent
4. Spec is drafted, "May I write" asked, file written after approval
5. Output explicitly notes: "No director gate review — quick-design is for sub-4h features"
**Assertions:**
- [ ] No director gate agents are spawned (no CD-, TD-, PR-, AD- prefixed gates)
- [ ] Skill does NOT read `production/session-state/review-mode.txt`
- [ ] Output contains a note explaining why no gate review is needed
- [ ] Review mode has no effect on this skill's behavior
- [ ] Full GDD review path (`/design-system`) is mentioned as the alternative for larger features
---
## Protocol Compliance
- [ ] Scope check runs before drafting (redirects to `/design-system` if scope too large)
- [ ] 3-section format used (Overview, Rules, Acceptance Criteria) — NOT the 8-section GDD format
- [ ] Draft shown to user before "May I write" ask
- [ ] "May I write `design/quick-notes/[name].md`?" asked before writing
- [ ] No director gates — no review-mode.txt read
- [ ] Ends with next-step handoff (e.g., proceed to implementation or `/dev-story`)
---
## Coverage Notes
- The scope threshold heuristic (sub-4h, single-system) is a judgment call —
the skill's internal check is the authoritative definition and is not
independently tested by counting hours.
- The `design/quick-notes/` directory is created automatically if it does not
exist — this filesystem behavior is not independently tested here.
- Integration with the story pipeline (can a quick-design generate a story
directly?) is out of scope for this spec — quick-designs are standalone.

176
CCGS Skill Testing Framework/skills/authoring/ux-design.md Normal file
View File

@@ -0,0 +1,176 @@
# Skill Test Spec: /ux-design
## Skill Summary
`/ux-design` is a guided, section-by-section UX spec authoring skill. It produces
user flow diagrams (described textually), interaction state definitions, wireframe
descriptions, and accessibility notes for a specified screen or HUD element. The
skill follows the skeleton-first pattern: it creates the file with all section
headers immediately, then fills each section through discussion and writes each
section to disk after user approval.
The skill has no inline director gates — `/ux-review` is the separate review step.
Each section requires a "May I write section [N] to [filepath]?" ask. If a UX spec
already exists for the named screen, the skill offers to retrofit individual sections
rather than replace. Verdict is COMPLETE when all sections are written.
---
## 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
- [ ] Contains verdict keyword: COMPLETE
- [ ] Contains "May I write" language per section
- [ ] Has a next-step handoff (e.g., `/ux-review` to validate the completed spec)
---
## Director Gate Checks
None. `/ux-design` has no inline director gates. `/ux-review` is the separate
review skill invoked after this skill completes.
---
## Test Cases
### Case 1: Happy Path — New HUD spec, all sections authored and written
**Fixture:**
- No existing HUD UX spec in `design/ux/`
- Engine and rendering preferences configured
**Input:** `/ux-design hud`
**Expected behavior:**
1. Skill creates a skeleton file `design/ux/hud.md` with all section headers
2. Skill discusses and drafts each section: User Flows, Interaction States
(normal/hover/focus/disabled), Wireframe Description, Accessibility Notes
3. After each section is drafted and user confirms, skill asks "May I write
section [N] to `design/ux/hud.md`?"
4. Each section is written in sequence after approval
5. After all sections are written, verdict is COMPLETE
6. Skill suggests running `/ux-review` as the next step
**Assertions:**
- [ ] Skeleton file is created first (with empty section bodies)
- [ ] "May I write section [N]" is asked per section (not once at the end)
- [ ] All required sections are present: User Flows, Interaction States,
Wireframe Description, Accessibility Notes
- [ ] Handoff to `/ux-review` is at the end
- [ ] Verdict is COMPLETE
---
### Case 2: Existing UX Spec — Retrofit: user picks section to update
**Fixture:**
- `design/ux/hud.md` already exists with all sections populated
- User wants to update only the Accessibility Notes section
**Input:** `/ux-design hud`
**Expected behavior:**
1. Skill reads existing `design/ux/hud.md` and detects all sections are populated
2. Skill reports: "UX spec already exists for HUD — offering to retrofit"
3. Skill lists all sections and asks which to update
4. User selects Accessibility Notes
5. Skill drafts updated accessibility content and asks "May I write section
Accessibility Notes to `design/ux/hud.md`?"
6. Only that section is updated; other sections are preserved; verdict is COMPLETE
**Assertions:**
- [ ] Existing spec is detected and retrofit is offered
- [ ] User selects which section(s) to update
- [ ] Only the selected section is updated — other sections unchanged
- [ ] "May I write" is asked for the updated section
- [ ] Verdict is COMPLETE
---
### Case 3: Dependency Gap — Spec references a system with no design doc
**Fixture:**
- User is authoring a UX spec for the inventory screen
- `design/gdd/inventory.md` does not exist
**Input:** `/ux-design inventory-screen`
**Expected behavior:**
1. Skill begins authoring the inventory screen UX spec
2. During the User Flows section, skill attempts to reference inventory system rules
3. Skill detects: "No GDD found for inventory system — UX spec has a DEPENDENCY GAP"
4. The dependency gap is flagged in the spec (noted inline: "DEPENDENCY GAP: inventory GDD")
5. Skill continues authoring with placeholder notes for the missing rules
6. Verdict is COMPLETE with advisory note about the dependency gap
**Assertions:**
- [ ] DEPENDENCY GAP label appears in the spec for the missing system doc
- [ ] Skill does NOT block on the missing GDD — it continues with placeholders
- [ ] Dependency gap is also noted in the skill output (not just in the file)
- [ ] Handoff suggests both `/ux-review` and writing the missing GDD
---
### Case 4: No Argument Provided — Usage error
**Fixture:**
- No argument provided with the skill invocation
**Input:** `/ux-design`
**Expected behavior:**
1. Skill detects no screen name or argument provided
2. Skill outputs a usage error: "Screen name required. Usage: `/ux-design [screen-name]`"
3. Skill provides examples: `/ux-design hud`, `/ux-design main-menu`, `/ux-design inventory`
4. No file is created; no "May I write" is asked
**Assertions:**
- [ ] Usage error is clearly stated
- [ ] Example invocations are provided
- [ ] No file is created
- [ ] Skill does not attempt to proceed without an argument
---
### Case 5: Director Gate Check — No gate; ux-review is the separate review skill
**Fixture:**
- New screen spec with argument provided
**Input:** `/ux-design settings-menu`
**Expected behavior:**
1. Skill authors all sections of the settings menu UX spec
2. No director agents are spawned
3. No gate IDs appear in output during authoring
**Assertions:**
- [ ] No director gate is invoked during ux-design
- [ ] No gate skip messages appear
- [ ] Verdict is COMPLETE without any gate check
---
## Protocol Compliance
- [ ] Creates skeleton file with all section headers before discussing content
- [ ] Discusses and drafts one section at a time
- [ ] Asks "May I write section [N]" after each section is approved
- [ ] Detects existing spec and offers retrofit path
- [ ] Ends with handoff to `/ux-review`
- [ ] Verdict is COMPLETE when all sections are written
---
## Coverage Notes
- Interaction state enumeration (normal/hover/focus/disabled/error) is a core
requirement of each spec; the `/ux-review` skill checks for completeness.
- Wireframe descriptions are text-only (no images); image references may be
added manually by a designer after the fact.
- Responsive layout concerns (different screen sizes) are noted as optional
content and not assertion-tested here.

176
CCGS Skill Testing Framework/skills/authoring/ux-review.md Normal file
View File

@@ -0,0 +1,176 @@
# Skill Test Spec: /ux-review
## Skill Summary
`/ux-review` validates an existing UX spec or HUD design document against
accessibility and interaction standards. It checks for required sections
(User Flows, Interaction States, Wireframe Description, Accessibility Notes),
completeness of interaction state definitions (hover, focus, disabled, error),
accessibility compliance (keyboard navigation, color contrast notes, screen
reader considerations), and consistency with the art bible or design system
if those documents exist.
The skill is read-only — it produces no file writes. Verdicts: APPROVED
(all checks pass), NEEDS REVISION (fixable issues found), or MAJOR REVISION
NEEDED (structural or accessibility failures). No director gates apply —
`/ux-review` IS the review gate for UX specs.
---
## 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
- [ ] Contains verdict keywords: APPROVED, NEEDS REVISION, MAJOR REVISION NEEDED
- [ ] Does NOT contain "May I write" language (skill is read-only)
- [ ] Has a next-step handoff (e.g., back to `/ux-design` for revision, or proceed to implementation)
---
## Director Gate Checks
None. `/ux-review` is itself the review gate for UX specs. No additional director
gates are invoked within this skill.
---
## Test Cases
### Case 1: Happy Path — Complete UX spec with all required sections, APPROVED
**Fixture:**
- `design/ux/hud.md` exists with all required sections populated:
- User Flows: complete player flow diagrams
- Interaction States: normal, hover, focus, disabled, error all defined
- Wireframe Description: layout described
- Accessibility Notes: keyboard nav, contrast ratios, screen reader notes
**Input:** `/ux-review hud`
**Expected behavior:**
1. Skill reads `design/ux/hud.md`
2. Skill checks all 4 required sections — all present and non-empty
3. Skill checks interaction states — all 5 states defined
4. Skill checks accessibility notes — keyboard, contrast, and screen reader covered
5. Skill outputs: checklist of all passed checks
6. Verdict is APPROVED
**Assertions:**
- [ ] All 4 required sections are checked
- [ ] All 5 interaction states are verified present
- [ ] Verdict is APPROVED
- [ ] No files are written
---
### Case 2: Missing Accessibility Section — NEEDS REVISION
**Fixture:**
- `design/ux/hud.md` exists but the Accessibility Notes section is empty
- All other sections are fully populated
**Input:** `/ux-review hud`
**Expected behavior:**
1. Skill reads the file and checks all sections
2. Accessibility Notes section is empty — check fails
3. Skill outputs: "NEEDS REVISION — Accessibility Notes section is empty"
4. Skill lists specific items to add: keyboard navigation, color contrast ratios,
screen reader labels
5. Verdict is NEEDS REVISION
6. Handoff suggests returning to `/ux-design hud` to fill in the section
**Assertions:**
- [ ] NEEDS REVISION verdict is returned (not APPROVED or MAJOR REVISION NEEDED)
- [ ] Specific missing content items are listed
- [ ] Handoff points back to `/ux-design hud` for revision
- [ ] No files are written
---
### Case 3: Interaction States Incomplete — NEEDS REVISION
**Fixture:**
- `design/ux/settings-menu.md` exists
- Interaction States section only defines: normal and hover
- Missing: focus, disabled, error states
**Input:** `/ux-review settings-menu`
**Expected behavior:**
1. Skill reads the file and checks interaction states
2. Only 2 of 5 required states are defined
3. Skill reports: "NEEDS REVISION — Interaction states incomplete: missing focus, disabled, error"
4. Verdict is NEEDS REVISION with specific missing states named
**Assertions:**
- [ ] NEEDS REVISION verdict returned
- [ ] All 3 missing states are named explicitly in the output
- [ ] Skill does not return MAJOR REVISION NEEDED for a fixable gap
- [ ] Handoff suggests returning to `/ux-design settings-menu`
---
### Case 4: File Not Found — Error with remediation
**Fixture:**
- `design/ux/inventory-screen.md` does not exist
**Input:** `/ux-review inventory-screen`
**Expected behavior:**
1. Skill attempts to read `design/ux/inventory-screen.md` — file not found
2. Skill outputs: "UX spec not found: design/ux/inventory-screen.md"
3. Skill suggests running `/ux-design inventory-screen` to create the spec first
4. No review is performed; no verdict is issued
**Assertions:**
- [ ] Error message names the missing file with full path
- [ ] `/ux-design inventory-screen` is suggested as the remediation
- [ ] No review checklist is produced
- [ ] No verdict is issued (error state, not APPROVED/NEEDS REVISION)
---
### Case 5: Director Gate Check — No gate; ux-review is itself the review
**Fixture:**
- Valid UX spec file
**Input:** `/ux-review hud`
**Expected behavior:**
1. Skill performs the review and issues a verdict
2. No additional director agents are spawned
3. No gate IDs appear in output
**Assertions:**
- [ ] No director gate is invoked
- [ ] No gate skip messages appear
- [ ] Verdict is APPROVED, NEEDS REVISION, or MAJOR REVISION NEEDED — no gate verdict
---
## Protocol Compliance
- [ ] Checks all 4 required sections (User Flows, Interaction States, Wireframe,
Accessibility Notes)
- [ ] Checks all 5 interaction states (normal, hover, focus, disabled, error)
- [ ] Checks accessibility coverage (keyboard nav, contrast, screen reader)
- [ ] Does not write any files
- [ ] Issues specific, actionable feedback when verdict is not APPROVED
- [ ] Ends with next-step handoff to `/ux-design` for revision or implementation
---
## Coverage Notes
- MAJOR REVISION NEEDED is triggered when structural sections are entirely
absent (not just empty) or when fundamental interaction flows are missing
entirely; not tested with a separate fixture here.
- Art bible / design system consistency check (color palette alignment) is
mentioned as a capability but not separately fixture-tested.
- The case where an existing spec was written for a now-renamed screen is
not tested; the skill would review the file by path regardless of the name.