/game-dev

name: game-dev
description: "Game development: design, asset pipelines, Phaser, vanilla JS frontend, GM mode, match booking."
agent: project-coordinator-engineer
user-invocable: true
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash
  - Grep
  - Glob
  - Task
  - Skill
routing:
  force_route: true
  not_for: "non-game frontend (use frontend), non-game backend (use workflow)"
  triggers:
    - game design
    - game design audit
    - game improvement
    - core loop
    - game feel
    - game balance
    - game economy
    - make game
    - game pipeline
    - game audio
    - deploy game
    - phaser
    - 2d game
    - platformer
    - arcade physics
    - tilemap
    - AI sprite
    - generate sprite
    - spritesheet pipeline
    - animated spritesheet
    - large GM implementation
    - GM systems overhaul
    - pixel art
    - screen shake
    - game qa
  pairs_with:
    - frontend
    - workflow
  complexity: Comprehensive
  category: game-development

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

| Mode | Signals | |------|---------| | **Design** | game design, improve game, retention, churn, core loop, audit, game feel, balance, economy | | **Pipeline** | make game, scaffold, game lifecycle, game audio, deploy game, game QA | | **Sprite** | AI sprite, generate character, portrait, spritesheet, animated sheet, pixel art | | **Phaser** | Phaser, 2D game, platformer, arcade physics, tilemap, side scroller | | **GM** | large GM implementation, multi-system GM, CPU systems, multi-wave overhaul |

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

1. **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. 2. **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)? 3. **Load references.** Route greedily -- load every module that could change the recommendation:

| Signal | Load | |--------|------| | Promise, fantasy, loops, goals | `references/core-loop-and-pillars.md` | | Ideation, novelty, removal, reuse | `references/creative-and-options.md` | | Player motives, personas, values | `references/player-and-social.md` | | Information, bias, randomness | `references/cognition-and-choice.md` | | Failure, difficulty, fairness | `references/fairness-and-failure.md` | | FTUE, flow, friction, session | `references/pacing-and-return.md` | | Co-op, competition, social | `references/social-and-competitive.md` | | Rewards, currencies, passes | `references/progression-and-economy.md` | | Pitch, mood, prototype | `references/emotion-and-presentation.md` | | Scope, sequence, estimates | `references/planning-and-production.md` | | Full health report | All modules + `references/full-diagnostic.md` |

4. **Diagnose.** Trace the player path: cue -> interpretation -> choice -> response -> cost/reward -> feedback -> next intention. State player consequence, evidence, competing explanations, confidence, severity. 5. **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. 6. **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

| Request | Entry Phase | |---------|-------------| | make a game, new game | SCAFFOLD | | generate assets, add sprites | ASSETS | | add juice, particles, screen shake | DESIGN | | add audio, background music | AUDIO | | test game, visual regression | QA | | deploy, ship, publish, iOS | DEPLOY |

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:

| Asset | Reference | |-------|-----------| | 3D model, GLB, mesh | `references/game-asset-generator.md` + `references/meshyai.md` | | Sprite, pixel art, tile | Load Sprite mode below | | Image, texture, concept art | `references/fal-ai-image.md` | | Environment, gaussian splat | `references/worldlabs.md` | | Free assets, Sketchfab | `references/asset-sources.md` | | Motion data, BVH, mocap | `references/motion-pipeline.md` |

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,