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

- 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>

.claude/skills/design-system/SKILL.md

@@ -10,14 +10,24 @@ When this skill is invoked:
 
 ## 1. Parse Arguments & Validate
 
-Extract `--review [full|lean|solo]` if present and store as the review mode
-override for this run (see `.claude/docs/director-gates.md`).
+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`
 
-A system name or retrofit path is **required**. If missing, fail with:
-> "Usage: `/design-system <system-name>` — e.g., `/design-system movement`
-> Or to fill gaps in an existing GDD: `/design-system retrofit design/gdd/[system-name].md`
-> Run `/map-systems` first to create the systems index, then use this skill
-> to write individual system GDDs."
+See `.claude/docs/director-gates.md` for the full check pattern.
+
+A system name or retrofit path is **required**. If missing:
+
+1. Check if `design/gdd/systems-index.md` exists.
+2. If it exists: read it, find the highest-priority system with status "Not Started" or equivalent, and use `AskUserQuestion`:
+   - Prompt: "The next system in your design order is **[system-name]** ([priority] | [layer]). Start designing it?"
+   - Options: `[A] Yes — design [system-name]` / `[B] Pick a different system` / `[C] Stop here`
+   - If [A]: proceed with that system name. If [B]: ask which system to design (plain text). If [C]: exit.
+3. If no systems index exists, fail with:
+   > "Usage: `/design-system <system-name>` — e.g., `/design-system movement`
+   > Or to fill gaps in an existing GDD: `/design-system retrofit design/gdd/[system-name].md`
+   > No systems index found. Run `/map-systems` first to map your systems and get the design order."
 
 **Detect retrofit mode:**
 If the argument starts with `retrofit` or the argument is a file path to an
@@ -271,7 +281,12 @@ Use the template structure from `.claude/docs/templates/game-design-document.md`
 
 Ask: "May I create the skeleton file at `design/gdd/[system-name].md`?"
 
-After writing, create `production/session-state/active.md` if it does not exist, then update it with:
+After writing, update `production/session-state/active.md`:
+- Use Glob to check if the file exists.
+- If it **does not exist**: use the **Write** tool to create it. Never attempt Edit on a file that may not exist.
+- If it **already exists**: use the **Edit** tool to update the relevant fields.
+
+File content:
 - Task: Designing [system-name] GDD
 - Current section: Starting (skeleton created)
 - File: design/gdd/[system-name].md
@@ -304,10 +319,24 @@ Context  ->  Questions  ->  Options  ->  Decision  ->  Draft  ->  Approval  ->
 5. **Draft**: Write the section content in conversation text for review. Flag any
    provisional assumptions about undesigned dependencies.
 
-6. **Approval**: Ask "Approve this section, or would you like changes?"
+6. **Approval**: Immediately after the draft — in the SAME response — use
+   `AskUserQuestion`. **NEVER use plain text. NEVER skip this step.**
+   - Prompt: "Approve the [Section Name] section?"
+   - Options: `[A] Approve — write it to file` / `[B] Make changes — describe what to fix` / `[C] Start over`
 
-7. **Write**: Use the Edit tool to replace the `[To be designed]` placeholder with
-   the approved content. Confirm the write.
+   **The draft and the approval widget MUST appear together in one response.
+   If the draft appears without the widget, the user is left at a blank prompt
+   with no path forward — this is a protocol violation.**
+
+7. **Write**: Use the Edit tool to replace the placeholder with the approved content.
+   **CRITICAL**: Always include the section heading in the `old_string` to ensure
+   uniqueness — never match `[To be designed]` alone, as multiple sections use the
+   same placeholder and the Edit tool requires a unique match. Use this pattern:
+   ```
+   old_string: "## [Section Name]\n\n[To be designed]"
+   new_string: "## [Section Name]\n\n[approved content]"
+   ```
+   Confirm the write.
 
 8. **Registry conflict check** (Sections C and D only — Detailed Design and Formulas):
    After writing, scan the section content for entity names, item names, formula
@@ -321,7 +350,8 @@ Context  ->  Questions  ->  Options  ->  Decision  ->  Draft  ->  Approval  ->
      (will be handled in Phase 5).
 
 After writing each section, update `production/session-state/active.md` with the
-completed section name.
+completed section name. Use Glob to check if the file exists — use Write to create
+it if absent, Edit to update it if present.
 
 ### Section-Specific Guidance
 
@@ -333,6 +363,20 @@ Each section has unique design considerations and may benefit from specialist ag
 
 **Goal**: One paragraph a stranger could read and understand.
 
+**Derive recommended options before building the widget**: Read the system's category and layer from the systems index (already in context from Phase 2), then determine the recommended option for each tab:
+- **Framing tab**: Foundation/Infrastructure layer → `[A]` recommended. Player-facing categories (Combat, UI, Dialogue, Character, Animation, Visual Effects, Audio) → `[C] Both` recommended.
+- **ADR ref tab**: Glob `docs/architecture/adr-*.md` and grep for the system name in the GDD Requirements section of any ADR. If a matching ADR is found → `[A] Yes — cite the ADR` recommended. If none found → `[B] No` recommended.
+- **Fantasy tab**: Foundation/Infrastructure layer → `[B] No` recommended. All other categories → `[A] Yes` recommended.
+
+Append `(Recommended)` to the appropriate option text in each tab.
+
+**Framing questions (ask BEFORE drafting)**: Use `AskUserQuestion` with a multi-tab widget:
+- Tab "Framing" — "How should the overview frame this system?" Options: `[A] As a data/infrastructure layer (technical framing)` / `[B] Through its player-facing effect (design framing)` / `[C] Both — describe the data layer and its player impact`
+- Tab "ADR ref" — "Should the overview reference the existing ADR for this system?" Options: `[A] Yes — cite the ADR for implementation details` / `[B] No — keep the GDD at pure design level`
+- Tab "Fantasy" — "Does this system have a player fantasy worth stating?" Options: `[A] Yes — players feel it directly` / `[B] No — pure infrastructure, players feel what it enables`
+
+Use the user's answers to shape the draft. Do NOT answer these questions yourself and auto-draft.
+
 **Questions to ask**:
 - What is this system in one sentence?
 - How does a player interact with it? (active/passive/automatic)
@@ -341,12 +385,32 @@ Each section has unique design considerations and may benefit from specialist ag
 **Cross-reference**: Check that the description aligns with how the systems index
 describes it. Flag discrepancies.
 
+**Design vs. implementation boundary**: Overview questions must stay at the behavior
+level — what the system *does*, not *how it is built*. If implementation questions
+arise during the Overview (e.g., "Should this use an Autoload singleton or a signal
+bus?"), note them as "→ becomes an ADR" and move on. Implementation patterns belong
+in `/architecture-decision`, not the GDD. The GDD describes behavior; the ADR
+describes the technical approach used to achieve it.
+
 ---
 
 ### Section B: Player Fantasy
 
 **Goal**: The emotional target — what the player should *feel*.
 
+**Derive recommended option before building the widget**: Read the system's category and layer from Phase 2 context:
+- Player-facing categories (Combat, UI, Dialogue, Character, Animation, Audio, Level/World) → `[A] Direct` recommended
+- Foundation/Infrastructure layer → `[B] Indirect` recommended
+- Mixed categories (Camera/input, Economy, AI with visible player effects) → `[C] Both` recommended
+
+Append `(Recommended)` to the appropriate option text.
+
+**Framing question (ask BEFORE drafting)**: Use `AskUserQuestion`:
+- Prompt: "Is this system something the player engages with directly, or infrastructure they experience indirectly?"
+- Options: `[A] Direct — player actively uses or feels this system` / `[B] Indirect — player experiences the effects, not the system` / `[C] Both — has a direct interaction layer and infrastructure beneath it`
+
+Use the answer to frame the Player Fantasy section appropriately. Do NOT assume the answer.
+
 **Questions to ask**:
 - What emotion or power fantasy does this serve?
 - What reference games nail this feeling? What specifically creates it?
@@ -355,6 +419,16 @@ describes it. Flag discrepancies.
 **Cross-reference**: Must align with the game pillars. If the system serves a pillar,
 quote the relevant pillar text.
 
+**Agent delegation (MANDATORY)**: After the framing answer is given but before drafting,
+spawn `creative-director` via Task:
+- Provide: system name, framing answer (direct/indirect/both), game pillars, any reference games the user mentioned, the game concept summary
+- Ask: "Shape the Player Fantasy for this system. What emotion or power fantasy should it serve? What player moment should we anchor to? What tone and language fits the game's established feeling? Be specific — give me 2-3 candidate framings."
+- Collect the creative-director's framings and present them to the user alongside the draft.
+
+**Do NOT draft Section B without first consulting `creative-director`.** The framing
+answer tells us *what kind* of fantasy it is; the creative-director shapes *how it's
+described* — tone, language, the specific player moment to anchor to.
+
 ---
 
 ### Section C: Detailed Design (Core Rules, States, Interactions)
@@ -375,9 +449,15 @@ This is usually the largest section. Break it into sub-sections:
 - What are the decision points the player faces?
 - What can the player NOT do? (Constraints are as important as capabilities)
 
-**Agent delegation**: For complex mechanics, use the Task tool to delegate to
-`game-designer` for high-level design review, or `systems-designer` for detailed
-mechanical modeling. Provide the full context gathered in Phase 2.
+**Agent delegation (MANDATORY)**: Before drafting Section C, spawn specialist agents via Task in parallel:
+- Look up the system category in the routing table (Section 6 of this skill)
+- Spawn the Primary Agent AND Supporting Agent(s) listed for this category
+- Provide each agent: system name, game concept summary, pillar set, dependency GDD excerpts, the specific section being worked on
+- Collect their findings before drafting
+- Surface any disagreements between agents to the user via `AskUserQuestion`
+- Draft only after receiving specialist input
+
+**Do NOT draft Section C without first consulting the appropriate specialists.** A `systems-designer` reviewing rules and mechanics will catch design gaps the main session cannot.
 
 **Cross-reference**: For each interaction listed, verify it matches what the
 dependency GDD specifies. If a dependency defines a value or formula and this
@@ -414,14 +494,12 @@ table. A formula without defined variables cannot be implemented without guesswo
 - Should scaling be linear, logarithmic, or stepped?
 - What should the output ranges be at early/mid/late game?
 
-**Agent delegation**: For formula-heavy systems, delegate to `systems-designer`
-via the Task tool. Provide:
-- The Core Rules from Section C (already written to file)
-- Tuning goals from the user
-- Balance context from dependency GDDs
-
-The agent should return proposed formulas with variable tables and expected output
-ranges. Present these to the user for review before approving.
+**Agent delegation (MANDATORY)**: Before proposing any formulas or balance values, spawn specialist agents via Task in parallel:
+- **Always spawn `systems-designer`**: provide Core Rules from Section C, tuning goals from user, balance context from dependency GDDs. Ask them to propose formulas with variable tables and output ranges.
+- **For economy/cost systems, also spawn `economy-designer`**: provide placement costs, upgrade cost intent, and progression goals. Ask them to validate cost curves and ratios.
+- Present the specialists' proposals to the user for review via `AskUserQuestion`
+- The user decides; the main session writes to file
+- **Do NOT invent formula values or balance numbers without specialist input.** A user without balance design expertise cannot evaluate raw numbers — they need the specialists' reasoning.
 
 **Cross-reference**: If a dependency GDD defines a formula whose output feeds into
 this system, reference it explicitly. Don't reinvent — connect.
@@ -448,9 +526,7 @@ design question, not a specification.
 - What happens when two rules apply at the same time?
 - What happens if a player finds an unintended interaction? (Identify degenerate strategies)
 
-**Agent delegation**: For systems with complex interactions, delegate to
-`systems-designer` to identify edge cases from the formula space. For narrative
-systems, consult `narrative-director` for story-breaking edge cases.
+**Agent delegation (MANDATORY)**: Spawn `systems-designer` via Task before finalising edge cases. Provide: the completed Sections C and D, and ask them to identify edge cases from the formula and rule space that the main session may have missed. For narrative systems, also spawn `narrative-director`. Present their findings and ask the user which to include.
 
 **Cross-reference**: Check edge cases against dependency GDDs. If a dependency
 defines a floor, cap, or resolution rule that this system could violate, flag it.
@@ -506,6 +582,8 @@ Include at least: one criterion per core rule from Section C, and one per formul
 from Section D. Do NOT write "the system works as designed" — every criterion must
 be independently verifiable by a QA tester without reading the GDD.
 
+**Agent delegation (MANDATORY)**: Spawn `qa-lead` via Task before finalising acceptance criteria. Provide: the completed GDD sections C, D, E, and ask them to validate that the criteria are independently testable and cover all core rules and formulas. Surface any gaps or untestable criteria to the user.
+
 **Questions to ask**:
 - What's the minimum set of tests that prove this works?
 - What performance budget does this system get? (frame time, memory)
@@ -518,16 +596,30 @@ not just this system in isolation.
 
 ### Optional Sections: Visual/Audio, UI Requirements, Open Questions
 
-These sections are included in the template but aren't part of the 8 required
-sections. Offer them after the required sections are done:
+These sections are included in the template. Visual/Audio is **REQUIRED** for visual system categories — not optional. Determine the requirement level before asking:
+
+**Visual/Audio is REQUIRED (mandatory — do not offer to skip) for these system categories:**
+- Combat, damage, health
+- UI systems (HUD, menus)
+- Animation, character movement
+- Visual effects, particles, shaders
+- Character systems
+- Dialogue, quests, lore
+- Level/world systems
+
+For required systems: **spawn `art-director` via Task** before drafting this section. Provide: system name, game concept, game pillars, art bible sections 1–4 if they exist. Ask them to specify: (1) VFX and visual feedback requirements for this system's events, (2) any animation or visual style constraints, (3) which art bible principles most directly apply to this system. Present their output; do NOT leave this section as `[To be designed]` for visual systems.
+
+For **all other system categories** (Foundation/Infrastructure, Economy, AI/pathfinding, Camera/input), offer the optional sections after the required sections:
 
 Use `AskUserQuestion`:
 - "The 8 required sections are complete. Do you want to also define Visual/Audio
   requirements, UI requirements, or capture open questions?"
   - Options: "Yes, all three", "Just open questions", "Skip — I'll add these later"
 
-For **Visual/Audio**: Coordinate with `art-director` and `audio-director` if detail
-is needed. Often a brief note suffices at the GDD stage.
+For **Visual/Audio** (non-required systems): Coordinate with `art-director` and `audio-director` if detail is needed. Often a brief note suffices at the GDD stage.
+
+> **Asset Spec Flag**: After the Visual/Audio section is written with real content, output this notice:
+> "📌 **Asset Spec** — Visual/Audio requirements are defined. After the art bible is approved, run `/asset-spec system:[system-name]` to produce per-asset visual descriptions, dimensions, and generation prompts from this section."
 
 For **UI Requirements**: Coordinate with `ux-designer` for complex UI systems.
 After writing this section, check whether it contains real content (not just
@@ -562,6 +654,11 @@ the source of truth). Verify:
 
 ### 5a-bis: Creative Director Pillar Review
 
+**Review mode check** — apply before spawning CD-GDD-ALIGN:
+- `solo` → skip. Note: "CD-GDD-ALIGN skipped — Solo mode." Proceed to Step 5b.
+- `lean` → skip (not a PHASE-GATE). Note: "CD-GDD-ALIGN skipped — Lean mode." Proceed to Step 5b.
+- `full` → spawn as normal.
+
 Before finalizing the GDD, spawn `creative-director` via Task using gate **CD-GDD-ALIGN** (`.claude/docs/director-gates.md`).
 
 Pass: completed GDD file path, game pillars (from `design/gdd/game-concept.md` or `design/gdd/game-pillars.md`), MDA aesthetics target.
@@ -610,11 +707,14 @@ Present a completion summary:
 > - Provisional assumptions: [list any assumptions about undesigned dependencies]
 > - Cross-system conflicts found: [list or "none"]
 
-Use `AskUserQuestion`:
-- "Run `/design-review` now to validate the GDD?"
-  - Options: "Yes, run review now", "I'll review it myself first", "Skip review"
+> **To validate this GDD, open a fresh Claude Code session and run:**
+> `/design-review design/gdd/[system-name].md`
+>
+> **Never run `/design-review` in the same session as `/design-system`.** The reviewing
+> agent must be independent of the authoring context. Running it here would inherit
+> the full design history, making independent critique impossible.
 
-If yes, invoke the design-review skill on the completed file.
+**NEVER offer to run `/design-review` inline.** Always direct the user to a fresh window.
 
 ### 5d: Update Systems Index
 
@@ -645,6 +745,7 @@ Update `production/session-state/active.md` with:
 Use `AskUserQuestion`:
 - "What's next?"
   - Options:
+    - "Run `/consistency-check` — verify this GDD's values don't conflict with existing GDDs (recommended before designing the next system)"
     - "Design next system ([next-in-order])" — if undesigned systems remain
     - "Fix review findings" — if design-review flagged issues
     - "Stop here for this session"
@@ -659,15 +760,19 @@ orchestrates the overall flow; agents provide expert content.
 
 | System Category | Primary Agent | Supporting Agent(s) |
 |----------------|---------------|---------------------|
-| Combat, damage, health | `game-designer` | `systems-designer` (formulas), `ai-programmer` (enemy AI) |
+| **Foundation/Infrastructure** (event bus, save/load, scene mgmt, service locator) | `systems-designer` | `gameplay-programmer` (feasibility), `engine-programmer` (engine integration) |
+| Combat, damage, health | `game-designer` | `systems-designer` (formulas), `ai-programmer` (enemy AI), `art-director` (hit feedback visual direction, VFX intent) |
 | Economy, loot, crafting | `economy-designer` | `systems-designer` (curves), `game-designer` (loops) |
 | Progression, XP, skills | `game-designer` | `systems-designer` (curves), `economy-designer` (sinks) |
-| Dialogue, quests, lore | `game-designer` | `narrative-director` (story), `writer` (content) |
-| UI systems (HUD, menus) | `game-designer` | `ux-designer` (flows), `ui-programmer` (feasibility) |
+| Dialogue, quests, lore | `game-designer` | `narrative-director` (story), `writer` (content), `art-director` (character visual profiles, cinematic tone) |
+| UI systems (HUD, menus) | `game-designer` | `ux-designer` (flows), `ui-programmer` (feasibility), `art-director` (visual style direction), `technical-artist` (render/shader constraints) |
 | Audio systems | `game-designer` | `audio-director` (direction), `sound-designer` (specs) |
 | AI, pathfinding, behavior | `game-designer` | `ai-programmer` (implementation), `systems-designer` (scoring) |
 | Level/world systems | `game-designer` | `level-designer` (spatial), `world-builder` (lore) |
 | Camera, input, controls | `game-designer` | `ux-designer` (feel), `gameplay-programmer` (feasibility) |
+| Animation, character movement | `game-designer` | `art-director` (animation style, pose language), `technical-artist` (rig/blend constraints), `gameplay-programmer` (feel) |
+| Visual effects, particles, shaders | `game-designer` | `art-director` (VFX visual direction), `technical-artist` (performance budget, shader complexity), `systems-designer` (trigger/state integration) |
+| Character systems (stats, archetypes) | `game-designer` | `art-director` (character visual archetype), `narrative-director` (character arc alignment), `systems-designer` (stat formulas) |
 
 **When delegating via Task tool**:
 - Provide: system name, game concept summary, dependency GDD excerpts, the specific
@@ -715,3 +820,13 @@ This skill follows the collaborative design principle at every step:
 **Never** write a section without user approval.
 **Never** contradict an existing approved GDD without flagging the conflict.
 **Always** show where decisions come from (dependency GDDs, pillars, user choices).
+
+## Context Window Awareness
+
+This is a long-running skill. After writing each section, check if the status line
+shows context at or above 70%. If so, append this notice to the response:
+
+> **Context is approaching the limit (≥70%).** Your progress is saved — all approved
+> sections are written to `design/gdd/[system-name].md`. When you're ready to continue,
+> open a fresh Claude Code session and run `/design-system [system-name]` — it will
+> detect which sections are complete and resume from the next one.