chore: share game-studio hermes plugin

.hermes/plugins/game-studio/skills/game-studio/SKILL.md

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

.hermes/plugins/game-studio/skills/game-studio/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Game Studio"
+  short_description: "Route browser-game work to the right path"
+  default_prompt: "Help me choose the right browser-game stack and workflow before implementation starts."