← Game StudioCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Game Studio
Snapshot Sep 30, 2026 · 23:18 UTC · version 0.1.2
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"name": "react-three-fiber-game",
"description": "Build React-hosted 3D browser games with React Three Fiber. Use when the user wants pmndrs-based scene composition, shared React state, and 3D HUD integration inside a React app.",
"included_files": [
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 239
}
],
"skill_md_contents": "---\nname: react-three-fiber-game\ndescription: Build React-hosted 3D browser games with React Three Fiber. Use when the user wants pmndrs-based scene composition, shared React state, and 3D HUD integration inside a React app.\n---\n\n# React Three Fiber Game\n\n## Overview\n\nUse this skill when the 3D runtime lives inside a React application. This is the default React-native 3D path in the plugin and should be preferred over vanilla Three.js when the app shell, settings, storefront, editor surface, or surrounding product already uses React.\n\nRecommended stack:\n\n- `@react-three/fiber`\n- `three`\n- `@react-three/drei`\n- `@react-three/rapier`\n- `@react-three/postprocessing`\n- `@react-three/a11y` when accessibility-sensitive interaction matters\n- DOM overlays in the normal React tree\n\n## Use This Skill When\n\n- the project already uses React\n- the 3D scene must share state with the rest of the app\n- declarative scene composition is a net gain\n- the team wants pmndrs helpers instead of building every helper layer by hand\n\n## Do Not Use This Skill When\n\n- the app is not React-based\n- the project wants a cleaner imperative runtime with minimal React coordination\n- the problem is asset packaging rather than runtime composition\n\n## Best Fit Scenarios\n\n- 3D configurators and tool-rich browser products\n- React apps with embedded game or scene surfaces\n- 3D menus, editors, or world maps in an existing React app\n- 3D game UIs that depend on shared app state and non-canvas shells\n\n## Core Rules\n\n1. Keep simulation state outside render components.\n - React components should describe scene composition, not become the source of truth for gameplay rules.\n2. Use React state and scene state deliberately.\n - Shared UI state can live in app state.\n - High-frequency simulation should not force the whole app through unnecessary React churn.\n3. Use pmndrs helpers intentionally.\n - Drei for controls, loaders, helpers, environments, and common scene primitives.\n - `@react-three/rapier` for physics integration.\n - `@react-three/postprocessing` for optional effects.\n - `@react-three/a11y` when the interaction model benefits from accessible scene semantics.\n4. Keep HUD, settings, and menus in DOM by default.\n5. Keep starter scaffolds visually restrained.\n - Start with one compact objective or status surface and transient prompts.\n - Keep notes, maps, and multi-step checklists collapsed until opened.\n - Do not surround the `Canvas` with equally weighted glass cards.\n\n## Architectural Guidance\n\n- Use a dedicated scene root component that owns the `Canvas`.\n- Keep camera rigs and control components isolated from gameplay systems.\n- Keep loader and asset wrappers predictable.\n- Keep DOM overlays and the 3D scene coordinated through explicit state boundaries.\n- If a system needs tight imperative control, isolate it rather than forcing everything into declarative patterns.\n- If the scene is immediately playable, keep the initial overlay budget low and let the world do more of the onboarding.\n\n## Anti-Patterns\n\n- Treating React components as the gameplay state store\n- Pushing heavy per-frame mutation through broad app state\n- Using R3F only because React is available, even when the project needs a cleaner imperative runtime\n- Building HUD or inventory UI inside the 3D scene by default\n- Shipping an initial scaffold with large cards occupying every side of the viewport\n\n## References\n\n- Shared architecture: `../web-game-foundations/SKILL.md`\n- Frontend direction: `../game-ui-frontend/SKILL.md`\n- 3D HUD layout patterns: `../../references/three-hud-layout-patterns.md`\n- React Three Fiber stack: `../../references/react-three-fiber-stack.md`\n- React starter: `../../references/react-three-fiber-starter.md`\n- GLB loader starter: `../../references/gltf-loading-starter.md`\n- Rapier starter: `../../references/rapier-integration-starter.md`\n- 3D asset pipeline: `../../references/web-3d-asset-pipeline.md`\n- WebGL debugging and perf: `../../references/webgl-debugging-and-performance.md`\n"
}SHA-256: 60ca743a52809b152b374ac1d0dd16a9e7656af2aca750ff9a0063115f6379a1