chore(skills): add runtime smoke test to pr-push and pr-review

Sprint 28 lesson: 3 review rounds without launching the game missed
critical bugs. Now enforced:
- pr-push: mandatory headless smoke test before pushing, visual
  verification question for UI changes
- pr-review: parse check before spawning reviewers, process gap flag
  if runtime testing wasn't performed
- Araminta: check Poly Haven + Quaternius before creating assets

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

.claude/agents/araminta.md

@@ -37,6 +37,14 @@ Named after Araminta from the Void Trilogy - practical, good aesthetic instincts
 - **Consistency compounds**: small rules applied everywhere create coherence. One accent color for danger, one for opportunity, one for unknown.
 - **Scale gracefully**: every visual decision should work at boxes-with-labels AND at full-art fidelity. Don't paint yourself into a corner.
 
+## Asset sourcing — check before creating
+
+Before authoring or generating any 3D asset, check these CC0 sources first:
+- **Poly Haven** (https://polyhaven.com) — models, textures, and HDRIs. Thousands of CC0 props, furniture, materials. Download GLTF, run through our toon shader pipeline.
+- **Quaternius** (https://quaternius.com) — CC0 low-poly game assets. Character system already uses their rigs and outfits.
+
+PBR assets from these sources go through our `toon_masked` shader and come out matching the game's aesthetic. Don't author from scratch what's available for free.
+
 ## Asset generation capability
 
 You have access to the `/asset-gen` skill which uses the `generate_image` MCP tool (powered by Nano Banana / Gemini 2.5 Flash Image generation). This tool can generate:

.claude/skills/pr-push/SKILL.md

@@ -34,6 +34,34 @@ git branch --show-current
 
 If on `main`, stop: "You're on main. Switch to a team branch first."
 
+### 1b. Runtime smoke test (MANDATORY)
+
+Before pushing, verify the game actually runs. This is non-negotiable —
+Sprint 28 proved that code review without runtime testing misses critical
+bugs (parse errors, depth sorting, scene tree failures).
+
+**For client/visual branches:**
+```bash
+# Headless parse check
+godot --headless --path client --quit 2>&1 | grep -i "SCRIPT ERROR"
+
+# If the branch has UI changes, also run the game briefly:
+timeout 10 godot --path client res://scenes/main_menu.tscn 2>&1 | grep -i "ERROR\|SCRIPT ERROR"
+```
+
+**For server branches:**
+```bash
+cd server && cargo test --lib 2>&1
+```
+
+If any errors are found, **stop and fix them before pushing**. Do not
+push broken code for reviewers to find — that wastes everyone's time.
+
+If the branch includes visual changes (character creation, UI, rendering),
+the team should have manually launched the game and verified the change
+works on screen before invoking `/pr-push`. If they haven't, ask:
+"Have you run `make game` and verified this works visually?"
+
 ### 2. Commit uncommitted changes
 
 ```bash

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

@@ -28,6 +28,26 @@ Do NOT proceed with the review. Do NOT work around this by reading files
 from another worktree — the review agent itself must be running in main.
 Stop and wait for the user to invoke `/pr-review` from main.
 
+### 0b. Verify runtime smoke test was performed
+
+Before spawning reviewers, check that the pushing team performed basic
+runtime verification. This was the #1 process failure of Sprint 28 —
+3 review rounds without anyone launching the game missed critical bugs.
+
+Ask: "Did the team run `make game` or a headless smoke test before
+pushing this PR?"
+
+If the PR description or commit messages don't mention runtime testing,
+note this in the review output as a process gap. Reviewers should still
+proceed (the PR exists and needs reviewing) but the gap should be visible.
+
+For **client/visual branches**, run a quick headless parse check from main:
+```bash
+godot --headless --path client --quit 2>&1 | grep -i "SCRIPT ERROR"
+```
+If script errors appear in the branch diff files, flag them immediately
+before spawning reviewers — no point reviewing code that doesn't parse.
+
 ### 1. Determine the branch to review
 
 If the user provided a branch name as argument, use it. Otherwise list open