Update docs, skill counts, and UX/setup-engine skills for v0.4.0

- Update skill count to 66 and hook count to 12 across README, skills-reference, and badges
- Add QA & Testing section to README and skills-reference (qa-plan, smoke-check, soak-test, etc.)
- Add Input & Platform section to technical-preferences.md (populated by /setup-engine)
- Document post-compact, notify, and validate-skill-change hooks in hooks-reference
- Expand /setup-engine, /ux-design, /ux-review, /design-system skills with input/platform context
- Restructure workflow-catalog: move UX steps into pre-production phase, improve descriptions
- Expand UPGRADING.md and WORKFLOW-GUIDE.md with v0.4.0 guidance
- Add skill-flow-diagrams examples and CODEOWNERS

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

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

@@ -457,6 +457,16 @@ For **Visual/Audio**: Coordinate with `art-director` and `audio-director` if det
 is needed. Often a brief note suffices at the GDD stage.
 
 For **UI Requirements**: Coordinate with `ux-designer` for complex UI systems.
+After writing this section, check whether it contains real content (not just
+`[To be designed]` or a note that this system has no UI). If it does have real
+UI requirements, output this flag immediately:
+
+> **📌 UX Flag — [System Name]**: This system has UI requirements. In Phase 4
+> (Pre-Production), run `/ux-design` to create a UX spec for each screen or
+> HUD element this system contributes to **before** writing epics. Stories that
+> reference UI should cite `design/ux/[screen].md`, not the GDD directly.
+>
+> Note this in the systems index for this system if you update it.
 
 For **Open Questions**: Capture anything that came up during design that wasn't
 fully resolved. Each question should have an owner and target resolution date.

.claude/skills/setup-engine/SKILL.md

@@ -35,9 +35,10 @@ If no engine is specified, run an interactive engine selection process:
 ### If the user wants to pick without a concept, ask:
 1. **What kind of game?** (2D, 3D, or both?)
 2. **What platforms?** (PC, mobile, console, web?)
-3. **Team size and experience?** (solo beginner, solo experienced, small team?)
-4. **Any strong language preferences?** (GDScript, C#, C++, visual scripting?)
-5. **Budget for engine licensing?** (free only, or commercial licenses OK?)
+3. **Primary input method?** (keyboard/mouse, gamepad, touch, or mixed?)
+4. **Team size and experience?** (solo beginner, solo experienced, small team?)
+5. **Any strong language preferences?** (GDScript, C#, C++, visual scripting?)
+6. **Budget for engine licensing?** (free only, or commercial licenses OK?)
 
 ### Produce a recommendation
 
@@ -135,6 +136,39 @@ engine-appropriate defaults. Read the existing template first, then fill in:
 - Booleans: `b` prefix (e.g., `bIsAlive`)
 - Files: Match class without prefix (e.g., `PlayerController.h`)
 
+### Input & Platform Section
+
+Populate `## Input & Platform` using the answers gathered in Section 2 (or extracted
+from the game concept). Derive the values using this mapping:
+
+| Platform target | Gamepad Support | Touch Support |
+|-----------------|-----------------|---------------|
+| PC only | Partial (recommended) | None |
+| Console | Full | None |
+| Mobile | None | Full |
+| PC + Console | Full | None |
+| PC + Mobile | Partial | Full |
+| Web | Partial | Partial |
+
+For **Primary Input**, use the dominant input for the game genre:
+- Action/RPG/platformer targeting console → Gamepad
+- Strategy/point-and-click/RTS → Keyboard/Mouse
+- Mobile game → Touch
+- Cross-platform → ask the user
+
+Present the derived values and ask the user to confirm or adjust before writing.
+
+Example filled section:
+```markdown
+## Input & Platform
+- **Target Platforms**: PC, Console
+- **Input Methods**: Keyboard/Mouse, Gamepad
+- **Primary Input**: Gamepad
+- **Gamepad Support**: Full
+- **Touch Support**: None
+- **Platform Notes**: All UI must support d-pad navigation. No hover-only interactions.
+```
+
 ### Remaining Sections
 - Performance Budgets: Leave as `[TO BE CONFIGURED]` with a suggestion:
   > "Typical targets: 60fps / 16.6ms frame budget. Want to set these now?"

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

@@ -90,7 +90,28 @@ already made.
 Check for `design/accessibility-requirements.md`. If found, read it. The spec
 must satisfy the accessibility tier committed to there.
 
-### 2h: Present Context Summary
+### 2h: Input Method (from Project Config)
+
+Read `.claude/docs/technical-preferences.md` and extract the `## Input & Platform`
+section. Store these values for use throughout the skill — they drive the
+Interaction Map and inform accessibility requirements:
+
+- **Input Methods** — e.g., Keyboard/Mouse, Gamepad, Touch, Mixed
+- **Primary Input** — the dominant input for this game
+- **Gamepad Support** — Full / Partial / None
+- **Touch Support** — Full / Partial / None
+- **Target Platforms** — for safe zone and aspect ratio decisions
+
+If the section is unconfigured (`[TO BE CONFIGURED]`), ask once:
+> "Input methods aren't configured yet. What does this game target?"
+> Options: "Keyboard/Mouse only", "Gamepad only", "Both (PC + Console)", "Touch (mobile)", "All of the above"
+>
+> (Run `/setup-engine` to save this permanently so you won't be asked again.)
+
+Store the answer for the rest of this session. Do **not** ask again per section
+or per screen.
+
+### 2i: Present Context Summary
 
 Before any design work, present a brief summary to the user:
 
@@ -101,6 +122,7 @@ Before any design work, present a brief summary to the user:
 > - Related screens already specced: [list, or "none yet"]
 > - Known patterns available: [count, or "no pattern library yet"]
 > - Accessibility tier: [from requirements doc, or "not yet defined"]
+> - Input methods: [from technical-preferences.md, or "asked above"]
 
 Then ask: "Anything else I should read before we start, or shall we proceed?"
 
@@ -427,8 +449,9 @@ For each interactive component identified in the Layout Specification, define:
 - The immediate feedback (visual, audio, haptic)
 - The outcome (navigation target, state change, data write)
 
-Ask up front: "Which input methods does this game target? I'll tailor the
-interaction map to those." Reference game concept for platform targets.
+Use the input methods loaded from `technical-preferences.md` in Phase 2h — do
+not ask the user again. State them upfront: "Mapping interactions for:
+[Input Methods from tech-prefs]. Covering [Gamepad Support] gamepad support."
 
 Work through components one at a time rather than asking for all at once.
 For navigation actions (going to another screen), verify the target matches

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

@@ -47,12 +47,16 @@ full detail for each.
 
 Before validating any spec, load:
 
-1. The accessibility tier committed to in `design/accessibility-requirements.md`
+1. **Input & Platform config**: Read `.claude/docs/technical-preferences.md` and
+   extract `## Input & Platform`. This is the authoritative source for which input
+   methods the game supports — use it to drive the Input Method Coverage checks in
+   Phase 3A, not the spec's own header. If unconfigured, fall back to the spec header.
+2. The accessibility tier committed to in `design/accessibility-requirements.md`
    (if it exists)
-2. The interaction pattern library at `design/ux/interaction-patterns.md` (if
+3. The interaction pattern library at `design/ux/interaction-patterns.md` (if
    it exists)
-3. The GDDs referenced in the spec's header (read their UI Requirements sections)
-4. The player journey map at `design/player-journey.md` (if it exists) for
+4. The GDDs referenced in the spec's header (read their UI Requirements sections)
+5. The player journey map at `design/player-journey.md` (if it exists) for
    context-arrival validation
 
 ---