chore: share game-studio hermes plugin

.hermes/plugins/game-studio/references/alternative-3d-engines.md

@@ -0,0 +1,50 @@
+# Alternative 3D Engines
+
+This plugin defaults to Three.js and React Three Fiber for code generation. Babylon.js and PlayCanvas still matter, but they are reference-only alternatives in the current plugin shape.
+
+## Babylon.js
+
+Useful sources:
+
+- [Babylon.js home](https://babylonjs.com/)
+- [Engine specifications](https://www.babylonjs.com/specifications/)
+- [Babylon.js Editor](https://editor.babylonjs.com/)
+
+Choose Babylon.js when:
+
+- the user explicitly wants Babylon.js
+- the team wants a more engine-heavy stack with scene, material, viewer, and editor tooling built around one ecosystem
+- WebGPU, Havok, node-based rendering or material tooling, or Babylon-specific runtime features are part of the reason for the choice
+
+What Babylon.js is good at:
+
+- full-engine 3D workflows
+- strong built-in tooling and editor surfaces
+- WebGL and WebGPU support inside one ecosystem
+- integrated viewer and inspection-oriented workflows
+
+## PlayCanvas
+
+Useful sources:
+
+- [PlayCanvas graphics overview](https://developer.playcanvas.com/user-manual/graphics/)
+- [Supported formats](https://developer.playcanvas.com/user-manual/assets/supported-formats/)
+- [PlayCanvas React GLTF API](https://developer.playcanvas.com/user-manual/react/api/gltf/)
+- [PlayCanvas Web Components](https://developer.playcanvas.com/user-manual/web-components/)
+
+Choose PlayCanvas when:
+
+- the user explicitly wants PlayCanvas
+- the team prefers an editor-centric browser engine workflow
+- GLB import, runtime tooling, React bindings, or web-component-based embedding are central to the project
+
+What PlayCanvas is good at:
+
+- editor and engine working together
+- GLB-centric browser asset workflows
+- strong web embedding patterns
+- WebGL and WebGPU support with browser-focused runtime tooling
+
+## Default recommendation
+
+If the user has not already chosen Babylon.js or PlayCanvas, prefer Three.js or React Three Fiber in this plugin because they give the best balance of portability, ecosystem depth, and predictable code generation across normal browser-game repos.

.hermes/plugins/game-studio/references/engine-selection.md

@@ -0,0 +1,53 @@
+# Engine Selection
+
+Use this table to choose the default implementation path for browser games in this plugin.
+
+## Default choices
+
+- Choose Phaser for 2D games unless the user explicitly asks for another stack.
+- Choose vanilla Three.js for explicit 3D or WebGL-first experiences in plain TypeScript or Vite apps.
+- Choose React Three Fiber when the 3D scene is part of a React application and shared app state or declarative composition matters.
+- Choose raw WebGL only when engine abstractions are the problem, not because WebGL sounds more advanced.
+- Treat Babylon.js and PlayCanvas as alternative ecosystems, not the default path in this plugin.
+
+## Phaser is the best fit when
+
+- the game is sprite- or tile-based
+- the game is top-down, side-view, or grid tactics
+- you need camera, sprite, and scene primitives quickly
+- the UI will mostly live in DOM overlays
+- the game loop is gameplay-first rather than renderer-first
+
+## Three.js is the best fit when
+
+- the game is genuinely 3D
+- camera movement and depth are central to play
+- materials, lighting, or scene composition matter more than sprite tooling
+- the user explicitly asks for Three.js or WebGL-based 3D work
+- the team wants direct control over scene setup, loaders, physics integration, and the game loop
+
+## React Three Fiber is the best fit when
+
+- the project already lives in React
+- the 3D scene needs to share app state with the rest of the product
+- declarative scene composition is more valuable than a fully imperative loop
+- the team benefits from pmndrs tooling such as Drei, React Postprocessing, or `@react-three/rapier`
+
+## Babylon.js or PlayCanvas are the best fit when
+
+- the user explicitly asks for those engines
+- the team already has engine-specific tooling or editor workflows in those ecosystems
+- the project wants engine-heavy runtime features, editor-first workflows, or platform-specific tooling that Three.js does not provide by default
+
+## Raw WebGL is the best fit when
+
+- the project is shader-heavy
+- you need a custom renderer or post-processing pipeline
+- the user explicitly wants low-level rendering control
+
+## Avoid these mismatches
+
+- Do not choose a 3D stack for a normal 2D tactics or platformer game.
+- Do not choose raw WebGL for a game that mostly needs engine conveniences.
+- Do not force HUD and menus into canvas or WebGL when DOM would be clearer.
+- Do not default to Babylon.js or PlayCanvas when the user mainly wants portable TypeScript code generation across browser-game repos.

.hermes/plugins/game-studio/references/frontend-prompts.md

@@ -0,0 +1,97 @@
+# Frontend Prompts
+
+Use these prompt shapes to keep browser-game UI intentional instead of generic.
+
+## Prompt ingredients
+
+- game genre and fantasy
+- camera or viewpoint
+- player verbs
+- HUD zones
+- menu surfaces
+- motion tone
+- desktop and mobile expectations
+- playfield protection and disclosure strategy
+- anti-patterns to avoid
+
+## HUD implementation prompt
+
+```text
+Design and implement the HUD for a browser game.
+
+Game fantasy: <genre and world>
+Viewpoint: <top-down, side-view, tactical grid, third-person, first-person>
+Primary verbs: <attack, move, cast, build, dodge, inspect>
+HUD zones: <top status, bottom command bar, side objectives, modal panels>
+Tone: <ornate, rugged, clean sci-fi, painterly, arcade>
+Motion: <restrained, snappy, dramatic only on important state changes>
+Platforms: desktop and mobile
+Constraints: readable over active gameplay, DOM-based overlays, CSS variables, no generic dashboard look
+Playfield protection: keep the central play area clear during normal play, prefer one primary persistent HUD cluster, and move long-form notes or controls behind menus
+Avoid: flat admin UI, default font stack, cluttered overlays, constant micro-animation, equal-weight cards around every edge, broad always-on panels that cover the world
+```
+
+## Menu implementation prompt
+
+```text
+Build the shell UI for a browser game with the following surfaces:
+- title screen
+- pause menu
+- settings panel
+- game-over or victory screen
+
+Keep the menus visually tied to the game world, not to a SaaS app aesthetic. Use strong hierarchy, intentional typography, meaningful motion, and responsive layout.
+```
+
+## Low-chrome 3D starter prompt
+
+```text
+Design the initial playable HUD for a browser 3D game.
+
+Goal: the first screen should feel playable in under 3 seconds, not like a dashboard.
+Camera mode: <third-person, first-person, orbit, rail>
+Primary verbs: <move, inspect, interact, attack, build>
+Persistent UI budget:
+- one compact objective chip or status cluster
+- one optional small secondary surface
+- one transient controls or interaction hint
+
+Interaction rules:
+- keep the center of the playfield clear
+- keep the lower-middle playfield mostly clear during normal play
+- lore, notes, quest details, and long control lists live behind a drawer, pause menu, or toggle
+- modal and pause states must gate camera input correctly
+
+Avoid:
+- giant title cards over live gameplay
+- field notes, controls, and objectives all open at once
+- equally weighted glass panels in every corner
+- full-screen overlay chrome during normal movement
+```
+
+## 3D overlay prompt
+
+```text
+Design and implement the HUD and menu overlays for a browser 3D game.
+
+Engine context: <vanilla Three.js or React Three Fiber>
+Camera mode: <third-person, first-person, orbit, rail>
+Primary verbs: <move, inspect, interact, attack, build>
+Overlay surfaces: <reticle, quest log, inventory, pause menu, settings>
+Interaction constraints:
+- DOM overlays, not in-scene UI by default
+- modal and menu states must suspend or gate camera input correctly
+- keyboard and pointer states must be explicit
+- reduced-motion support for non-essential transitions
+- keep the center of the screen clear during normal play
+- keep the lower-middle playfield mostly clear during normal play
+- start with one compact objective surface and transient hints rather than multiple permanent cards
+- secondary content such as notes, lore, and full control references should be collapsed by default
+Avoid:
+- dashboard UI
+- cluttered full-screen overlays
+- boxed panels around every edge of the viewport
+- full-width top-and-bottom panel stacks
+- permanent text-heavy cards competing with the scene
+- camera movement continuing under active menus
+```

.hermes/plugins/game-studio/references/gltf-loading-starter.md

@@ -0,0 +1,43 @@
+# GLB Loading Starter
+
+Use this as the canonical minimal pattern for loading shipped 3D content.
+
+## Vanilla Three.js
+
+```ts
+import { GLTFLoader } from "three/examples/jsm/loaders/GLTFLoader.js";
+import { DRACOLoader } from "three/examples/jsm/loaders/DRACOLoader.js";
+
+const draco = new DRACOLoader();
+draco.setDecoderPath("/draco/");
+
+const gltfLoader = new GLTFLoader();
+gltfLoader.setDRACOLoader(draco);
+
+gltfLoader.load("/assets/hero.glb", (gltf) => {
+  const root = gltf.scene;
+  root.traverse((node) => {
+    if ("castShadow" in node) {
+      node.castShadow = true;
+      node.receiveShadow = true;
+    }
+  });
+  scene.add(root);
+});
+```
+
+## React Three Fiber
+
+```tsx
+import { useGLTF } from "@react-three/drei";
+
+function HeroModel() {
+  const gltf = useGLTF("/assets/hero.glb");
+  return <primitive object={gltf.scene} />;
+}
+```
+
+## Notes
+
+- Default shipping format is GLB or glTF 2.0.
+- Keep optimization upstream in the asset pipeline; loader code should stay boring.

.hermes/plugins/game-studio/references/phaser-architecture.md

@@ -0,0 +1,56 @@
+# Phaser Architecture
+
+This is the default 2D structure for the plugin.
+
+## Recommended module split
+
+```text
+src/
+  game/
+    simulation/
+      state.ts
+      systems/
+      rules/
+    content/
+      encounters/
+      items/
+      maps/
+    input/
+      actions.ts
+      bindings.ts
+    assets/
+      manifest.ts
+  phaser/
+    boot/
+    scenes/
+      BootScene.ts
+      MenuScene.ts
+      BattleScene.ts
+    view/
+      sprites/
+      fx/
+      camera/
+    adapters/
+      sceneBridge.ts
+  ui/
+    hud/
+    menus/
+    overlays/
+```
+
+## Responsibilities
+
+- `simulation/`: source of truth for rules and saveable state
+- `content/`: authored data and encounter configuration
+- `input/`: action map and physical control bindings
+- `assets/`: stable manifest keys and asset metadata
+- `phaser/scenes/`: scene orchestration, not game rules
+- `phaser/view/`: render and effect helpers
+- `ui/`: DOM HUD, menus, and narrative panels
+
+## Rules
+
+- Phaser scenes read from and write to the simulation through a defined bridge.
+- Game state changes should not depend on sprite or tween lifetime.
+- Camera behavior should be isolated from combat or movement rules.
+- Use DOM for dense text and settings surfaces.

.hermes/plugins/game-studio/references/playtest-checklist.md

@@ -0,0 +1,51 @@
+# Playtest Checklist
+
+Use this checklist for browser-game QA.
+
+## Universal checks
+
+- Does the game boot into a useful first state?
+- Are the main verbs obvious and responsive?
+- Does the HUD remain readable over gameplay?
+- Does the first playable screen prioritize play over dashboard chrome?
+- Does the central playfield stay mostly clear during normal play?
+- Do pause, failure, and recovery states work?
+- Does the game survive viewport changes?
+
+## 2D checks
+
+- sprite baseline consistency
+- hit, hurt, and attack timing
+- command menu focus and input state
+- tile or platform readability
+- particle or camera effects obscuring gameplay
+
+## 3D checks
+
+- camera control stability
+- camera and menu-state handoff
+- depth readability
+- persistent overlay weight versus scene readability
+- secondary notes, controls, and quest details collapsed by default
+- resize and aspect-ratio handling
+- renderer fallback or context-loss handling
+- material and lighting stability across states
+- GLB asset and texture streaming behavior
+- collision proxy alignment
+- GPU bottlenecks isolated with capture tools when needed
+
+## Browser checks
+
+- desktop and mobile viewports
+- input modality differences
+- reduced-motion behavior
+- pause behavior when focus changes
+- pointer-lock and camera-input release when overlays open
+- transient onboarding hints dismiss or fade once the player is moving
+
+## Reporting
+
+- Capture screenshots for visual findings.
+- Put findings in severity order.
+- Include reproduction steps.
+- Call out whether the likely owner is simulation, renderer, frontend, or asset pipeline.

.hermes/plugins/game-studio/references/rapier-integration-starter.md

@@ -0,0 +1,42 @@
+# Rapier Integration Starter
+
+Use this as the smallest canonical pattern for adding physics without letting it take over the whole runtime.
+
+## Vanilla Three.js
+
+```ts
+import RAPIER from "@dimforge/rapier3d-compat";
+
+await RAPIER.init();
+
+const world = new RAPIER.World({ x: 0, y: -9.81, z: 0 });
+const body = world.createRigidBody(RAPIER.RigidBodyDesc.dynamic().setTranslation(0, 2, 0));
+world.createCollider(RAPIER.ColliderDesc.cuboid(0.5, 0.5, 0.5), body);
+
+renderer.setAnimationLoop(() => {
+  world.step();
+  const p = body.translation();
+  mesh.position.set(p.x, p.y, p.z);
+  renderer.render(scene, camera);
+});
+```
+
+## React Three Fiber
+
+```tsx
+import { Physics, RigidBody } from "@react-three/rapier";
+
+<Physics gravity={[0, -9.81, 0]}>
+  <RigidBody colliders="cuboid">
+    <mesh>
+      <boxGeometry args={[1, 1, 1]} />
+      <meshStandardMaterial color="#3dd9b8" />
+    </mesh>
+  </RigidBody>
+</Physics>;
+```
+
+## Notes
+
+- Keep physics state synchronized through an explicit bridge.
+- Do not bury gameplay rules inside render or physics callbacks.

.hermes/plugins/game-studio/references/react-three-fiber-stack.md

@@ -0,0 +1,42 @@
+# React Three Fiber Stack
+
+This is the default React-native 3D stack for the plugin.
+
+## Primary components
+
+- [React Three Fiber](https://r3f.docs.pmnd.rs/getting-started/introduction) for declarative Three.js rendering in React.
+- [Drei](https://drei.docs.pmnd.rs/controls/introduction) for controls, loaders, helpers, environments, and common scene utilities.
+- [React Postprocessing](https://react-postprocessing.docs.pmnd.rs/introduction) for effect composition in React-hosted scenes.
+- [React Three Rapier](https://pmndrs.github.io/react-three-rapier/) for physics integration.
+- [React Three A11y](https://a11y.docs.pmnd.rs/introduction) when scene interaction benefits from accessibility-aware patterns.
+- [glTF Transform](https://gltf-transform.dev/) and the [glTF 2.0 specification](https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html) for shipped assets.
+
+## Default stack choices
+
+- Runtime: `@react-three/fiber` + `three`
+- Helper ecosystem: `@react-three/drei`
+- Physics: `@react-three/rapier`
+- Effects: `@react-three/postprocessing`
+- Accessibility: `@react-three/a11y` when appropriate
+- Assets: GLB or glTF 2.0
+
+## Choose this stack when
+
+- the 3D scene lives inside a React app
+- the UI shell, settings, or product flow already uses React
+- the team benefits from declarative scene composition
+- the scene must share app state with non-canvas UI
+
+## Avoid this stack when
+
+- the project wants a cleaner imperative loop with minimal React coordination
+- the whole game runtime would be easier to reason about in plain TypeScript
+
+## Companion references
+
+- `threejs-stack.md`
+- `react-three-fiber-starter.md`
+- `gltf-loading-starter.md`
+- `rapier-integration-starter.md`
+- `web-3d-asset-pipeline.md`
+- `webgl-debugging-and-performance.md`

.hermes/plugins/game-studio/references/react-three-fiber-starter.md

@@ -0,0 +1,51 @@
+# React Three Fiber Starter
+
+Use this as the smallest canonical starting point for a React-hosted 3D scene.
+
+## Files
+
+```text
+src/
+  App.tsx
+```
+
+## `src/App.tsx`
+
+```tsx
+import { Canvas } from "@react-three/fiber";
+
+function Spinner() {
+  return (
+    <mesh rotation={[0.4, 0.6, 0]}>
+      <boxGeometry args={[1, 1, 1]} />
+      <meshStandardMaterial color="#3dd9b8" />
+    </mesh>
+  );
+}
+
+export default function App() {
+  return (
+    <div className="app-shell">
+      <Canvas camera={{ position: [0, 1.5, 4], fov: 60 }}>
+        <color attach="background" args={["#101418"]} />
+        <ambientLight intensity={0.7} />
+        <directionalLight position={[4, 6, 3]} intensity={1.2} />
+        <Spinner />
+      </Canvas>
+      <div className="hud">
+        <div className="objective-chip">Reach the lantern bridge.</div>
+        <div className="hint-pill">WASD to move. Hold mouse to look.</div>
+      </div>
+    </div>
+  );
+}
+```
+
+## Notes
+
+- Start here when the 3D scene lives inside an existing React app.
+- Keep the initial HUD sparse. One compact objective surface and one transient hint is usually enough for a first playable scaffold.
+- Put lore, notes, map, and settings behind drawers or modals instead of opening them all by default.
+- Add GLB loading with `gltf-loading-starter.md`.
+- Add physics with `rapier-integration-starter.md`.
+- Use `three-hud-layout-patterns.md` for low-chrome 3D overlay defaults.

.hermes/plugins/game-studio/references/sprite-pipeline.md

@@ -0,0 +1,57 @@
+# Sprite Pipeline
+
+This is the default 2D animation workflow for the plugin.
+
+## Principles
+
+- Start from one approved in-game frame.
+- Generate the animation as one strip, not isolated frames.
+- Normalize the whole strip with one shared scale.
+- Use one shared anchor, typically bottom-center.
+- Preview before approving the asset.
+
+## Why this works
+
+- The approved seed frame preserves identity.
+- Strip-first generation reduces frame-to-frame drift.
+- Shared-scale normalization prevents one tall pose from making the character feel smaller.
+- Locking frame 01 back to the shipped sprite preserves continuity for idle-to-action transitions.
+
+## Prompt template
+
+```text
+Intended use: candidate production spritesheet for a 2D browser game animation review.
+Edit the provided transparent reference canvas into a single horizontal <N>-frame spritesheet.
+
+The existing sprite in the leftmost slot is the anchor frame and must remain the same character:
+- same facing direction
+- same silhouette family
+- same palette family
+- same proportions
+- same readable face or key features
+- same outfit details
+
+Composition:
+- transparent canvas
+- exactly one row of <N> equal frame slots
+- no extra characters
+- no labels
+- no scenery
+- no poster layout
+
+Action:
+- describe the specific animation beat from frame 1 through frame N
+
+Style:
+- authentic pixel-art production asset
+- crisp pixel clusters
+- restrained palette
+- not concept art
+```
+
+## Normalization notes
+
+- Use the union of detected sprite bounds per slot.
+- Compute one scale from the largest detected frame and anchor.
+- Bottom-align frames into the target canvas.
+- Reuse the exact shipped frame for frame 01 when `--lock-frame1` is appropriate.

.hermes/plugins/game-studio/references/three-hud-layout-patterns.md

@@ -0,0 +1,61 @@
+# 3D HUD Layout Patterns
+
+Use these defaults for initial 3D browser-game scaffolds. The first screen should be playable before it is informational.
+
+## Layout Budget
+
+- Keep the center of the screen clear during normal play.
+- On desktop, prefer one primary persistent cluster and one small secondary cluster.
+- On mobile, prefer one compact persistent cluster and transient prompts.
+- Secondary information belongs in drawers, toggles, pause menus, or contextual popovers.
+
+## Good Default Patterns
+
+### Objective chip
+
+- One short objective in a compact top-corner chip.
+- One optional sublabel for location or mode.
+- No giant hero banner over the live scene.
+
+### Contextual interaction prompt
+
+- Bottom-center or lower-corner pill.
+- Appears only near interactables or during onboarding.
+- Dismisses after first use or fades once the player is moving confidently.
+
+### Small status strip
+
+- Health, energy, party count, or beacon progress in a narrow edge-aligned strip.
+- Use icons, short labels, and compact meters instead of stacked cards.
+
+### Collapsible journal or quest log
+
+- Closed by default.
+- Opened by a hotkey, button, or pause state.
+- Holds longer prose, lore, map notes, and multi-step objective details.
+
+### Pause and settings modal
+
+- Explicit modal state.
+- Suspends pointer-lock, drag-look, or camera input while active.
+
+## Anti-Patterns
+
+- four to six glass cards permanently framing the viewport
+- large lore or field-notes panels open during normal movement
+- controls lists permanently pinned to the screen
+- symmetric dashboard composition that competes with the scene
+- oversized title panels staying visible after the first second of play
+
+## Example UI Budget
+
+- top-left: objective chip
+- top-right: compact status strip
+- bottom-center: transient interaction or controls hint
+- pause menu or drawer: map, notes, inventory, settings
+
+## Prompt Add-On
+
+```text
+Default to a low-chrome playable HUD. Keep the central playfield clear. Use one compact objective chip, one small status surface, and transient prompts. Put lore, field notes, full controls, and long checklists behind a drawer or pause menu. Avoid equal-weight boxed panels in every corner.
+```

.hermes/plugins/game-studio/references/three-webgl-architecture.md

@@ -0,0 +1,61 @@
+# Three WebGL Architecture
+
+This is the default 3D structure for the plugin.
+
+## Recommended module split
+
+```text
+src/
+  game/
+    simulation/
+    content/
+    input/
+    save/
+  render/
+    app/
+      createRenderer.ts
+      createScene.ts
+      createCamera.ts
+      createLoop.ts
+    loaders/
+      loadGltf.ts
+      loadEnvironment.ts
+      loadTextures.ts
+    objects/
+    materials/
+    lights/
+    post/
+    adapters/
+      renderBridge.ts
+  physics/
+    world.ts
+    colliders.ts
+    sync.ts
+  diagnostics/
+    debugFlags.ts
+    perf.ts
+  ui/
+    hud/
+    menus/
+    overlays/
+```
+
+## Responsibilities
+
+- `simulation/`: rules, state, AI, progression, save data
+- `render/app/`: renderer, scene, camera, resize, context lifecycle
+- `render/loaders/`: GLTF, compression, texture, and environment loading
+- `render/objects/`: scene graph construction and disposal
+- `render/materials/`: material setup and shader boundaries
+- `physics/`: Rapier world and simulation bridge
+- `diagnostics/`: performance probes and GPU debugging hooks
+- `ui/`: DOM HUD and menus
+
+## Rules
+
+- Scene graph objects are not the source of truth for game rules.
+- Keep camera logic explicit and testable.
+- Handle resize and context-loss as real browser concerns.
+- Keep high-density UI in DOM even when the world is fully 3D.
+- Treat GLB or glTF 2.0 as the default content format.
+- Add physics and diagnostics as real subsystems, not temporary one-off utilities.

.hermes/plugins/game-studio/references/threejs-stack.md

@@ -0,0 +1,41 @@
+# Three.js Stack
+
+This is the default non-React 3D runtime stack for the plugin.
+
+## Primary components
+
+- [Three.js documentation](https://threejs.org/docs/) for the core renderer, scene graph, materials, cameras, loaders, and examples.
+- [Rapier JavaScript guide](https://rapier.rs/docs/user_guides/javascript/getting_started_js/) for physics integration.
+- [glTF 2.0 specification](https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html) for the default shipping asset format.
+- [glTF Transform](https://gltf-transform.dev/) for optimization, packaging, and compression workflows.
+- [SpectorJS](https://spector.babylonjs.com/) for WebGL frame capture and GPU debugging.
+
+## Default stack choices
+
+- Runtime: `three`
+- Tooling: TypeScript + Vite
+- Assets: GLB or glTF 2.0
+- Loaders: `GLTFLoader`, `DRACOLoader`, `KTX2Loader` when the asset pipeline requires them
+- Physics: Rapier JS
+- UI: DOM overlays, not in-scene UI by default
+
+## Choose this stack when
+
+- the project is not React-first
+- the team wants direct control over the render loop
+- scene composition, loader setup, or custom render behavior needs imperative structure
+- the game code should feel engine-like without a React abstraction layer
+
+## Avoid this stack when
+
+- the surrounding app is already React-heavy and wants shared declarative state
+- the project needs an editor-first engine workflow more than a portable TypeScript runtime
+
+## Companion references
+
+- `three-webgl-architecture.md`
+- `threejs-vanilla-starter.md`
+- `gltf-loading-starter.md`
+- `rapier-integration-starter.md`
+- `web-3d-asset-pipeline.md`
+- `webgl-debugging-and-performance.md`

.hermes/plugins/game-studio/references/threejs-vanilla-starter.md

@@ -0,0 +1,58 @@
+# Three.js Vanilla Starter
+
+Use this as the smallest canonical starting point for a plain TypeScript or Vite Three.js app.
+
+## Files
+
+```text
+src/
+  main.ts
+```
+
+## `src/main.ts`
+
+```ts
+import * as THREE from "three";
+
+const scene = new THREE.Scene();
+scene.background = new THREE.Color("#101418");
+
+const camera = new THREE.PerspectiveCamera(60, window.innerWidth / window.innerHeight, 0.1, 200);
+camera.position.set(0, 1.5, 4);
+
+const renderer = new THREE.WebGLRenderer({ antialias: true });
+renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2));
+renderer.setSize(window.innerWidth, window.innerHeight);
+document.body.appendChild(renderer.domElement);
+
+scene.add(new THREE.AmbientLight(0xffffff, 0.7));
+const light = new THREE.DirectionalLight(0xffffff, 1.2);
+light.position.set(4, 6, 3);
+scene.add(light);
+
+const mesh = new THREE.Mesh(
+  new THREE.BoxGeometry(1, 1, 1),
+  new THREE.MeshStandardMaterial({ color: "#3dd9b8" }),
+);
+scene.add(mesh);
+
+window.addEventListener("resize", () => {
+  camera.aspect = window.innerWidth / window.innerHeight;
+  camera.updateProjectionMatrix();
+  renderer.setSize(window.innerWidth, window.innerHeight);
+});
+
+renderer.setAnimationLoop(() => {
+  mesh.rotation.y += 0.01;
+  renderer.render(scene, camera);
+});
+```
+
+## Notes
+
+- Start here for direct loop and renderer control.
+- If the scaffold needs UI, start with one compact objective chip and one transient controls hint rather than multiple permanent cards.
+- Keep notes, codex, maps, and settings behind on-demand surfaces. The starter scene should stay readable while moving the camera.
+- Add GLB loading with `gltf-loading-starter.md`.
+- Add physics sync with `rapier-integration-starter.md`.
+- Use `three-hud-layout-patterns.md` for low-chrome 3D overlay defaults.

.hermes/plugins/game-studio/references/web-3d-asset-pipeline.md

@@ -0,0 +1,47 @@
+# Web 3D Asset Pipeline
+
+This is the default 3D asset shipping guidance for the plugin.
+
+## Primary sources
+
+- [Blender glTF exporter manual](https://docs.blender.org/manual/en/latest/addons/import_export/scene_gltf2.html)
+- [glTF 2.0 specification](https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html)
+- [glTF Transform](https://gltf-transform.dev/)
+- [PlayCanvas supported formats](https://developer.playcanvas.com/user-manual/assets/supported-formats/) for a good reference on why GLB is the recommended runtime format in browser engines
+
+## Default output
+
+- Ship GLB when possible.
+- Use `.gltf` with external files only when the asset pipeline or delivery strategy genuinely needs that shape.
+
+## Recommended workflow
+
+1. Clean the source asset in the DCC tool.
+2. Export to GLB or glTF 2.0.
+3. Run glTF Transform for validation, pruning, deduplication, and size reduction.
+4. Apply the chosen geometry and texture compression strategy.
+5. Verify pivots, scale, collision assumptions, and hierarchy naming.
+6. Test the asset in the runtime before treating it as final.
+
+## Compression and optimization
+
+- Use Draco or Meshopt deliberately, not both by default.
+- Use KTX2 or BasisU when the runtime stack supports GPU-friendly compressed textures.
+- Keep texture resolution aligned with actual on-screen use.
+- Reuse materials and avoid unnecessary texture uniqueness.
+
+## Runtime checks
+
+- scale is consistent across assets
+- pivots match gameplay expectations
+- node names are stable
+- collision proxy needs are handled
+- animation clips and variants load correctly
+- memory and load time are reasonable for the scene
+
+## Starter patterns
+
+- `threejs-vanilla-starter.md`
+- `react-three-fiber-starter.md`
+- `gltf-loading-starter.md`
+- `rapier-integration-starter.md`

.hermes/plugins/game-studio/references/webgl-debugging-and-performance.md

@@ -0,0 +1,36 @@
+# WebGL Debugging and Performance
+
+Use this reference when a browser 3D scene is visually wrong, unstable, or slower than expected.
+
+## Primary tools
+
+- [SpectorJS](https://spector.babylonjs.com/) for frame capture, pipeline inspection, draw-call review, and shader debugging.
+- Browser performance tooling for main-thread work, asset decode stalls, and memory pressure.
+- Engine-native debug views and stats surfaces where available.
+
+## What to inspect first
+
+- draw-call count
+- shader compilation churn
+- texture memory pressure
+- geometry count and material count
+- post-processing cost
+- asset decode and streaming stalls
+- WebGL context loss or fallback behavior
+
+## Common causes of poor performance
+
+- too many unique materials
+- oversized textures
+- heavy GLB assets loaded without optimization
+- complex post-processing on top of an already expensive scene
+- physics and render state fighting for ownership
+- React and scene state updating each other too frequently in React-hosted 3D apps
+
+## Debugging rules
+
+- Capture first, then guess.
+- Reduce the scene until the perf cliff becomes obvious.
+- Disable post-processing before rewriting core scene code.
+- Verify the asset pipeline before blaming the renderer.
+- Treat context-loss handling as a browser requirement, not an edge case.