ksh999000/Claude-Code-Game-Studios
1
0
Fork 0
mirror of https://github.com/Donchitos/Claude-Code-Game-Studios.git synced 2026-06-27 04:51:46 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add v0.5.0: CCGS Skill Testing Framework, skill-improve, 4 new skills, director gate path fixes

Browse Source 
- Add CCGS Skill Testing Framework: self-contained QA layer with 72 skill specs,
  49 agent specs, catalog.yaml, quality-rubric.md, templates, README, CLAUDE.md
- Add /skill-improve: test-fix-retest loop covering static + category checks
- Add 4 missing skills: /art-bible, /asset-spec, /day-one-patch, /security-audit
- Add /skill-test category mode (Phase 2D) with quality rubric evaluation
- Extend /skill-test audit to cover agent specs alongside skill specs
- Update all skill-test and skill-improve path refs to CCGS Skill Testing Framework/
- Remove stale tests/skills/ directory (superseded by CCGS Skill Testing Framework)
- Add director gate intensity modes (full/lean/solo) to gate-check and related skills

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Donchitos
2026-04-06 17:42:32 +10:00
parent 8ba9e736a5
commit a73ff759c9
192 changed files with 21953 additions and 1158 deletions
Download Patch File Download Diff File Expand all files Collapse all files

74
.claude/skills/map-systems/SKILL.md
View File

@@ -3,12 +3,12 @@ name: map-systems
description: "Decompose a game concept into individual systems, map dependencies, prioritize design order, and create the systems index."
argument-hint: "[next | system-name] [--review full|lean|solo]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Edit, AskUserQuestion, TodoWrite
allowed-tools: Read, Glob, Grep, Write, Edit, AskUserQuestion, TodoWrite, Task
---
When this skill is invoked:
## 1. Parse Arguments
## Parse Arguments
Two modes:
@@ -17,12 +17,16 @@ Two modes:
- **`next`**: `/map-systems next` — Pick the highest-priority undesigned system
from the index and hand off to `/design-system` (Phase 6).
Also extract `--review [full|lean|solo]` if present and store as the review mode
override for this run (see `.claude/docs/director-gates.md`).
Also resolve the review mode (once, store for all gate spawns this run):
1. If `--review [full|lean|solo]` was passed → use that
2. Else read `production/review-mode.txt` → use that value
3. Else → default to `lean`
See `.claude/docs/director-gates.md` for the full check pattern.
---
## 2. Phase 1: Read Concept (Required Context)
## Phase 1: Read Concept (Required Context)
Read the game concept and any existing design work. This provides the raw material
for systems decomposition.
@@ -48,7 +52,7 @@ for systems decomposition.
---
## 3. Phase 2: Systems Enumeration (Collaborative)
## Phase 2: Systems Enumeration (Collaborative)
Extract and identify all systems the game needs. This is the creative core of the
skill — it requires human judgment because concept docs rarely enumerate every
@@ -101,7 +105,7 @@ Iterate until the user approves the enumeration.
---
## 4. Phase 3: Dependency Mapping (Collaborative)
## Phase 3: Dependency Mapping (Collaborative)
For each system, determine what it depends on. A system "depends on" another if
it cannot function without that other system existing first.
@@ -140,6 +144,11 @@ Show the dependency map as a layered list. Highlight:
Use `AskUserQuestion` to ask: "Does this dependency ordering look right? Any
dependencies I'm missing or that should be removed?"
**Review mode check** — apply before spawning TD-SYSTEM-BOUNDARY:
- `solo` → skip. Note: "TD-SYSTEM-BOUNDARY skipped — Solo mode." Proceed to priority assignment.
- `lean` → skip (not a PHASE-GATE). Note: "TD-SYSTEM-BOUNDARY skipped — Lean mode." Proceed to priority assignment.
- `full` → spawn as normal.
**After dependency mapping is approved, spawn `technical-director` via Task using gate TD-SYSTEM-BOUNDARY (`.claude/docs/director-gates.md`) before proceeding to priority assignment.**
Pass: the dependency map summary, layer assignments, bottleneck systems list, any circular dependency resolutions.
@@ -148,7 +157,7 @@ Present the assessment. If REJECT, revise the system boundaries with the user be
---
## 5. Phase 4: Priority Assignment (Collaborative)
## Phase 4: Priority Assignment (Collaborative)
Assign each system to a priority tier based on what milestone it's needed for.
@@ -172,6 +181,18 @@ Which systems should be higher or lower priority?"
Explain reasoning in conversation: "I placed [system] in MVP because the core loop
requires it — without [system], the 30-second loop can't function."
**"Why" column guidance**: When explaining why each system was placed in a priority tier, mix technical necessity with player-experience reasoning. Do not use purely technical justifications like "Combat needs damage math" — connect to player experience where relevant. Examples of good "Why" entries:
- "Required for the core loop — without it, placement decisions have no consequence (Pillar 2: Placement is the Puzzle)"
- "Ballista's punch-through identity is established here — this stat definition is what makes it feel different from Archer"
- "Foundation for all economy decisions — players must understand upgrade costs to make meaningful placement choices"
Pure technical necessity ("X depends on Y") is insufficient alone when the system directly shapes player experience.
**Review mode check** — apply before spawning PR-SCOPE:
- `solo` → skip. Note: "PR-SCOPE skipped — Solo mode." Proceed to writing the systems index.
- `lean` → skip (not a PHASE-GATE). Note: "PR-SCOPE skipped — Lean mode." Proceed to writing the systems index.
- `full` → spawn as normal.
**After priorities are approved, spawn `producer` via Task using gate PR-SCOPE (`.claude/docs/director-gates.md`) before writing the index.**
Pass: total system count per milestone tier, estimated implementation volume per tier (system count × average complexity), team size, stated project timeline.
@@ -191,7 +212,7 @@ This is the order the team should write GDDs in.
---
## 6. Phase 5: Create Systems Index (Write)
## Phase 5: Create Systems Index (Write)
### Step 5a: Draft the Document
@@ -215,6 +236,11 @@ Ask: "May I write the systems index to `design/gdd/systems-index.md`?"
Wait for approval. Write the file only after "yes."
**Review mode check** — apply before spawning CD-SYSTEMS:
- `solo` → skip. Note: "CD-SYSTEMS skipped — Solo mode." Proceed to Phase 7 next steps.
- `lean` → skip (not a PHASE-GATE). Note: "CD-SYSTEMS skipped — Lean mode." Proceed to Phase 7 next steps.
- `full` → spawn as normal.
**After the systems index is written, spawn `creative-director` via Task using gate CD-SYSTEMS (`.claude/docs/director-gates.md`).**
Pass: systems index path, game pillars and core fantasy (from `design/gdd/game-concept.md`), MVP priority tier system list.
@@ -234,7 +260,7 @@ If the user declined: **Verdict: BLOCKED** — user did not approve the write.
---
## 7. Phase 6: Design Individual Systems (Handoff to /design-system)
## Phase 6: Design Individual Systems (Handoff to /design-system)
This phase is entered when:
- The user says "yes" to designing systems after creating the index
@@ -280,16 +306,20 @@ If continuing, return to Step 6a.
---
## 8. Phase 7: Suggest Next Steps
## Phase 7: Suggest Next Steps
After the systems index is created (or after designing some systems), suggest
the appropriate next actions:
After the systems index is created (or after designing some systems), present next actions using `AskUserQuestion`:
- "Run `/design-system [system-name]` to write the next system's GDD"
- "Run `/design-review [path]` on each completed GDD to validate quality"
- "Run `/gate-check pre-production` to check if you're ready to start building"
- "Prototype the highest-risk system with `/prototype [system]`"
- "Plan the first implementation sprint with `/sprint-plan new`"
- "Systems index is written. What would you like to do next?"
- [A] Start designing GDDs — run `/design-system [first-system-in-order]`
- [B] Ask a director to review the index first — ask `creative-director` or `technical-director` to validate the system set before committing to 10+ GDD sessions
- [C] Stop here for this session
**The director review option ([B]) is worth highlighting**: having a Creative Director or Technical Director review the completed systems index before starting GDD authoring catches scope issues, missing systems, and boundary problems before they're locked in across many documents. It is optional but recommended for new projects.
After any individual GDD is completed:
- "Run `/design-review design/gdd/[system].md` in a fresh session to validate quality"
- "Run `/gate-check systems-design` when all MVP GDDs are complete"
---
@@ -314,3 +344,11 @@ This skill follows the collaborative design principle at every phase:
**Never** auto-generate the full systems list and write it without review.
**Never** start designing a system without user confirmation.
**Always** show the enumeration, dependencies, and priorities for user validation.
## Context Window Awareness
If context reaches or exceeds 70% at any point, append this notice:
> **Context is approaching the limit (≥70%).** The systems index is saved to
> `design/gdd/systems-index.md`. Open a fresh Claude Code session to continue
> designing individual GDDs — run `/map-systems next` to pick up where you left off.