Gap closure: feedback loops, traceability, and new /content-audit skill

- NEW /content-audit skill: GDD-specified content vs implemented content gap
  report with COMPLETE/IN PROGRESS/EARLY/NOT STARTED per system
- balance-check: Fix & Verify Cycle phase (fix → re-verify → propagate-design-change)
- perf-profile: Scope & Timeline Decision phase for M/L effort optimizations
- playtest-report: Action Routing phase categorizes findings → design/balance/bugs/polish
- review-all-gdds: Phase 4 Cross-System Scenario Walkthrough (multi-system sequences)
- story-done: Test-Criterion Traceability (each AC mapped to a test, BLOCKING if >50% untested)
- code-review: ADR Compliance Check (ARCHITECTURAL VIOLATION / ADR DRIFT / MINOR DEVIATION)
- setup-engine: upgrade subcommand (pre-upgrade API scan, migration plan, VERSION.md update)
- story-readiness: Asset References Check (verifies referenced asset paths exist)
- validate-assets.sh: invalid JSON now exits 1 (blocking); naming issues exit 0 (warning)
- workflow-catalog.yaml + sprint-plan: /scope-check wired into production phase

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

.claude/skills/code-review/SKILL.md

@@ -14,10 +14,43 @@ When this skill is invoked:
 
 2. **Read the CLAUDE.md** for project coding standards.
 
-3. **Identify the system category** (engine, gameplay, AI, networking, UI, tools)
+3. **ADR Compliance Check**:
+
+   a. Search for ADR references in: the story file associated with this work (if
+      provided), any commit message context, and header comments in the files being
+      reviewed. Look for patterns like `ADR-NNN`, `ADR-[name]`, or
+      `docs/architecture/ADR-`.
+
+   b. If no ADR references are found, note:
+      > "No ADR references found — skipping ADR compliance check."
+      Then proceed to step 4.
+
+   c. For each referenced ADR: read `docs/architecture/ADR-NNN-*.md` and extract
+      the **Decision** and **Consequences** sections.
+
+   d. Check the implementation against each ADR:
+      - What pattern/approach was chosen in the Decision?
+      - Are there alternatives explicitly rejected in the ADR?
+      - Are there required guardrails or constraints in the Consequences?
+
+   e. Classify any deviation found:
+      - **ARCHITECTURAL VIOLATION** (BLOCKING): Implementation uses a pattern
+        explicitly rejected in the ADR (e.g., ADR rejected singletons for game
+        state, but the code uses a singleton).
+      - **ADR DRIFT** (WARNING): Implementation diverges meaningfully from the
+        chosen approach without using an explicitly forbidden pattern (e.g., ADR
+        chose event-based communication but code uses direct method calls).
+      - **MINOR DEVIATION** (INFO): Small difference from ADR guidance that does
+        not affect the overall architecture (e.g., slightly different naming from
+        the ADR's example code).
+
+   f. Include ADR compliance findings in the review output under
+      `### ADR Compliance` before the Standards Compliance section.
+
+4. **Identify the system category** (engine, gameplay, AI, networking, UI, tools)
    and apply category-specific standards.
 
-4. **Evaluate against coding standards**:
+5. **Evaluate against coding standards**:
    - [ ] Public methods and classes have doc comments
    - [ ] Cyclomatic complexity under 10 per method
    - [ ] No method exceeds 40 lines (excluding data declarations)
@@ -25,32 +58,35 @@ When this skill is invoked:
    - [ ] Configuration values loaded from data files
    - [ ] Systems expose interfaces (not concrete class dependencies)
 
-5. **Check architectural compliance**:
+6. **Check architectural compliance**:
    - [ ] Correct dependency direction (engine <- gameplay, not reverse)
    - [ ] No circular dependencies between modules
    - [ ] Proper layer separation (UI does not own game state)
    - [ ] Events/signals used for cross-system communication
    - [ ] Consistent with established patterns in the codebase
 
-6. **Check SOLID compliance**:
+7. **Check SOLID compliance**:
    - [ ] Single Responsibility: Each class has one reason to change
    - [ ] Open/Closed: Extendable without modification
    - [ ] Liskov Substitution: Subtypes substitutable for base types
    - [ ] Interface Segregation: No fat interfaces
    - [ ] Dependency Inversion: Depends on abstractions, not concretions
 
-7. **Check for common game development issues**:
+8. **Check for common game development issues**:
    - [ ] Frame-rate independence (delta time usage)
    - [ ] No allocations in hot paths (update loops)
    - [ ] Proper null/empty state handling
    - [ ] Thread safety where required
    - [ ] Resource cleanup (no leaks)
 
-8. **Output the review** in this format:
+9. **Output the review** in this format:
 
 ```
 ## Code Review: [File/System Name]
 
+### ADR Compliance: [NO ADRS FOUND / COMPLIANT / DRIFT / VIOLATION]
+[List each ADR checked, result, and any deviations with severity]
+
 ### Standards Compliance: [X/6 passing]
 [List failures with line references]
 
@@ -67,7 +103,7 @@ When this skill is invoked:
 [What is done well -- always include this section]
 
 ### Required Changes
-[Must-fix items before approval]
+[Must-fix items before approval — ARCHITECTURAL VIOLATIONs always appear here]
 
 ### Suggestions
 [Nice-to-have improvements]