game-review

name	game-review
description	Audits existing game code against design principles — checks server-authority, schema conventions, auth security, payment safety, narrative coherence, and MVP scope drift. Extract the optional component name or path from the user's message (defaults to entire src/). Use after building components or before committing.

Game Review — Code Auditor

Prerequisites

• Apply relevant engineering and design skills based on the detected code domains (see Phase 0)

---

Phase 0 — Context Load (silent)

1. READ docs/mvp-first-draft.md if it exists (provides architectural intent for comparison)
2. READ docs/build-registry.md if it exists (tracks what's built vs mocked)
3. Determine scope from the user's message:
   • If a component name or path was provided: focus on src/[component]/ or the specified path
   • If nothing provided: review all of src/
4. Scan the target scope to identify which technology domains are present (auth, payments, WebSocket, Redis, BullMQ, quests, etc.)
5. Apply only the skills relevant to the detected domains:
   • Auth detected → Apply the betterauth-integration skill
   • Payments/Stripe detected → Apply the stripe-game-payments skill
   • WebSocket/game state detected → Apply the game-state-sync skill
   • Redis detected → Apply the redis-game-patterns skill
   • BullMQ detected → Apply the bullmq-game-queues skill
   • Quest/narrative code detected → Apply the quest-narrative-coherence skill
   • Database/Drizzle detected → Apply the postgres-game-schema skill
   • Matchmaking detected → Apply the matchmaking-system skill
   • Analytics detected → Apply the gameplay-analytics skill

Phase 1 — Engineering Review

Read all TypeScript files in the target scope. Apply these checks. For every finding, record: severity, file path, line number (approximate), description, fix suggestion, and the skill it violates.

State Authority (multiplayer/WebSocket code)

• 🔴 CRITICAL: Any WebSocket handler that trusts message.userId or message.playerId from the client — must derive identity from server session
• 🔴 CRITICAL: Any game state mutation triggered directly by client message without server validation
• 🟡 WARNING: Game loop tick rate over 60Hz without justification

Database / Schema

• 🔴 CRITICAL: Raw SQL template literals (sql\SELECT...`) outside of Drizzle's sql` tagged helper — must use Drizzle typed query builder
• 🟡 WARNING: Missing deletedAt soft-delete column on player-facing tables (players, inventory, characters)
• 🟡 WARNING: Hardcoded column names for game-specific attributes that should be in JSONB (e.g., manaPoints, fireResistance as top-level columns)
• 🟢 SUGGESTION: Indexes missing on (playerId, type) composite for event/log tables

Auth & Sessions

• 🔴 CRITICAL: Any endpoint reading req.body.userId or req.query.userId to identify the actor — must use auth.api.getSession() and derive from session
• 🔴 CRITICAL: JWT verification without checking expiry
• 🟡 WARNING: No rate limiting on /auth/login or /auth/signup routes
• 🟡 WARNING: Admin/moderator role stored in a cookie or JWT claim (must be fetched from DB on each request)

Payments (Stripe)

• 🔴 CRITICAL: Any purchase fulfillment triggered on checkout success redirect (GET /success) — must be webhook-driven
• 🔴 CRITICAL: Webhook handler that doesn't call stripe.webhooks.constructEvent() to verify the signature
• 🔴 CRITICAL: Stripe secret key referenced in client-side code (any file in public/, client/, frontend/)
• 🟡 WARNING: Missing idempotency check for checkout.session.completed events — could double-grant rewards on webhook replay

Job Queues (BullMQ)

• 🟡 WARNING: BullMQ processor with no attempts config — all jobs should have retry policy
• 🟡 WARNING: BullMQ processor with no backoff config — should use exponential backoff
• 🟢 SUGGESTION: Consider adding removeOnComplete and removeOnFail options to prevent queue bloat

Redis

• 🟡 WARNING: Redis keys that don't follow {entity}:{id}:{field} naming convention
• 🟡 WARNING: Session keys stored in Redis without EXPIRE — ephemeral state must have TTL
• 🟢 SUGGESTION: Leaderboard sorted sets should use ZADD NX or GT to only update when score improves

General Security

• 🔴 CRITICAL: Any .env values or secrets hardcoded in source files
• 🔴 CRITICAL: eval() or Function() constructor called with user input
• 🟡 WARNING: Missing input validation on API endpoints that accept user-controlled data

Phase 2 — Narrative Coherence Check

If docs/world-lore.md and docs/quest-registry.md both don't exist, output: 📋 Narrative coherence check: skipped (docs/quest-registry.md not found — run the game-quest skill to create it) Then skip to Phase 3.

If either file exists:

1. Read docs/world-lore.md and docs/quest-registry.md
2. Scan source files for quest IDs, character names, faction names, location names
3. Check: do any hardcoded quest/character/faction/location strings in code contradict what's registered in the world lore?
4. Flag: ⚠️ LORE CONFLICT: Character "Mira" referenced in src/quests/main.ts but not registered in quest-registry.md

Phase 3 — MVP Scope Drift Check

If docs/mvp-first-draft.md doesn't exist, output: 📋 Scope audit: skipped (docs/mvp-first-draft.md not found — run the game-architect skill first) Then skip to Phase 4.

1. Read Section 10 (Out of Scope) from docs/mvp-first-draft.md
2. Scan src/ for implementations of explicitly deferred features
3. Flag: ⚠️ SCOPE DRIFT: [feature] found in [file] but listed as out-of-scope in MVP plan Section 10

Also check docs/build-registry.md for components marked "built" that don't appear in the MVP build sequence (Section 9) — these may be gold-plating.

Phase 4 — Report Output

Output a structured review report:

# Game Review Report
Scope: [path reviewed]
Generated: [timestamp]

## Summary
🔴 Critical: X | 🟡 Warning: Y | 🟢 Suggestion: Z

Then list all findings grouped by category (Engineering, Narrative, Scope). For each finding:

### [🔴/🟡/🟢] [Title]
**File:** `src/path/to/file.ts` (line ~42)
**Issue:** [what's wrong]
**Fix:** [concrete fix description]
**Skill ref:** [→ stripe-game-payments: webhook-first fulfillment]

End with:

## Next Steps
- Fix all 🔴 CRITICAL issues before committing
- Review the [top-violation-category] skill for correct patterns
- Run the game-build skill to rebuild any component with critical violations

If no issues found in a category, output:

### ✅ [Category] — No issues found

---

Hard Constraints

1. Never modify code — this is a read-only audit command. Output findings only.
2. Never report false positives — if a pattern looks like a violation but context makes it acceptable, skip it or downgrade to 🟢
3. Always link to a skill — every finding must reference the skill that defines the correct pattern
4. Be specific — include file path and approximate line number for every finding
5. Prioritize signal — 5 real critical issues is more useful than 30 noise suggestions