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

192
CCGS Skill Testing Framework/skills/review/architecture-review.md Normal file
View File

@@ -0,0 +1,192 @@
# Skill Test Spec: /architecture-review
## Skill Summary
`/architecture-review` is an Opus-tier skill that validates a technical architecture
document against the project's 8 required architecture sections and checks that it
is internally consistent, non-contradictory with existing ADRs, and correctly
targeting the pinned engine version. It produces a verdict of APPROVED /
NEEDS REVISION / MAJOR REVISION NEEDED.
In `full` review mode, the skill spawns two director gate agents in parallel:
TD-ARCHITECTURE (technical-director) and LP-FEASIBILITY (lead-programmer). In
`lean` or `solo` mode, both gates are skipped and noted. The skill is read-only —
no files 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 keywords: APPROVED, NEEDS REVISION, MAJOR REVISION NEEDED
- [ ] Does NOT require "May I write" language (read-only skill)
- [ ] Has a next-step handoff at the end
- [ ] Documents gate behavior: TD-ARCHITECTURE + LP-FEASIBILITY in full mode; skipped in lean/solo
---
## Director Gate Checks
In `full` mode: TD-ARCHITECTURE (technical-director) and LP-FEASIBILITY
(lead-programmer) are spawned in parallel after the skill reads the architecture doc.
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 — Complete architecture doc in full mode
**Fixture:**
- `docs/architecture/architecture.md` exists with all 8 required sections populated
- All sections reference the correct engine version from `docs/engine-reference/`
- No contradictions with existing Accepted ADRs in `docs/architecture/`
- `production/session-state/review-mode.txt` contains `full`
**Input:** `/architecture-review docs/architecture/architecture.md`
**Expected behavior:**
1. Skill reads the architecture document
2. Skill reads existing ADRs for cross-reference
3. Skill reads engine version reference
4. TD-ARCHITECTURE and LP-FEASIBILITY gate agents spawn in parallel
5. Both gates return APPROVED
6. Skill outputs section-by-section completeness check (8/8 sections present)
7. Verdict: APPROVED
**Assertions:**
- [ ] All 8 required sections are checked and reported
- [ ] TD-ARCHITECTURE and LP-FEASIBILITY spawn in parallel (not sequentially)
- [ ] Verdict is APPROVED when all sections are present and no conflicts exist
- [ ] Skill does NOT write any files
- [ ] Next-step handoff to `/create-control-manifest` or `/create-epics` is present
---
### Case 2: Failure Path — Missing required sections
**Fixture:**
- `docs/architecture/architecture.md` exists but is missing at least 2 required sections
(e.g., no data model section, no error handling section)
- `production/session-state/review-mode.txt` contains `full`
**Input:** `/architecture-review docs/architecture/architecture.md`
**Expected behavior:**
1. Skill reads the document and identifies missing sections
2. Section completeness shows fewer than 8/8 sections present
3. Missing sections are listed by name with specific remediation guidance
4. Verdict: MAJOR REVISION NEEDED (≥2 missing sections)
**Assertions:**
- [ ] Verdict is MAJOR REVISION NEEDED (not APPROVED or NEEDS REVISION) for ≥2 missing sections
- [ ] Each missing section is named explicitly in the output
- [ ] Remediation guidance is specific (what to add, not just "add missing sections")
- [ ] Skill does NOT pass a document missing required sections
---
### Case 3: Partial Path — Architecture contradicts an existing ADR
**Fixture:**
- `docs/architecture/architecture.md` exists with all 8 sections present
- One Accepted ADR in `docs/architecture/` establishes a constraint that the architecture doc contradicts
(e.g., ADR-001 mandates ECS pattern; architecture.md describes a different pattern for the same system)
**Input:** `/architecture-review docs/architecture/architecture.md`
**Expected behavior:**
1. Skill reads the architecture doc and all existing ADRs
2. Conflict is detected between the architecture doc and the named ADR
3. Conflict entry names: the ADR number/title, the contradicting sections, and impact
4. Verdict: NEEDS REVISION (conflict exists but structure is otherwise sound)
**Assertions:**
- [ ] Verdict is NEEDS REVISION (not MAJOR REVISION NEEDED for a single contradiction)
- [ ] The specific ADR number and title are named in the conflict entry
- [ ] The contradicting sections in both documents are identified
- [ ] Skill does NOT auto-resolve the contradiction
---
### Case 4: Edge Case — File not found
**Fixture:**
- The path provided does not exist in the project
**Input:** `/architecture-review docs/architecture/nonexistent.md`
**Expected behavior:**
1. Skill attempts to read the file
2. File not found
3. Skill outputs a clear error naming the missing file
4. Skill suggests checking `docs/architecture/` or running `/create-architecture`
5. Skill does NOT produce a verdict
**Assertions:**
- [ ] Skill outputs a clear error when the file is not found
- [ ] No verdict is produced (APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED)
- [ ] Skill suggests a corrective action
- [ ] Skill does NOT crash or produce a partial report
---
### Case 5: Director Gate — Full mode spawns both gates; solo mode skips both
**Fixture (full mode):**
- `docs/architecture/architecture.md` exists with all 8 sections
- `production/session-state/review-mode.txt` contains `full`
**Full mode expected behavior:**
1. TD-ARCHITECTURE gate spawns
2. LP-FEASIBILITY gate spawns in parallel with TD-ARCHITECTURE
3. Both gates complete before verdict is issued
**Assertions (full mode):**
- [ ] TD-ARCHITECTURE and LP-FEASIBILITY both appear in the output as completed gates
- [ ] Both gates spawn in parallel (not one after the other)
- [ ] Verdict reflects gate feedback
**Fixture (solo mode):**
- Same architecture doc
- `production/session-state/review-mode.txt` contains `solo`
**Solo mode expected behavior:**
1. Skill reads the architecture doc
2. Gates are NOT spawned
3. Output notes: "TD-ARCHITECTURE skipped — solo mode" and "LP-FEASIBILITY skipped — solo mode"
4. Verdict is based on structural checks only
**Assertions (solo mode):**
- [ ] Neither TD-ARCHITECTURE nor LP-FEASIBILITY appears as an active gate
- [ ] Both skipped gates are noted in the output
- [ ] Verdict is still produced based on the structural check alone
---
## Protocol Compliance
- [ ] Does NOT write any files (read-only skill)
- [ ] Presents section completeness check before issuing verdict
- [ ] TD-ARCHITECTURE and LP-FEASIBILITY spawn in parallel in full mode
- [ ] Skipped gates are noted by name and mode in lean/solo output
- [ ] Verdict is one of exactly: APPROVED, NEEDS REVISION, MAJOR REVISION NEEDED
- [ ] Ends with next-step handoff appropriate to verdict
---
## Coverage Notes
- The 8 required architecture sections are project-specific; tests use the
section list defined in the skill body — not re-enumerated here.
- Engine version compatibility checking (cross-referencing `docs/engine-reference/`)
is part of Case 1's happy path but not independently fixture-tested.
- RTM (requirement traceability matrix) mode is a separate concern covered by
the `/architecture-review` skill's own `rtm` argument mode, not tested here.

170
CCGS Skill Testing Framework/skills/review/design-review.md Normal file
View File

@@ -0,0 +1,170 @@
# Skill Test Spec: /design-review
## Skill Summary
`/design-review` reads a game design document (GDD) and evaluates it against
the project's 8-section design standard (Overview, Player Fantasy, Detailed
Rules, Formulas, Edge Cases, Dependencies, Tuning Knobs, Acceptance Criteria).
It checks for internal consistency, implementability, and cross-system
conflicts. It produces a verdict of APPROVED, NEEDS REVISION, or MAJOR
REVISION NEEDED. It is a read-only skill (no file writes) and runs as a
`context: fork` subagent.
---
## 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 or numbered steps
- [ ] Contains verdict keywords: APPROVED, NEEDS REVISION, MAJOR REVISION NEEDED
- [ ] Does NOT require "May I write" language (read-only skill — `allowed-tools` excludes Write/Edit)
- [ ] Output format is documented (review template shown in skill body)
---
## Test Cases
### Case 1: Happy Path — Complete GDD, all 8 sections present
**Fixture:**
- `design/gdd/light-manipulation.md` exists (use `_fixtures/minimal-game-concept.md`
as a stand-in — represents a complete document with all required content)
- All 8 required sections are populated with substantive content
- Formulas section contains at least one formula with defined variables
- Acceptance Criteria section contains at least 3 testable criteria
**Input:** `/design-review design/gdd/light-manipulation.md`
**Expected behavior:**
1. Skill reads the target document in full
2. Skill reads CLAUDE.md for project context and standards
3. Skill evaluates all 8 required sections (present/absent check)
4. Skill checks internal consistency (formulas match described behavior)
5. Skill checks implementability (rules are precise enough to code)
6. Skill outputs structured review with section-by-section status
7. Skill outputs APPROVED verdict
**Assertions:**
- [ ] Skill reads the target file before producing any output
- [ ] Output includes a "Completeness" section showing X/8 sections present
- [ ] Output includes an "Internal Consistency" section
- [ ] Output includes an "Implementability" section
- [ ] Output ends with a verdict line: APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED
- [ ] APPROVED verdict is given when all 8 sections are present and consistent
---
### Case 2: Failure Path — Incomplete GDD (4/8 sections)
**Fixture:**
- `design/gdd/light-manipulation.md` exists using content from
`tests/skills/_fixtures/incomplete-gdd.md` (4 of 8 sections populated;
Formulas, Edge Cases, Tuning Knobs, Acceptance Criteria are missing)
**Input:** `/design-review design/gdd/light-manipulation.md`
**Expected behavior:**
1. Skill reads the document
2. Skill identifies 4 missing sections
3. Skill outputs "Completeness: 4/8 sections present"
4. Skill lists specifically which 4 sections are missing
5. Skill outputs MAJOR REVISION NEEDED verdict (not APPROVED or NEEDS REVISION)
**Assertions:**
- [ ] Output shows "4/8" in the completeness section (not a higher number)
- [ ] Output explicitly names each missing section (Formulas, Edge Cases, Tuning Knobs, Acceptance Criteria)
- [ ] Verdict is MAJOR REVISION NEEDED (not APPROVED or NEEDS REVISION) when ≥3 sections are missing
- [ ] Output does not suggest the document is implementation-ready
- [ ] Skill does not write any files (read-only enforcement)
---
### Case 3: Partial Path — 7/8 sections, minor inconsistency
**Fixture:**
- GDD has all sections except Formulas
- The described behavior mentions numeric values but no formulas are defined
- Acceptance Criteria exist but are vague ("feels good" rather than measurable)
**Input:** `/design-review design/gdd/[document].md`
**Expected behavior:**
1. Skill identifies missing Formulas section
2. Skill flags vague acceptance criteria as an implementability issue
3. Skill outputs NEEDS REVISION verdict (not APPROVED, not MAJOR REVISION NEEDED)
4. Skill provides specific remediation notes for each issue
**Assertions:**
- [ ] Verdict is NEEDS REVISION (not APPROVED, not MAJOR REVISION NEEDED) for 7/8 with issues
- [ ] Output identifies the missing Formulas section specifically
- [ ] Output flags the vague acceptance criteria as an implementability gap
- [ ] Each flagged issue has a specific, actionable remediation note
---
### Case 4: Edge Case — File not found
**Fixture:**
- The path provided does not exist in the project
**Input:** `/design-review design/gdd/nonexistent.md`
**Expected behavior:**
1. Skill attempts to read the file
2. File not found
3. Skill outputs an error message naming the missing file
4. Skill suggests checking the path or listing files in `design/gdd/`
5. Skill does NOT produce a verdict
**Assertions:**
- [ ] Skill outputs a clear error when the file is not found
- [ ] Skill does NOT output APPROVED, NEEDS REVISION, or MAJOR REVISION NEEDED when file is missing
- [ ] Skill suggests a corrective action (check path, list available GDDs)
---
---
### Case 5: Director Gate — no gate spawned regardless of review mode
**Fixture:**
- `design/gdd/light-manipulation.md` exists with all 8 sections
- `production/session-state/review-mode.txt` exists with `full` (most permissive mode)
**Input:** `/design-review design/gdd/light-manipulation.md` (with full review mode active)
**Expected behavior:**
1. Skill reads the GDD document
2. Skill does NOT read `review-mode.txt` — this skill has no director gates
3. Skill produces the review output normally
4. No director gate agents are spawned at any point
5. Verdict is APPROVED (all 8 sections present in fixture)
**Assertions:**
- [ ] Skill does NOT spawn any director gate agent (CD-, TD-, PR-, AD- prefixed agents)
- [ ] Skill does NOT read `review-mode.txt` or equivalent mode file
- [ ] The `--review` flag or `full` mode state has NO effect on whether directors spawn
- [ ] Output does not contain any "Gate: [GATE-ID]" entries
- [ ] Skill IS the review — it does not delegate the review to a director
---
## Protocol Compliance
- [ ] Does NOT use Write or Edit tools (read-only skill)
- [ ] Presents complete findings before any verdict
- [ ] Does not ask for approval before producing output (no writes to approve)
- [ ] Ends with recommended next step (e.g., fix issues and re-run, or proceed to `/map-systems`)
---
## Coverage Notes
- Cross-system consistency checking (Case 3 in the skill's own phase list) is
not directly tested here because it requires multiple GDD files to compare;
this is covered by the `/review-all-gdds` spec instead.
- The skill's `context: fork` behavior (running as a subagent) is not tested
at the spec level — this is a runtime behavior verified manually.
- Performance and edge cases involving very large GDD files are not in scope.

178
CCGS Skill Testing Framework/skills/review/review-all-gdds.md Normal file
View File

@@ -0,0 +1,178 @@
# Skill Test Spec: /review-all-gdds
## Skill Summary
`/review-all-gdds` is an Opus-tier skill that performs a holistic cross-GDD review
across all files in `design/gdd/`. It runs two complementary review phases in
parallel: Phase 1 checks for consistency (contradictions, formula mismatches,
stale references, competing ownership), and Phase 2 checks design theory (dominant
strategies, pillar drift, cognitive overload, economic imbalance). Because the two
phases are independent, they are spawned simultaneously to save time. The skill
produces a CONSISTENT / MINOR ISSUES / MAJOR ISSUES verdict and is read-only — no
files are written without explicit user approval.
The skill is itself the holistic review gate in the pipeline. It is invoked after
individual GDDs are complete and before architecture work begins. It does NOT spawn
any director gate agents (it IS the director-level review).
---
## 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 ≥5 phase headings (complex multi-phase skill)
- [ ] Contains verdict keywords: CONSISTENT, MINOR ISSUES, MAJOR ISSUES
- [ ] Does NOT require "May I write" language (read-only skill)
- [ ] Has a next-step handoff at the end
- [ ] Documents parallel phase spawning (Phase 1 and Phase 2 are independent)
---
## Director Gate Checks
No director gates — this skill spawns no director gate agents. It IS the holistic
review; delegating to a director gate would create a circular dependency.
---
## Test Cases
### Case 1: Happy Path — Clean GDD set with no conflicts
**Fixture:**
- `design/gdd/` contains ≥3 system GDDs
- All GDDs are internally consistent: no formula contradictions, no competing ownership, no stale references
- All GDDs align with the pillars defined in `design/gdd/game-pillars.md`
**Input:** `/review-all-gdds`
**Expected behavior:**
1. Skill reads all GDD files in `design/gdd/`
2. Phase 1 (consistency scan) and Phase 2 (design theory check) spawn in parallel
3. Phase 1 finds no contradictions, no formula mismatches, no ownership conflicts
4. Phase 2 finds no pillar drift, no dominant strategies, no cognitive overload
5. Skill outputs a structured findings table with 0 blocking issues
6. Verdict: CONSISTENT
**Assertions:**
- [ ] Both review phases are spawned in parallel (not sequentially)
- [ ] Output includes a findings table (even if empty — shows "No issues found")
- [ ] Verdict is CONSISTENT when no conflicts are found
- [ ] Skill does NOT write any files without user approval
- [ ] Next-step handoff to `/architecture-review` or `/create-architecture` is present
---
### Case 2: Failure Path — Conflicting rules between two GDDs
**Fixture:**
- GDD-A defines a floor value (e.g. "minimum [output] is [N]")
- GDD-B states a mechanic that bypasses that floor (e.g. "[mechanic] can reduce [output] to 0")
- The two GDDs are otherwise complete and valid
**Input:** `/review-all-gdds`
**Expected behavior:**
1. Phase 1 (consistency scan) detects the contradiction between GDD-A and GDD-B
2. Conflict is reported with: both filenames, the specific conflicting rules, and severity HIGH
3. Verdict: MAJOR ISSUES
4. Handoff instructs user to resolve the conflict and re-run before proceeding
**Assertions:**
- [ ] Verdict is MAJOR ISSUES (not CONSISTENT or MINOR ISSUES)
- [ ] Both GDD filenames are named in the conflict entry
- [ ] The specific contradicting rules are quoted or described (not vague "conflict found")
- [ ] Issue is classified as severity HIGH (blocking)
- [ ] Skill does NOT auto-resolve the conflict
---
### Case 3: Partial Path — Single GDD with orphaned dependency reference
**Fixture:**
- GDD-A lists a dependency in its Dependencies section pointing to "system-B"
- No GDD for system-B exists in `design/gdd/`
- All other GDDs are consistent
**Input:** `/review-all-gdds`
**Expected behavior:**
1. Phase 1 detects the orphaned dependency reference in GDD-A
2. Issue is reported as: DEPENDENCY GAP — GDD-A references system-B which has no GDD
3. No other conflicts found
4. Verdict: MINOR ISSUES (dependency gap is advisory, not blocking by itself)
**Assertions:**
- [ ] Verdict is MINOR ISSUES (not MAJOR ISSUES for a single orphaned reference)
- [ ] The specific GDD filename and the missing dependency name are reported
- [ ] Skill suggests running `/design-system system-B` to resolve the gap
- [ ] Skill does NOT skip or silently ignore the missing dependency
---
### Case 4: Edge Case — No GDD files found
**Fixture:**
- `design/gdd/` directory is empty or does not exist
- No GDD files are present
**Input:** `/review-all-gdds`
**Expected behavior:**
1. Skill attempts to read files in `design/gdd/`
2. No files found — skill outputs an error with guidance
3. Skill recommends running `/brainstorm` and `/design-system` before re-running
4. Skill does NOT produce a verdict (CONSISTENT / MINOR ISSUES / MAJOR ISSUES)
**Assertions:**
- [ ] Skill outputs a clear error message when no GDDs are found
- [ ] No verdict is produced when the directory is empty
- [ ] Skill recommends the correct next action (`/brainstorm` or `/design-system`)
- [ ] Skill does NOT crash or produce a partial report
---
### Case 5: Director Gate — No gate spawned regardless of review mode
**Fixture:**
- `design/gdd/` contains ≥2 consistent system GDDs
- `production/session-state/review-mode.txt` exists with content `full`
**Input:** `/review-all-gdds`
**Expected behavior:**
1. Skill reads all GDDs and runs the two review phases
2. Skill does NOT read `review-mode.txt`
3. Skill does NOT spawn any director gate agent (CD-, TD-, PR-, AD- prefixed)
4. Skill completes and outputs its verdict normally
5. Review mode setting has no effect on this skill's behavior
**Assertions:**
- [ ] No director gate agents are spawned at any point
- [ ] Skill does NOT read `production/session-state/review-mode.txt`
- [ ] Output does not contain any "Gate: [GATE-ID]" or "skipped" gate entries
- [ ] The skill produces a verdict regardless of review mode
- [ ] R4 metric: gate count for this skill = 0 in all modes
---
## Protocol Compliance
- [ ] Phase 1 (consistency) and Phase 2 (design theory) spawned in parallel — not sequentially
- [ ] Does NOT write any files without "May I write" approval
- [ ] Findings table shown before any write ask
- [ ] Verdict is one of exactly: CONSISTENT, MINOR ISSUES, MAJOR ISSUES
- [ ] Ends with appropriate handoff: MAJOR ISSUES → fix and re-run; MINOR ISSUES → may proceed with awareness; CONSISTENT → `/create-architecture`
---
## Coverage Notes
- Economic balance analysis (source/sink loops) requires cross-GDD resource data — covered
structurally by Case 2 (the conflict detection pattern is the same).
- The design theory phase (Phase 2) checks including dominant strategy detection and
cognitive overload are not individually fixture-tested — they follow the same
pattern as consistency checks and are validated via the pillar drift case structure.
- The `since-last-review` scoping mode is not tested here — it is a runtime concern.