## Summary Add a first-class Phaser 3 engine specialist (agent, behavioral spec, version reference, index updates) to fill the gap between the existing Godot, Unity, and Unreal engine specialists. ## Type - [x] New agent - [ ] New skill (slash command) - [ ] New hook - [ ] New rule - [ ] New template - [ ] Improvement to existing component - [x] Other: behavioral spec + engine-reference VERSION.md + `agent-roster.md` and `catalog.yaml` updates (the standard "engine specialist" bundle, matching how godot / unity / unreal are shipped) ## Problem / Motivation I've shipped two production Phaser 3 + TypeScript + Vite games using CCGS: one single-player (Phaser 3.88, web + mobile via Capacitor) and one PvP lockstep multiplayer (Phaser 3.90, web). CCGS ships engine specialists for Godot, Unity, and Unreal — Phaser has zero coverage. Both projects had to derive the same Phaser patterns locally: scene lifecycle conventions, custom GameObject factory registration, `core/` vs `scenes/` separation for testability and lockstep determinism, build/tooling stack, etc. A first-party Phaser specialist closes that gap and lets web-game projects benefit from the same engine-aware guidance Godot, Unity, and Unreal projects already get — version pinning, post-cutoff API risk flagging, idiomatic pattern enforcement. ## Proposed Solution A minimum-viable PR with five files, mirroring how the existing engine specialists are shipped: 1. **`.claude/agents/phaser-specialist.md`** — runtime agent. - Domain: Phaser 3 architecture (scene lifecycle, GameObjects, EventEmitter, asset loader, tweens, physics). - Tier: engine specialist (sibling of `godot-specialist`, `unity-specialist`, `unreal-specialist`). - Model: Sonnet. - Tools: `Read, Glob, Grep, Write, Edit, Bash, Task` (matches the other engine specialists). - Canonical body structure: Collaboration Protocol → Core Responsibilities → Phaser Best Practices to Enforce → Delegation Map → MUST NOT Do → Version Awareness → When Consulted. - No sub-specialists in v1. Routing of `.ts` source, shaders, and audio defers explicitly to `gameplay-programmer`, `technical-artist`, and `sound-designer`. 2. **`CCGS Skill Testing Framework/agents/engine/phaser/phaser-specialist.md`** — behavioral spec with the standard 5 test cases (in-domain request, wrong-engine redirect, post-cutoff API risk, deference decision, version context pass). 3. **`CCGS Skill Testing Framework/catalog.yaml`** — append a Phaser block under `agents` (mirroring the godot / unity / unreal blocks). 4. **`.claude/docs/agent-roster.md`** — append a row to the "Engine Leads" table. 5. **`docs/engine-reference/phaser/VERSION.md`** — pinned to Phaser 3.90, mirroring `docs/engine-reference/godot/VERSION.md`. Knowledge corpus the specialist would cover: scene lifecycle and one-scene-per-screen architecture; custom GameObjects via `Phaser.GameObjects.GameObjectFactory` registration; `core/` vs `scenes/` separation for testability and lockstep determinism; seedable PRNG and the `Math.random()` / `Date.now()` ban inside `core/`; Vite + TypeScript strict + Vitest tooling; Capacitor wrap for web → Android + iOS; `localStorage` retry queue for flaky-network writes; lightweight anti-tamper (XOR cipher + score signature) for static-asset web games; performance budgets for typical 2D web targets. ## Alternatives Considered 1. **A broader `web-game-specialist` covering multiple web engines** (PixiJS, Babylon, Three.js, Phaser as sibling). Rejected for v1 because the ground truth I have only validates Phaser — a multi-engine surface would either over-generalize without evidence or under-deliver on the one engine I can validate. A `web-game-specialist` can be added later as a sibling. 2. **Ship as a separate `ccgs-phaser-extensions` repo under my account.** Loses the first-party stamp and forces users to install both. Tabled as a fallback if this proposal is out of scope. 3. **Ship only the runtime agent without the behavioral spec, version reference, and index updates.** Rejected because the existing engine specialists are paired with all four — a partial ship would diverge from the project's own conventions. ## Additional Context **Optional follow-ups (happy to split into separate PRs if preferred):** - `.claude/docs/templates/phaser-game-scaffold/` — Vite + TS + Vitest + Phaser starter with a minimal sample scene and CI workflow. - Expansion of `docs/engine-reference/phaser/` with `breaking-changes.md`, `deprecated-apis.md`, `current-best-practices.md`, and per-domain module docs. - `.claude/skills/setup-engine/SKILL.md` — surface Phaser as a fourth engine option in the setup prompts. **Constraints I'm following:** All artifacts in English. No project-specific content from the source projects (per `CONTRIBUTING.md`: *"CCGS is the system that helps you build games, not a place to store the games you build with it"*). Conventional Commits. Windows Git Bash tested. Collaborative principle respected (no auto-writes). **Three questions before I draft:** 1. Anything in the v1 list out of bounds for the framework's direction (e.g. concerns about adding a 2D-web engine specialist)? 2. Prefer one bundled PR for the five v1 files, or should the engine-reference doc and the catalog / roster updates split into separate PRs? 3. Any in-flight Phaser or web-game work I should coordinate with? Happy to share sanitized example outputs from the source projects to validate the patterns generalize. Will wait for scope ack before drafting the PR.
