chore: share game-studio hermes plugin

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

@@ -0,0 +1,95 @@
+---
+name: web-game-foundations
+description: Set browser-game architecture before implementation. Use when the user needs engine choice, simulation and render boundaries, input model, asset organization, or save/debug/performance strategy.
+---
+
+# Web Game Foundations
+
+## Overview
+
+Use this skill to establish the non-negotiable architecture before implementation starts. Browser games degrade quickly when simulation, rendering, UI, asset loading, and input handling are mixed together.
+
+Default rule: simulation state is owned outside the renderer, browser UI is not forced into the canvas unless there is a clear reason, and shipped 3D assets default to GLB or glTF 2.0 rather than ad hoc model formats.
+
+## Use This Skill When
+
+- the user has not settled the engine or renderer choice
+- the task is about boundaries, module shape, state ownership, or asset policy
+- multiple specialist skills need one shared architectural frame
+
+## Do Not Stay Here When
+
+- the runtime track is clearly Phaser
+- the runtime track is clearly vanilla Three.js
+- the runtime track is clearly React Three Fiber
+- the task is purely about shipped 3D assets
+
+Once the stack is clear, hand off to the runtime or asset specialist skill.
+
+## Architecture Rules
+
+1. Separate simulation from rendering.
+   - Simulation owns entities, turns, timers, collisions, progression, and saveable state.
+   - The renderer owns scene composition, animation playback, camera, particles, and input plumbing.
+2. Keep input mapping explicit.
+   - Define actions such as `move`, `confirm`, `cancel`, `ability-1`, and `pause`.
+   - Map physical inputs to actions in one place.
+3. Treat asset loading as a first-class system.
+   - Use stable manifest keys.
+   - Group by domain: characters, environment, UI, audio, FX.
+   - For 3D content, standardize on GLB or glTF 2.0 unless the chosen engine ecosystem requires another format upstream.
+4. Define save/debug/perf boundaries up front.
+   - Save serializable simulation state, not renderer objects.
+   - Keep debug overlays and perf probes easy to toggle.
+5. Use DOM overlays for menus and HUD by default.
+   - Canvas or WebGL should handle the playfield.
+   - DOM should handle text-heavy HUD, menus, settings, and accessibility-sensitive controls.
+   - In 3D, keep the persistent UI budget small so the scene stays readable and interactive.
+6. Lock 3D runtime conventions early.
+   - Choose consistent units, origins, pivots, and naming conventions.
+   - Decide how collision proxies, LODs, and baked lighting data are authored before runtime integration starts.
+
+## Engine Selection
+
+- Default to Phaser for 2D games with sprites, tilemaps, top-down or side-view action, turn-based grids, and classic browser arcade flows.
+- Default to vanilla Three.js for explicit 3D scenes that want direct scene, camera, renderer, and loop control in plain TypeScript or Vite.
+- Default to React Three Fiber when the 3D scene lives inside a React application and needs declarative composition, shared app state, or React-first UI coordination.
+- Use raw WebGL only for shader-heavy or renderer-first projects where engine abstractions would get in the way.
+- Keep Babylon.js and PlayCanvas as alternative-engine paths rather than the default code-generation target.
+
+See `../../references/engine-selection.md` for the default decision table.
+
+## Implementation Checklist
+
+Define these before writing core code:
+
+- Player fantasy and primary verbs
+- Core loop and loss or reset states
+- Camera model
+- Input action map
+- Simulation modules
+- Renderer modules
+- Asset manifest layout
+- 3D asset format and optimization rules
+- HUD and menu surfaces
+- Save data boundary
+- Debug and perf surfaces
+
+## Anti-Patterns
+
+- Mixing gameplay rules directly into scene callbacks
+- Treating the renderer as the source of truth for game state
+- Putting all HUD and menu UI into the canvas by default
+- Letting asset filenames become the public API instead of manifest keys
+- Shipping unoptimized 3D assets straight from the DCC tool into the browser
+- Mixing camera-control state and menu or modal state without an explicit input boundary
+- Rebuilding architecture every time the game changes genre
+
+## References
+
+- Engine selection: `../../references/engine-selection.md`
+- Phaser structure: `../../references/phaser-architecture.md`
+- Three.js structure: `../../references/three-webgl-architecture.md`
+- Three.js ecosystem stack: `../../references/threejs-stack.md`
+- React Three Fiber stack: `../../references/react-three-fiber-stack.md`
+- 3D asset shipping: `../../references/web-3d-asset-pipeline.md`

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

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Web Game Foundations"
+  short_description: "Set browser-game architecture before implementation"
+  default_prompt: "Establish the core architecture for this browser game before implementation starts."