Game Development
Five modes: Design (diagnosis, auditing, improvement), Pipeline (full
lifecycle orchestration), Sprite (AI sprite generation), Phaser (2D
engine builds), GM (large multi-system implementations). Cross-cutting
concerns (audio, QA, deploy) load as needed. Classify the request and follow
the matching section.
Mode Selection
If the request spans modes, load both primary references. Design + Pipeline is
common (design an improvement then implement it). Sprite + Phaser is common
(generate assets then wire into a Phaser game).
Design Mode
Evidence-led game design diagnosis with 61 runnable capabilities. Start from
repository evidence; never guess when the repo can answer.
Workflow
- Intake. Read target repository's governing files. Search for game, product, UI, analytics, and research guidance. Use file search to find design docs, player copy, rules, UI, config, tests, analytics, issues. Separate facts into: observed, documented, measured, inferred.
- Ask only what the repo cannot answer. Which player moment matters? What external evidence exists (playtests, telemetry, reviews)? Which constraints bind (platform, phase, team, time)?
- Load references. Route greedily -- load every module that could change the recommendation:
- Diagnose. Trace the player path: cue -> interpretation -> choice -> response -> cost/reward -> feedback -> next intention. State player consequence, evidence, competing explanations, confidence, severity.
- Decide. Offer 2-5 distinct options. For each: player-visible change, pillar fit, scope, dependencies, effort, reversibility, success metric, stop rule. Prefer reversible experiments. Reject dark patterns.
- Completion gate. Every finding has evidence or is marked as inference. Every recommendation has a validation plan.
Discovery Mode
When request is bare "game design" or "what reviews are available": load references/capability-catalog.md and present the full domain-organized catalog of 61 capabilities.
Autonomous Improvement
When asked to improve a game's retention, churn, or engagement: load references/autonomous-improvement.md. Inspect the real game, run relevant capabilities, make the smallest safe reversible improvement, verify, leave a measurement plan.
Pipeline Mode
Full lifecycle orchestration: SCAFFOLD -> ASSETS -> DESIGN -> AUDIO -> QA ->
DEPLOY. Each phase can be entered independently.
Entry Detection
Phase 1: SCAFFOLD
Detect engine (Three.js, Phaser, or vanilla canvas). Delegate to the appropriate engine skill or scaffold from template.
Phase 2: ASSETS
Route by asset type:
Phase 3: DESIGN
Add game feel: screen shake, particles, hit-stop, juice. Load references/game-feel-patterns.md.
Phase 4: AUDIO
Web Audio API patterns, AudioManager, AudioBridge. Load references/game-audio.md.
Phase 5: QA
Automated testing, visual regression, Playwright, canvas seams. Load references/game-qa.md.
Phase 6: DEPLOY