Add v0.6.0: full skill/agent QA pass, 3 new agents tested, template cleanup

Skills fixed: sprint-status (stale escalation, threshold), retrospective
(existing file detection, missing data fallback), changelog (misc category,
task-ref count), patch-notes (BLOCKED on missing changelog, tone/template
paths), story-readiness (Phase 0 mode resolution, QL-STORY-READY gate),
art-bible, brainstorm, design-system, ux-design, dev-story, story-done,
create-architecture, create-control-manifest, map-systems, propagate-design-change,
quick-design, prototype, asset-spec.

Agents fixed: all 4 directors (gate verdict token format), engine-programmer,
ui-programmer, tools-programmer, technical-artist (engine version safety),
gameplay-programmer (ADR compliance), godot-gdextension-specialist (ABI warning),
systems-designer (escalation path to creative-director), accessibility-specialist
(model, tools, WCAG criterion format, findings template), live-ops-designer
(escalation paths, battle pass value language), qa-tester (model, test case
format, evidence routing, ambiguous criteria, regression scope).

Specs updated: smoke-check and adopt specs rewritten to match actual skill
behavior. catalog.yaml reset to blank template state. Removed
session-state marketing research file, removed session-state from gitignore.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

CCGS Skill Testing Framework/catalog.yaml

@@ -1,5 +1,5 @@
 version: 2
-last_updated: "2026-04-06"
+last_updated: ""
 skills:
   # Critical — gate skills that control phase transitions
   - name: gate-check
@@ -801,32 +801,24 @@ agents:
   # Tier 1 Directors (Opus)
   - name: creative-director
     spec: CCGS Skill Testing Framework/agents/directors/creative-director.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: director
 
   - name: technical-director
     spec: CCGS Skill Testing Framework/agents/directors/technical-director.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: director
 
   - name: producer
     spec: CCGS Skill Testing Framework/agents/directors/producer.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: director
 
   - name: art-director
     spec: CCGS Skill Testing Framework/agents/directors/art-director.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: director
@@ -834,56 +826,42 @@ agents:
   # Tier 2 Leads (Sonnet)
   - name: lead-programmer
     spec: CCGS Skill Testing Framework/agents/leads/lead-programmer.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: lead
 
   - name: qa-lead
     spec: CCGS Skill Testing Framework/agents/leads/qa-lead.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: lead
 
   - name: narrative-director
     spec: CCGS Skill Testing Framework/agents/leads/narrative-director.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: lead
 
   - name: audio-director
     spec: CCGS Skill Testing Framework/agents/leads/audio-director.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: lead
 
   - name: game-designer
     spec: CCGS Skill Testing Framework/agents/leads/game-designer.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: lead
 
   - name: systems-designer
     spec: CCGS Skill Testing Framework/agents/leads/systems-designer.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: lead
 
   - name: level-designer
     spec: CCGS Skill Testing Framework/agents/leads/level-designer.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: lead
@@ -891,96 +869,72 @@ agents:
   # Core Specialists (Sonnet)
   - name: gameplay-programmer
     spec: CCGS Skill Testing Framework/agents/specialists/gameplay-programmer.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: specialist
 
   - name: ai-programmer
     spec: CCGS Skill Testing Framework/agents/specialists/ai-programmer.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: specialist
 
   - name: technical-artist
     spec: CCGS Skill Testing Framework/agents/specialists/technical-artist.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: specialist
 
   - name: sound-designer
     spec: CCGS Skill Testing Framework/agents/specialists/sound-designer.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: specialist
 
   - name: engine-programmer
     spec: CCGS Skill Testing Framework/agents/specialists/engine-programmer.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: specialist
 
   - name: tools-programmer
     spec: CCGS Skill Testing Framework/agents/specialists/tools-programmer.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: specialist
 
   - name: network-programmer
     spec: CCGS Skill Testing Framework/agents/specialists/network-programmer.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: specialist
 
   - name: security-engineer
     spec: CCGS Skill Testing Framework/agents/qa/security-engineer.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: qa
 
   - name: accessibility-specialist
     spec: CCGS Skill Testing Framework/agents/qa/accessibility-specialist.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: qa
 
   - name: ux-designer
     spec: CCGS Skill Testing Framework/agents/specialists/ux-designer.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: specialist
 
   - name: ui-programmer
     spec: CCGS Skill Testing Framework/agents/specialists/ui-programmer.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: specialist
 
   - name: performance-analyst
     spec: CCGS Skill Testing Framework/agents/specialists/performance-analyst.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: specialist
@@ -988,40 +942,30 @@ agents:
   # Engine Specialists — Godot
   - name: godot-specialist
     spec: CCGS Skill Testing Framework/agents/engine/godot/godot-specialist.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: engine
 
   - name: godot-gdscript-specialist
     spec: CCGS Skill Testing Framework/agents/engine/godot/godot-gdscript-specialist.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: engine
 
   - name: godot-csharp-specialist
     spec: CCGS Skill Testing Framework/agents/engine/godot/godot-csharp-specialist.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: engine
 
   - name: godot-shader-specialist
     spec: CCGS Skill Testing Framework/agents/engine/godot/godot-shader-specialist.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: engine
 
   - name: godot-gdextension-specialist
     spec: CCGS Skill Testing Framework/agents/engine/godot/godot-gdextension-specialist.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: engine
@@ -1029,40 +973,30 @@ agents:
   # Engine Specialists — Unity
   - name: unity-specialist
     spec: CCGS Skill Testing Framework/agents/engine/unity/unity-specialist.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: engine
 
   - name: unity-ui-specialist
     spec: CCGS Skill Testing Framework/agents/engine/unity/unity-ui-specialist.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: engine
 
   - name: unity-shader-specialist
     spec: CCGS Skill Testing Framework/agents/engine/unity/unity-shader-specialist.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: engine
 
   - name: unity-dots-specialist
     spec: CCGS Skill Testing Framework/agents/engine/unity/unity-dots-specialist.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: engine
 
   - name: unity-addressables-specialist
     spec: CCGS Skill Testing Framework/agents/engine/unity/unity-addressables-specialist.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: engine
@@ -1070,40 +1004,30 @@ agents:
   # Engine Specialists — Unreal
   - name: unreal-specialist
     spec: CCGS Skill Testing Framework/agents/engine/unreal/unreal-specialist.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: engine
 
   - name: ue-blueprint-specialist
     spec: CCGS Skill Testing Framework/agents/engine/unreal/ue-blueprint-specialist.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: engine
 
   - name: ue-gas-specialist
     spec: CCGS Skill Testing Framework/agents/engine/unreal/ue-gas-specialist.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: engine
 
   - name: ue-umg-specialist
     spec: CCGS Skill Testing Framework/agents/engine/unreal/ue-umg-specialist.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: engine
 
   - name: ue-replication-specialist
     spec: CCGS Skill Testing Framework/agents/engine/unreal/ue-replication-specialist.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: engine
@@ -1111,56 +1035,42 @@ agents:
   # Operations
   - name: devops-engineer
     spec: CCGS Skill Testing Framework/agents/operations/devops-engineer.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: operations
 
   - name: release-manager
     spec: CCGS Skill Testing Framework/agents/operations/release-manager.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: operations
 
   - name: live-ops-designer
     spec: CCGS Skill Testing Framework/agents/operations/live-ops-designer.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: operations
 
   - name: community-manager
     spec: CCGS Skill Testing Framework/agents/operations/community-manager.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: operations
 
   - name: analytics-engineer
     spec: CCGS Skill Testing Framework/agents/operations/analytics-engineer.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: operations
 
   - name: economy-designer
     spec: CCGS Skill Testing Framework/agents/operations/economy-designer.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: operations
 
   - name: localization-lead
     spec: CCGS Skill Testing Framework/agents/operations/localization-lead.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: operations
@@ -1168,32 +1078,24 @@ agents:
   # QA & Creative
   - name: qa-tester
     spec: CCGS Skill Testing Framework/agents/qa/qa-tester.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: qa
 
   - name: prototyper
     spec: CCGS Skill Testing Framework/agents/specialists/prototyper.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: specialist
 
   - name: writer
     spec: CCGS Skill Testing Framework/agents/specialists/writer.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: specialist
 
   - name: world-builder
     spec: CCGS Skill Testing Framework/agents/specialists/world-builder.md
-    last_static: ""
-    last_static_result: ""
     last_spec: ""
     last_spec_result: ""
     category: specialist

CCGS Skill Testing Framework/quality-rubric.md

@@ -32,33 +32,42 @@ auto-advancing stage and must respect the three review modes.
 
 **Skills**: design-review, architecture-review, review-all-gdds
 
-Review skills read documents and produce structured verdicts. They are strictly
-read-only and must never trigger director gates themselves.
+Review skills read documents and produce structured verdicts. They are primarily
+read-only and must not trigger director gates during the analysis phase.
 
 | Metric | PASS criteria |
 |---|---|
-| **R1 — Read-only enforcement** | `allowed-tools` does not include `Write` or `Edit`; skill never offers to modify the reviewed document |
+| **R1 — Read-only enforcement** | Skill does not modify the reviewed document without explicit user approval; any write operations (review logs, index updates) are gated behind "May I write" |
 | **R2 — 8-section check** | Skill evaluates all 8 required GDD sections (or equivalent architectural sections) explicitly |
 | **R3 — Correct verdict vocabulary** | Verdict is exactly one of: APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED (design) or PASS / CONCERNS / FAIL (architecture) |
-| **R4 — No director gates** | Skill does not spawn any director gate regardless of review mode; it IS the review |
+| **R4 — No director gates during analysis** | Skill does not spawn director gates during its analysis phases; post-analysis director review (as in architecture-review) is acceptable when the skill's scope and stakes warrant it |
 | **R5 — Structured findings** | Output contains a per-section status table or checklist before the final verdict |
 
+> **Exceptions:**
+> - `design-review`: Has `Write, Edit` in allowed-tools to support an optional "Revise now" path (all writes gated behind user approval) and to write review logs. R1 is satisfied because the reviewed document is never silently modified.
+> - `architecture-review`: Spawns TD-ARCHITECTURE and LP-FEASIBILITY gates after its analysis is complete. This is intentional — architecture review is high-stakes and benefits from director sign-off. R4 is satisfied because the gates run post-analysis, not during it.
+
 ---
 
 ### `authoring`
 
 **Skills**: design-system, quick-design, architecture-decision, ux-design, ux-review, art-bible, create-architecture
 
-Authoring skills create or update design documents section by section. They must
-collaborate before writing and handle both new and existing (retrofit) documents.
+Authoring skills create or update design documents collaboratively. Full GDD/UX
+authoring skills use a section-by-section cycle; lightweight authoring skills use
+a single-draft pattern appropriate to their smaller scope.
 
 | Metric | PASS criteria |
 |---|---|
-| **A1 — Section-by-section cycle** | Skill authors one section at a time, presenting content for approval before proceeding to the next |
-| **A2 — May-I-write per section** | Skill asks "May I write this to [filepath]?" before each section write, not just once at the end |
-| **A3 — Retrofit mode** | Skill detects if the target file already exists and offers to update specific sections rather than overwriting the whole document |
+| **A1 — Section-by-section cycle** | Full authoring skills (design-system, ux-design, art-bible) author one section at a time, presenting content for approval before proceeding to the next. Lightweight skills (quick-design, architecture-decision, create-architecture) may draft the complete document then ask for approval — single-draft is acceptable for documents under ~4 hours of implementation scope. |
+| **A2 — May-I-write per section** | Full authoring skills ask "May I write this to [filepath]?" before each section write. Lightweight skills ask once for the complete document. |
+| **A3 — Retrofit mode** | Skill detects if the target file already exists and offers to update specific sections rather than overwriting the whole document. Lightweight skills (quick-design) that always create new files are exempt. |
 | **A4 — Director gate at correct tier** | If a director gate is defined for this skill (e.g., CD-GDD-ALIGN, TD-ADR), it runs at the correct mode threshold (full/lean) — NOT in solo |
-| **A5 — Skeleton-first** | Skill creates a file skeleton with all section headers before filling content, to preserve progress on session interruption |
+| **A5 — Skeleton-first** | Full authoring skills create a file skeleton with all section headers before filling content, to preserve progress on session interruption. Lightweight skills are exempt. |
+
+> **Full authoring skills** (must pass all 5 metrics): `design-system`, `ux-design`, `art-bible`
+> **Lightweight authoring skills** (A1, A2, A5 use single-draft pattern; A3 exempt for new-file-only skills): `quick-design`, `architecture-decision`, `create-architecture`
+> **Review-mode skill** (evaluated against review metrics): `ux-review`
 
 ---
 

CCGS Skill Testing Framework/skills/utility/adopt.md

@@ -2,17 +2,16 @@
 
 ## Skill Summary
 
-`/adopt` performs brownfield onboarding: it reads an existing non-Claude-Code
-project's source files, detects the engine and language, and generates a
-matching CLAUDE.md stub plus a populated `technical-preferences.md` to bring
-the project under the Claude Code Game Studios framework. It may also produce
-skeleton GDD files if enough design intent can be inferred from the code.
+`/adopt` audits an existing project's artifacts — GDDs, ADRs, stories, infrastructure
+files, and `technical-preferences.md` — for format compliance with the template's
+skill pipeline. It classifies every gap by severity (BLOCKING / HIGH / MEDIUM / LOW),
+composes a numbered, ordered migration plan, and writes it to `docs/adoption-plan-[date].md`
+after explicit user approval via `AskUserQuestion`.
 
-Each generated file is gated behind a "May I write" ask. If an existing CLAUDE.md
-or `technical-preferences.md` is detected, the skill offers to merge rather than
-overwrite. The skill has no director gates. Verdicts: COMPLETE (full analysis done
-and files written), PARTIAL (analysis complete but some fields are ambiguous),
-or BLOCKED (cannot proceed — no source code found or user declined all writes).
+This skill is distinct from `/project-stage-detect` (which checks what exists).
+`/adopt` checks whether what exists will actually work with the template's skills.
+
+No director gates apply. The skill does NOT invoke any director agents.
 
 ---
 
@@ -22,149 +21,194 @@ 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: COMPLETE, PARTIAL, BLOCKED
-- [ ] Contains "May I write" collaborative protocol language before each file creation
-- [ ] Has a next-step handoff at the end (e.g., `/setup-engine` to refine or `/brainstorm`)
+- [ ] Contains severity tier keywords: BLOCKING, HIGH, MEDIUM, LOW
+- [ ] Contains "May I write" or `AskUserQuestion` language before writing the adoption plan
+- [ ] Has a next-step handoff at the end (e.g., offering to fix the highest-priority gap immediately)
 
 ---
 
 ## Director Gate Checks
 
-None. `/adopt` is a brownfield onboarding utility. No director gates apply.
+None. `/adopt` is a brownfield audit utility. No director gates apply.
 
 ---
 
 ## Test Cases
 
-### Case 1: Happy Path — Existing Unity project with C# code detected
+### Case 1: Happy Path — All GDDs compliant, no gaps, COMPLIANT
 
 **Fixture:**
-- `src/` contains `.cs` files with Unity-specific namespaces (`using UnityEngine;`)
-- No CLAUDE.md overrides, no `technical-preferences.md` beyond placeholders
-- Project has a recognizable folder structure (Assets/, Scripts/)
+- `design/gdd/` contains 3 GDD files; each has all 8 required sections with content
+- `docs/architecture/adr-0001.md` exists with `## Status`, `## Engine Compatibility`,
+  and all other required sections
+- `production/stage.txt` exists
+- `docs/architecture/tr-registry.yaml` and `docs/architecture/control-manifest.md` exist
+- Engine configured in `technical-preferences.md`
 
 **Input:** `/adopt`
 
 **Expected behavior:**
-1. Skill scans `src/` and detects C# files with Unity API imports
-2. Skill identifies engine as Unity, language as C#
-3. Skill produces a draft `technical-preferences.md` with engine/language fields populated
-4. Skill produces a draft CLAUDE.md stub with detected project structure
-5. Skill asks "May I write `technical-preferences.md`?" and then "May I write CLAUDE.md?"
-6. Files are written after approval; verdict is COMPLETE
+1. Skill emits "Scanning project artifacts..." then reads all artifacts silently
+2. Reports detected phase, GDD count, ADR count, story count
+3. Phase 2 audit: all 3 GDDs have all 8 sections, Status field present and valid
+4. ADR audit: all required sections present
+5. Infrastructure audit: all critical files exist
+6. Phase 3: zero BLOCKING, zero HIGH, zero MEDIUM, zero LOW gaps
+7. Summary reports: "No blocking gaps — this project is template-compatible"
+8. Uses `AskUserQuestion` to ask about writing the plan; user selects write
+9. Adoption plan is written to `docs/adoption-plan-[date].md`
+10. Phase 7 offers next action: no blocking gaps, offers options for next steps
 
 **Assertions:**
-- [ ] Engine detected as Unity (not Godot or Unreal)
-- [ ] Language detected as C#
-- [ ] Draft is shown to user before any "May I write" ask
-- [ ] "May I write" is asked separately for each file
-- [ ] Verdict is COMPLETE after both files are written
+- [ ] Skill reads silently before presenting any output
+- [ ] "Scanning project artifacts..." appears before the silent read phase
+- [ ] Gap counts show 0 BLOCKING, 0 HIGH, 0 MEDIUM (or only LOW)
+- [ ] `AskUserQuestion` is used before writing the adoption plan
+- [ ] Adoption plan file is written to `docs/adoption-plan-[date].md`
+- [ ] Phase 7 offers a specific next action (not just a list)
 
 ---
 
-### Case 2: Mixed Languages — Partial analysis, asks user to clarify
+### Case 2: Non-Compliant Documents — GDDs missing sections, NEEDS MIGRATION
 
 **Fixture:**
-- `src/` contains both `.gd` (GDScript) and `.cs` (C#) files
-- Engine cannot be definitively identified from the mix
+- `design/gdd/` contains 2 GDD files:
+  - `combat.md` — missing `## Acceptance Criteria` and `## Formulas` sections
+  - `movement.md` — all 8 sections present
+- One ADR (`adr-0001.md`) is missing `## Status` section
+- `docs/architecture/tr-registry.yaml` does not exist
 
 **Input:** `/adopt`
 
 **Expected behavior:**
-1. Skill scans source and detects conflicting language signals
-2. Skill reports: "Mixed language signals detected (GDScript + C#) — cannot auto-identify engine"
-3. Skill presents the ambiguous findings and asks the user to confirm: Godot with C# or Unity?
-4. After user clarifies, skill resumes analysis with confirmed engine
-5. Produces a PARTIAL analysis noting fields that required manual clarification
+1. Skill scans all artifacts
+2. Phase 2 audit finds:
+   - `combat.md`: 2 missing sections (Acceptance Criteria, Formulas)
+   - `adr-0001.md`: missing `## Status` — BLOCKING impact
+   - `tr-registry.yaml`: missing — HIGH impact
+3. Phase 3 classifies:
+   - BLOCKING: `adr-0001.md` missing `## Status` (story-readiness silently passes)
+   - HIGH: `tr-registry.yaml` missing; `combat.md` missing Acceptance Criteria (can't generate stories)
+   - MEDIUM: `combat.md` missing Formulas
+4. Phase 4 builds ordered migration plan:
+   - Step 1 (BLOCKING): Add `## Status` to `adr-0001.md` — command: `/architecture-decision retrofit`
+   - Step 2 (HIGH): Run `/architecture-review` to bootstrap tr-registry.yaml
+   - Step 3 (HIGH): Add Acceptance Criteria to `combat.md` — command: `/design-system retrofit`
+   - Step 4 (MEDIUM): Add Formulas to `combat.md`
+5. Gap Preview shows BLOCKING items as bullets (actual file names), HIGH/MEDIUM as counts
+6. `AskUserQuestion` asks to write the plan; writes after approval
+7. Phase 7 offers to fix the highest-priority gap (ADR Status) immediately
 
 **Assertions:**
-- [ ] Skill does NOT guess or silently pick an engine when signals conflict
-- [ ] Ambiguous findings are reported to the user explicitly
-- [ ] User choice is incorporated into the generated config
-- [ ] Verdict is PARTIAL (not COMPLETE) when manual clarification was required
+- [ ] BLOCKING gaps are listed as explicit file-name bullets in the Gap Preview
+- [ ] HIGH and MEDIUM shown as counts in Gap Preview
+- [ ] Migration plan items are in BLOCKING-first order
+- [ ] Each plan item includes the fix command or manual steps
+- [ ] `AskUserQuestion` is used before writing
+- [ ] Phase 7 offers to immediately retrofit the first BLOCKING item
 
 ---
 
-### Case 3: CLAUDE.md Already Exists — Offers merge rather than overwrite
+### Case 3: Mixed State — Some docs compliant, some not, partial report
 
 **Fixture:**
-- `CLAUDE.md` exists with custom content (project name, existing imports)
-- `technical-preferences.md` exists with some fields populated
+- 4 GDD files: 2 fully compliant, 2 with gaps (one missing Tuning Knobs, one missing Edge Cases)
+- ADRs: 3 files — 2 compliant, 1 missing `## ADR Dependencies`
+- Stories: 5 files — 3 have TR-ID references, 2 do not
+- Infrastructure: all critical files present; `technical-preferences.md` fully configured
 
 **Input:** `/adopt`
 
 **Expected behavior:**
-1. Skill reads existing CLAUDE.md and detects it is already populated
-2. Skill reports: "CLAUDE.md already exists — offering to merge, not overwrite"
-3. Skill presents a diff of new fields vs. existing content
-4. Skill asks "May I merge new fields into CLAUDE.md?" (not "May I write")
-5. If user approves: only new or changed fields are added; existing content preserved
+1. Skill audits all artifact types
+2. Audit summary shows totals: "4 GDDs (2 fully compliant, 2 with gaps); 3 ADRs
+   (2 fully compliant, 1 with gaps); 5 stories (3 with TR-IDs, 2 without)"
+3. Gap classification:
+   - No BLOCKING gaps
+   - HIGH: 1 ADR missing `## ADR Dependencies`
+   - MEDIUM: 2 GDDs with missing sections; 2 stories missing TR-IDs
+   - LOW: none
+4. Migration plan lists HIGH gap first, then MEDIUM gaps in order
+5. Note included: "Existing stories continue to work — do not regenerate stories
+   that are in progress or done"
+6. `AskUserQuestion` to write plan; writes after approval
 
 **Assertions:**
-- [ ] Skill does NOT overwrite existing CLAUDE.md without explicit user approval for a full replace
-- [ ] Merge option is offered when the file already exists
-- [ ] Diff is shown before the merge ask
-- [ ] Existing custom content is preserved in the merged output
+- [ ] Per-artifact compliance tallies are shown (N compliant, M with gaps)
+- [ ] Existing story compatibility note is included in the plan
+- [ ] No BLOCKING gaps results in no BLOCKING section in migration plan
+- [ ] HIGH gap precedes MEDIUM gaps in plan ordering
+- [ ] `AskUserQuestion` is used before writing
 
 ---
 
-### Case 4: No Source Code Found — Stops with error
+### Case 4: No Artifacts Found — Fresh project, guidance to run /start
 
 **Fixture:**
-- Repository has only documentation files (`.md`) and no source code in `src/`
-- No engine-identifiable files anywhere in the repo
+- Repository has no files in `design/gdd/`, `docs/architecture/`, `production/epics/`
+- `production/stage.txt` does not exist
+- `src/` directory does not exist or has fewer than 10 files
+- No game-concept.md, no systems-index.md
 
 **Input:** `/adopt`
 
 **Expected behavior:**
-1. Skill scans `src/` and all likely code locations — finds nothing
-2. Skill outputs: "No source code detected — cannot perform brownfield analysis"
-3. Skill suggests alternatives: run `/start` for a new project, or point to a
-   different directory if source is located elsewhere
-4. No files are written
+1. Phase 1 existence check finds no artifacts
+2. Skill infers "Fresh" — no brownfield work to migrate
+3. Uses `AskUserQuestion`:
+   - "This looks like a fresh project — no existing artifacts found. `/adopt` is for
+     projects with work to migrate. What would you like to do?"
+   - Options: "Run `/start`", "My artifacts are in a non-standard location", "Cancel"
+4. Skill stops — does not proceed to audit regardless of user selection
 
 **Assertions:**
-- [ ] Verdict is BLOCKED
-- [ ] Error message explicitly states no source code was found
-- [ ] Alternatives (`/start` or directory guidance) are provided
-- [ ] No "May I write" prompts appear (nothing to write)
+- [ ] `AskUserQuestion` is used (not a plain text message) when no artifacts are found
+- [ ] `/start` is presented as a named option
+- [ ] Skill stops after the question — no audit phases run
+- [ ] No adoption plan file is written
 
 ---
 
-### Case 5: Director Gate Check — No gate; adopt is a utility onboarding skill
+### Case 5: Director Gate Check — No gate; adopt is a utility audit skill
 
 **Fixture:**
-- Existing project with detectable source code
+- Project with a mix of compliant and non-compliant GDDs
 
 **Input:** `/adopt`
 
 **Expected behavior:**
-1. Skill completes full brownfield analysis and produces config files
+1. Skill completes full audit and produces migration plan
 2. No director agents are spawned at any point
 3. No gate IDs (CD-*, TD-*, AD-*, PR-*) appear in output
+4. No `/gate-check` is invoked during the skill run
 
 **Assertions:**
 - [ ] No director gate is invoked
 - [ ] No gate skip messages appear
-- [ ] Skill reaches COMPLETE or PARTIAL without any gate verdict
+- [ ] Skill reaches plan-writing or cancellation without any gate verdict
 
 ---
 
 ## Protocol Compliance
 
-- [ ] Scans source before generating any config content
-- [ ] Shows draft config to user before asking to write
-- [ ] Asks "May I write" (or "May I merge") before each file operation
-- [ ] Detects existing files and offers merge path rather than silent overwrite
-- [ ] Ends with COMPLETE, PARTIAL, or BLOCKED verdict
+- [ ] Emits "Scanning project artifacts..." before silent read phase
+- [ ] Reads all artifacts silently before presenting any results
+- [ ] Shows Adoption Audit Summary and Gap Preview before asking to write
+- [ ] Uses `AskUserQuestion` before writing the adoption plan file
+- [ ] Adoption plan written to `docs/adoption-plan-[date].md` — not to any other path
+- [ ] Migration plan items ordered: BLOCKING first, HIGH second, MEDIUM third, LOW last
+- [ ] Phase 7 always offers a single specific next action (not a generic list)
+- [ ] Never regenerates existing artifacts — only fills gaps in what exists
+- [ ] Does not invoke director gates at any point
 
 ---
 
 ## Coverage Notes
 
-- The Unreal Engine + Blueprint detection case (`.uasset`, `.umap` files)
-  follows the same happy path pattern as Case 1 and is not separately tested.
-- Multi-directory source layouts (monorepo style) are not tested; the skill
-  assumes a conventional single-project structure.
-- GDD skeleton generation from inferred design intent is noted as a capability
-  but not fixture-tested here — it follows from the PARTIAL analysis pattern.
+- The `gdds`, `adrs`, `stories`, and `infra` argument modes narrow the audit scope;
+  each follows the same pattern as the full audit but limited to that artifact type.
+  Not separately fixture-tested here.
+- The systems-index.md parenthetical status value check (BLOCKING) is a special case
+  that triggers an immediate fix offer before writing the plan; not separately tested.
+- The review-mode.txt prompt (Phase 6b) runs after plan writing if `production/review-mode.txt`
+  does not exist; not separately tested here.

CCGS Skill Testing Framework/skills/utility/smoke-check.md

@@ -2,15 +2,18 @@
 
 ## Skill Summary
 
-`/smoke-check` runs the critical path smoke test checklist for a build. It reads
-the QA plan from `production/qa/` and checks each critical path item against the
-acceptance criteria defined in the current sprint's stories. Items that can be
-evaluated analytically are assessed; items that require runtime verification or
-visual inspection are flagged as NEEDS MANUAL CHECK.
+`/smoke-check` is the gate between implementation and QA hand-off. It detects the
+test environment, runs the automated test suite (via Bash), scans test coverage
+against sprint stories, and uses `AskUserQuestion` to batch-verify manual smoke
+checks with the developer. It writes a report to `production/qa/smoke-[date].md`
+after explicit user approval.
 
-The skill produces no file writes — output is conversational. No director gates
-apply. Verdicts: PASS (all critical items verified), FAIL (at least one critical
-item fails), or NEEDS MANUAL CHECK (critical items exist that require human verification).
+Verdicts: PASS (tests pass, all smoke checks pass, no missing test evidence),
+PASS WITH WARNINGS (tests pass or NOT RUN, all critical checks pass, but advisory
+gaps exist such as missing test coverage), or FAIL (any automated test failure or
+any Batch 1/Batch 2 smoke check returns FAIL).
+
+No director gates apply. The skill does NOT invoke any director agents.
 
 ---
 
@@ -20,150 +23,171 @@ 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: PASS, FAIL, NEEDS MANUAL CHECK
-- [ ] Does NOT contain "May I write" language (skill is read-only)
-- [ ] Has a next-step handoff (e.g., `/bug-report` on FAIL, `/release-checklist` on PASS)
+- [ ] Contains verdict keywords: PASS, PASS WITH WARNINGS, FAIL
+- [ ] Contains "May I write" collaborative protocol language before writing the report
+- [ ] Has a next-step handoff (e.g., `/bug-report` on FAIL, QA hand-off guidance on PASS)
 
 ---
 
 ## Director Gate Checks
 
-None. `/smoke-check` is a QA utility skill. No director gates apply.
+None. `/smoke-check` is a pre-QA utility skill. No director gates apply.
 
 ---
 
 ## Test Cases
 
-### Case 1: Happy Path — All critical path items verifiable, PASS
+### Case 1: Happy Path — Automated tests pass, manual items confirmed, PASS
 
 **Fixture:**
-- `production/qa/qa-plan-sprint-005.md` exists with 4 critical path items
-- All 4 items are logic or integration type (analytically assessable)
-- Corresponding story ACs are defined and met per sprint stories
+- `tests/` directory exists with a GDUnit4 runner script
+- Engine detected as Godot from `technical-preferences.md`
+- `production/qa/qa-plan-sprint-005.md` exists
+- Automated test runner reports 12 tests, 12 passing, 0 failing
+- Developer confirms all Batch 1 and Batch 2 smoke checks as PASS
+- All sprint stories have matching test files (no MISSING coverage)
 
 **Input:** `/smoke-check`
 
 **Expected behavior:**
-1. Skill reads the QA plan and identifies 4 critical path items
-2. Skill evaluates each item against the story's acceptance criteria
-3. All 4 items pass
-4. Skill outputs a checklist: each item with a PASS marker
-5. Verdict is PASS with summary: "4/4 critical path items verified"
+1. Skill detects test directory and engine, notes QA plan found
+2. Runs `godot --headless --script tests/gdunit4_runner.gd` via Bash
+3. Parses output: 12/12 passing
+4. Scans test coverage — all stories COVERED or EXPECTED
+5. Uses `AskUserQuestion` for Batch 1 (core stability) and Batch 2 (sprint mechanics)
+6. Developer selects PASS for all items
+7. Report assembled: automated tests PASS, all smoke checks PASS, no MISSING coverage
+8. Asks "May I write this smoke check report to `production/qa/smoke-[date].md`?"
+9. Writes report after approval
+10. Delivers verdict: PASS
 
 **Assertions:**
-- [ ] All 4 items appear in the checklist output
-- [ ] Each item is marked PASS
+- [ ] Automated test runner is invoked via Bash
+- [ ] `AskUserQuestion` is used for manual smoke check batches
+- [ ] "May I write" is asked before writing the report file
+- [ ] Report is written to `production/qa/smoke-[date].md`
 - [ ] Verdict is PASS
-- [ ] No files are written
 
 ---
 
-### Case 2: Failure Path — One critical item fails, FAIL verdict
+### Case 2: Failure Path — Automated test fails, FAIL verdict
 
 **Fixture:**
-- QA plan has 3 critical path items
-- Item 2 ("Player health does not go below 0") fails — story AC indicates
-  clamping logic was not implemented
+- `tests/` directory exists, engine is Godot
+- Automated test runner reports 10 tests run: 8 passing, 2 failing
+  - Failing tests: `test_health_clamp_at_zero`, `test_damage_calculation_negative`
+- QA plan exists
 
 **Input:** `/smoke-check`
 
 **Expected behavior:**
-1. Skill evaluates all 3 items
-2. Item 1 and Item 3 pass; Item 2 fails
-3. Skill outputs checklist with specific failure: "Item 2 FAIL — Health clamping not verified"
-4. Verdict is FAIL
-5. Skill suggests running `/bug-report` for the failing item
+1. Skill runs automated tests via Bash
+2. Parses output — 2 failures detected
+3. Records failing test names
+4. Proceeds through manual smoke check batches
+5. Report shows automated tests as FAIL with failing test names listed
+6. Asks to write report; writes after approval
+7. Delivers FAIL verdict with message: "The smoke check failed. Do not hand off to
+   QA until these failures are resolved." Lists failing tests and suggests fixing
+   then re-running `/smoke-check`
 
 **Assertions:**
-- [ ] Verdict is FAIL (not PARTIAL or NEEDS MANUAL CHECK)
-- [ ] Failing item is identified by name/description
-- [ ] Passing items are also shown (not hidden)
-- [ ] `/bug-report` is suggested for the failure
+- [ ] Failing test names are listed in the report
+- [ ] Verdict is FAIL
+- [ ] Post-verdict message directs developer to fix failures before QA hand-off
+- [ ] `/smoke-check` re-run is suggested after fixing
 
 ---
 
-### Case 3: Visual Item Cannot Be Auto-Verified — NEEDS MANUAL CHECK
+### Case 3: Manual Confirmation — AskUserQuestion used, PASS WITH WARNINGS
 
 **Fixture:**
-- QA plan has 3 items: 2 logic items (PASS) and 1 visual item
-  ("Explosion VFX triggers correctly on enemy death" — ADVISORY, visual type)
+- `tests/` directory exists, engine is Godot
+- Automated test runner reports all tests passing (8/8)
+- One Logic story has no matching test file (MISSING coverage)
+- Developer confirms all Batch 1 and Batch 2 smoke checks as PASS
 
 **Input:** `/smoke-check`
 
 **Expected behavior:**
-1. Skill evaluates the 2 logic items — both pass
-2. Skill evaluates the visual item — cannot be verified analytically
-3. Visual item is marked NEEDS MANUAL CHECK with a note: "Visual quality requires
-   human verification — see production/qa/evidence/"
-4. Verdict is NEEDS MANUAL CHECK (not PASS, because human action is required)
-5. Guidance on how to perform manual check is provided
+1. Automated tests PASS
+2. Coverage scan finds 1 MISSING entry for a Logic story
+3. `AskUserQuestion` is used for Batch 1 and Batch 2 — developer confirms all PASS
+4. Report shows: automated tests PASS, manual checks all PASS, 1 MISSING coverage entry
+5. Verdict is PASS WITH WARNINGS — build ready for QA, but MISSING entry must be
+   resolved before `/story-done` closes the affected story
+6. Asks to write report; writes after approval
 
 **Assertions:**
-- [ ] Verdict is NEEDS MANUAL CHECK (not PASS or FAIL)
-- [ ] Visual item is marked with explicit NEEDS MANUAL CHECK tag
-- [ ] Guidance for manual verification process is included
-- [ ] Logic items are still shown as PASS
+- [ ] `AskUserQuestion` is used for manual smoke check batches (not inline text prompts)
+- [ ] MISSING test coverage entry appears in the report
+- [ ] Verdict is PASS WITH WARNINGS (not PASS, not FAIL)
+- [ ] Advisory note explains MISSING entry must be resolved before `/story-done`
+- [ ] Report file is written to `production/qa/smoke-[date].md`
 
 ---
 
-### Case 4: No Smoke Test Plan — Guidance to run /qa-plan
+### Case 4: No Test Directory — Skill stops with guidance
 
 **Fixture:**
-- `production/qa/` directory exists but contains no QA plan file for the
-  current sprint
-- Current sprint is sprint-006
+- `tests/` directory does not exist
+- Engine is configured as Godot
 
 **Input:** `/smoke-check`
 
 **Expected behavior:**
-1. Skill looks for QA plan for the current sprint — not found
-2. Skill outputs: "No smoke test plan found for sprint-006"
-3. Skill suggests running `/qa-plan sprint-006` first
-4. No checklist is produced
+1. Phase 1 checks for `tests/` directory — not found
+2. Skill outputs: "No test directory found at `tests/`. Run `/test-setup` to
+   scaffold the testing infrastructure, or create the directory manually if
+   tests live elsewhere."
+3. Skill stops — no automated tests run, no manual smoke checks, no report written
 
 **Assertions:**
-- [ ] Error message names the missing sprint's plan
-- [ ] `/qa-plan` is suggested with the correct sprint argument
-- [ ] Skill does not produce a checklist with no plan
-- [ ] Verdict is not PASS (error state, no checklist evaluated)
+- [ ] Error message references the missing `tests/` directory
+- [ ] `/test-setup` is suggested as the remediation step
+- [ ] Skill stops after this message (no further phases run)
+- [ ] No report file is written
 
 ---
 
-### Case 5: Director Gate Check — No gate; smoke-check is a QA utility
+### Case 5: Director Gate Check — No gate; smoke-check is a QA pre-check utility
 
 **Fixture:**
-- Valid QA plan with assessable items
+- Valid test setup, automated tests pass, manual smoke checks confirmed
 
 **Input:** `/smoke-check`
 
 **Expected behavior:**
-1. Skill runs the smoke check and produces a verdict
-2. No director agents are spawned
-3. No gate IDs appear in output
+1. Skill runs all phases and produces a PASS or PASS WITH WARNINGS verdict
+2. No director agents are spawned at any point
+3. No gate IDs (CD-*, TD-*, AD-*, PR-*) appear in output
+4. No `/gate-check` is invoked
 
 **Assertions:**
 - [ ] No director gate is invoked
-- [ ] No write tool is called
-- [ ] Verdict is PASS, FAIL, or NEEDS MANUAL CHECK — no gate verdict involved
+- [ ] No gate skip messages appear
+- [ ] Verdict is PASS, PASS WITH WARNINGS, or FAIL — no gate verdict involved
 
 ---
 
 ## Protocol Compliance
 
-- [ ] Reads QA plan before evaluating any items
-- [ ] Evaluates each item explicitly (no silent skips)
-- [ ] Visual/feel items are always flagged NEEDS MANUAL CHECK (not auto-passed)
-- [ ] FAIL verdict triggers on first critical failure (not advisory)
-- [ ] Verdict is PASS, FAIL, or NEEDS MANUAL CHECK — no other verdicts
+- [ ] Uses `AskUserQuestion` for all manual smoke check batches (Batch 1, Batch 2, Batch 3)
+- [ ] Runs automated tests via Bash before asking any manual questions
+- [ ] Asks "May I write" before creating the report file — never writes without approval
+- [ ] Verdict vocabulary is strictly PASS / PASS WITH WARNINGS / FAIL — no other verdicts
+- [ ] FAIL is triggered by automated test failures or Batch 1/Batch 2 FAIL responses
+- [ ] PASS WITH WARNINGS is triggered when MISSING test coverage exists but no critical failures
+- [ ] NOT RUN (engine binary unavailable) is recorded as a warning, not a FAIL
+- [ ] Does not invoke director gates at any point
 
 ---
 
 ## Coverage Notes
 
-- The case where the QA plan exists but has no critical path items (all items
-  are ADVISORY) is not tested; PASS would be returned with a note that no
-  critical items were checked.
-- The distinction between BLOCKING and ADVISORY gate levels from coding-standards.md
-  is relied upon to determine which items can produce a FAIL.
-- Build-specific failures (runtime crashes) that occur during manual testing are
-  outside the scope of this skill — use `/bug-report` for those.
+- The `quick` argument (skips Phase 3 coverage scan and Batch 3) is not separately
+  fixture-tested; it follows the same pattern as Case 1 with a coverage-skip note in output.
+- The `--platform` argument adds platform-specific AskUserQuestion batches and a
+  per-platform verdict table; not separately tested here.
+- The case where the engine binary is not on PATH (NOT RUN) follows the PASS WITH
+  WARNINGS pattern and is covered by the protocol compliance assertions above.