Update to Game Studio

{
  "description": "Route early browser-game work. Use when the user needs stack selection and workflow planning across design, implementation, assets, and playtesting before moving to a specialist skill.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 213
    }
  ],
  "name": "game-studio",
  "skill_md_contents": "---\nname: game-studio\ndescription: Route early browser-game work. Use when the user needs stack selection and workflow planning across design, implementation, assets, and playtesting before moving to a specialist skill.\n---\n\n# Game Studio\n\n## Overview\n\nUse this skill as the umbrella entrypoint for browser-game work. Default to a 2D Phaser path unless the user explicitly asks for 3D, Three.js, React Three Fiber, shader-heavy rendering, or another WebGL-first direction.\n\nThis plugin is intentionally asymmetric:\n\n- 2D is the strongest execution path in v1.\n- 3D has one opinionated default ecosystem: vanilla Three.js for plain TypeScript or Vite apps, React Three Fiber for React-hosted 3D apps, and GLB or glTF 2.0 as the default shipping asset format.\n- Shared architecture, UI, and playtest practices apply to both.\n\n## Use This Skill When\n\n- the user is still choosing a stack\n- the request spans multiple domains such as runtime, UI, asset pipeline, and QA\n- the user says \"help me build a game\" without naming the implementation path\n\n## Do Not Stay Here When\n\n- the runtime is clearly plain Three.js\n- the runtime is clearly React Three Fiber\n- the task is clearly a shipped-asset problem\n- the task is clearly frontend-only or QA-only\n\nOnce the intent is clear, route to the most specific specialist skill and continue from there.\n\n## Routing Rules\n\n1. Classify the request before designing or coding:\n   - `2D default`: Phaser, sprites, tilemaps, top-down, side-view, grid tactics, action platformers.\n   - `3D + plain TS/Vite`: imperative scene control, engine-like loops, non-React apps, direct Three.js work.\n   - `3D + React`: React-hosted product surfaces, declarative scene composition, shared React state, UI-heavy 3D apps.\n   - `3D asset pipeline`: GLB, glTF, texture packaging, compression, LOD, runtime asset size.\n   - `Alternative engine`: Babylon.js or PlayCanvas requests, usually as comparison or ecosystem fit questions.\n   - `Shared`: core loop design, frontend direction, save/debug/perf boundaries, browser QA.\n2. Route to the specialist skills immediately after classification:\n   - Shared architecture and engine choice: `../web-game-foundations/SKILL.md`\n   - Deep 2D implementation: `../phaser-2d-game/SKILL.md`\n   - Vanilla Three.js implementation: `../three-webgl-game/SKILL.md`\n   - React-hosted 3D implementation: `../react-three-fiber-game/SKILL.md`\n   - 3D asset shipping and optimization: `../web-3d-asset-pipeline/SKILL.md`\n   - HUD and menu direction: `../game-ui-frontend/SKILL.md`\n   - 2D sprite generation and normalization: `../sprite-pipeline/SKILL.md`\n   - Browser QA and visual review: `../game-playtest/SKILL.md`\n3. Keep one coherent plan across the routed skills. Do not let engine, UI, asset, and QA decisions drift apart.\n\n## Default Workflow\n\n1. Lock the game fantasy and player verbs.\n2. Define the core loop, failure states, progression, and target play session length.\n3. Choose the implementation track:\n   - Default to Phaser for 2D browser games.\n   - Choose vanilla Three.js when the project is explicitly 3D and wants direct render-loop control in a plain TypeScript or Vite app.\n   - Choose React Three Fiber when the project already lives in React or wants declarative scene composition with shared React state.\n   - Choose raw WebGL only when the user explicitly wants a custom renderer or shader-first surface.\n4. Define the UI surface early. Browser games usually need a DOM HUD and menu layer even when the playfield is canvas or WebGL.\n   - For 3D starter scaffolds, default to a low-chrome HUD that preserves the playfield and keeps secondary panels collapsed.\n5. Decide the asset workflow:\n   - 2D characters and effects: use `sprite-pipeline`.\n   - 3D models, textures, and shipping format: use `web-3d-asset-pipeline`.\n6. Close with a playtest loop before calling the work production-ready.\n\n## Output Expectations\n\n- For planning requests, return a game-specific plan with stack choice, gameplay loop, UI surface, asset workflow, and test approach.\n- For implementation requests, keep the chosen stack obvious in the file structure and code boundaries.\n- For mixed requests, preserve the plugin default: 2D Phaser first unless the user asks for something else.\n- When the user asks about Babylon.js or PlayCanvas, compare them honestly but keep Three.js and R3F as the primary code-generation defaults unless the user explicitly chooses another engine.\n\n## References\n\n- Engine selection: `../../references/engine-selection.md`\n- Three.js stack: `../../references/threejs-stack.md`\n- React Three Fiber stack: `../../references/react-three-fiber-stack.md`\n- 3D asset pipeline: `../../references/web-3d-asset-pipeline.md`\n- Vanilla Three.js starter: `../../references/threejs-vanilla-starter.md`\n- React Three Fiber starter: `../../references/react-three-fiber-starter.md`\n- Frontend prompting patterns: `../../references/frontend-prompts.md`\n- Playtest checklist: `../../references/playtest-checklist.md`\n\n## Examples\n\n- \"Help me prototype a browser tactics game.\"\n- \"I need a Phaser-based action game loop with a HUD and menus.\"\n- \"I want a Three.js exploration demo with WebGL lighting and browser-safe UI.\"\n- \"I want a React-based 3D configurator with React Three Fiber.\"\n- \"Optimize my GLB assets for the web and keep the file sizes under control.\"\n- \"Set up the asset workflow for consistent 2D sprite animations.\"\n"
}