game-studio

Route early browser-game work. Use when the user needs stack selection and workflow planning across design, implementation, assets, and playtesting before…

npx skills add https://github.com/openai/plugins --skill game-studio

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."

More skills from openai

user-context
openai
Load or manage the Data Analytics plugin's durable source-routing preferences, onboarding logic, setup progress, and semantic-layer registry.
official
notion-research-documentation
openai
Research Notion content and synthesize into structured briefs, reports, or comparisons with citations. Search and fetch Notion pages using targeted queries, then organize findings by theme with inline source citations and a references section Choose from four output formats (quick brief, research summary, comparison, comprehensive report) based on scope and user goal Create and update Notion pages using built-in templates; link sources directly and track changes as new information arrives...
official
rcsb-pdb-skill
openai
Submit compact RCSB PDB requests for core metadata, Search API queries, and FASTA downloads. Use when a user wants concise RCSB summaries; save raw JSON or…
official
pdf
openai
PDF reading, creation, and validation with visual rendering and programmatic generation. Render PDF pages to PNG for visual inspection of layout, spacing, and typography before delivery using Poppler ( pdftoppm ) Generate PDFs programmatically with reportlab for reliable formatting; extract text and metadata with pdfplumber or pypdf Enforce quality standards: no clipped text, overlapping elements, broken tables, or rendering artifacts; ASCII hyphens only, human-readable citations Use...
official
test-coverage-improver
openai
Improve test coverage in the OpenAI Agents JS monorepo: run `pnpm test:coverage`, inspect coverage artifacts, identify low-coverage files and branches, propose…
official
playwright
openai
Terminal-driven browser automation with element snapshots and interactive UI workflows. Operates via playwright-cli wrapper script (requires npx ); supports headless and headed modes for visual debugging Core workflow: open page, snapshot for stable element references, interact using refs, re-snapshot after navigation or DOM changes Includes form filling, clicking, typing, multi-tab management, screenshot/PDF capture, and trace recording for flow debugging Element refs (e.g., e3 , e15 )...
official
ukb-topmed-phewas-skill
openai
Fetch compact UKB-TOPMed PheWAS summaries for single variants by accepting rsID, GRCh37, or GRCh38 input and resolving to the required GRCh38 query. Use when a…
official
code-review-context
openai
Model visible context
official