threejs-game-skills: Agent Skills That Route a Three.js Game Build End to End

The problem is not Three.js, it is the agent forgetting what it decided

Three.js is well documented and a competent model can write a scene graph. What a model does poorly across a long build is hold a decision. Session one picks a camera scale, a colour range and a movement feel. Session four adds a level and quietly changes all three. The README frames the director's job as preserving "your scope and art direction" while using specialist guidance automatically, and that is the real claim here: not that the agent can write Three.js, but that it can keep a multi-hour build coherent and scale its own verification to the size of the change. The intended user is an engineer or designer who already works inside Codex or Claude Code and wants a game loop, not a rendering demo. The README's own framing is blunt about the alternative: "Full games get a complete production pass; a small HUD fix stays a small HUD fix."

One shared skill pack, a director that delegates, and a scaffold the agent uses internally

The repository ships nine skills in skills/, shared by both runners. threejs-game-director is the entry point; the siblings cover gameplay systems, graphics, UI, debug and profiling, QA and release, plus three asset generators for 3D, images and audio. The README describes the director as routing "gameplay, graphics, UI, asset generation, audio, debugging, and release verification without requiring users to choose every specialist skill manually."

Each skill folder carries its own runtime material: SKILL.md files, references, helper scripts, and in the relevant folders a Vite + TypeScript + Three.js scaffold. That bundling is the architectural decision worth noting. The scaffold is not a separate starter repo you clone; it lives inside the skill and the agent copies from it when starting in an empty folder. The same applies to the QA helpers, which the README says users "generally should not need to run" directly.

Generated games carry deterministic test hooks, a seeded RNG, and Playwright templates for smoke tests, visual-regression baselines and bot playtests. The seeding matters more than it sounds: a visual-regression baseline is worthless if the scene randomises differently on every run. Delegation to subagents, background tools and native async execution are described as host-dependent, and the README states plainly that installing the skills does not enable an API feature or change model settings. When delegation is unavailable, the agent works directly.

Installing the skills and getting a first playable loop

The README gives an npx command per runner. For Codex, the install is a single line with a global flag:

npx skills add majidmanzarpour/threejs-game-skills --skill '*' -a codex -g -y

For Claude Code the same command targets a different agent:

npx skills add majidmanzarpour/threejs-game-skills --skill '*' -a claude-code -g -y

If your installed skills CLI does not support one of those targets, the README points to a cloned checkout and its installer. The local installer copies skills/ into the selected agent skills directory, skips same-named skills unless --force is passed, and does not remove unrelated user skills unless --prune-managed is requested. That default is the safe one: a first install will not overwrite anything of yours.

./install.sh --codex
./install.sh --claude
./install.sh --all

Once installed, open the agent in an empty project folder or in an existing Three.js game. Discovery differs by runner. Claude Code reads from ~/.claude/skills and routes from each SKILL.md description, and you can invoke the director with /threejs-game-director. Codex discovers global skills in ~/.agents/skills, and each skill's agents/openai.yaml supplies a display name and a short $skill-name kickoff prompt, so $threejs-game-director works. The README warns against installing duplicate copies in both ~/.agents/skills and the legacy ~/.codex/skills root.

The first prompt is the whole interface. The README's example asks the director to build a playable loop before iterating:

Use threejs-game-director to build a premium futuristic tower defense game from scratch.
Automatically use the relevant gameplay, graphics, UI, asset generation, audio, debug,
and QA skills. Build a playable loop first, then iterate until it passes browser,
mobile, visual, UI, performance, and release checks.

What you should see is game code appearing in your project folder, not in the skill directory, with the agent establishing art direction, camera scale and a representative playable scene before expanding levels or asset families. The README also says the agent should keep a compact project note recording constraints, completed work, pending asset jobs and next actions so that corrections do not restart finished generation.

Asset generation is optional, and the fallback is the honest part

Three of the nine skills call paid providers. threejs-3d-generator uses the Tripo API through TRIPO_API_KEY for text, image and multiview to 3D, game-ready GLB and FBX models, rigging and animation. threejs-image-generator uses the Gemini image API through GEMINI_API_KEY for concept art, texture references, skies, icons and menu art. Audio has its own generator skill. The README states that the core Three.js skills work without paid API keys.

The behaviour when a key is missing is specified rather than left to chance. The director continues with procedural and local assets and reports the affected limitation. Temporary failures trigger "bounded recovery of the existing job, not an immediate downgrade or duplicate paid submission", and requests that are explicitly procedural stay procedural. That last clause is the one to hold the tool to, because the expensive failure mode for any agent that can call a paid API is re-submitting a job it already paid for. The README also warns against committing API keys or placing them in browser-side game code, and describes the flow as provider APIs called from local agent tooling with generated assets saved into your game project. That separation is correct, but it is a convention the skills follow, not something the installer enforces.

Where this is the wrong tool

The README is explicit that host capabilities vary. Background tools, subagents, native async execution, user-steering delivery and reasoning settings all depend on the runner, and installing the skills does not change your model settings. If your runner cannot delegate, the director works directly. That is fine for a small HUD change and materially slower for a full build with three asset families, because the parallelism the design assumes is not there.

The harder limit is that nothing here is a runtime. There is no engine, no physics library, no networking layer, no server. A generated game is a Vite + TypeScript + Three.js project that you still have to host and operate, and the README's own demos are static Netlify sites. If you need multiplayer authority, persistence, or anything that survives a page reload on the server, this pack does not address it and the README does not claim to.

Verification is also narrower than the phrase "release checks" suggests. The Playwright templates cover smoke tests, visual-regression baselines and bot playtests, and the README lists production builds, real input, screenshots, canvas pixels, supported viewports and motion evidence for animated models. That is a strong automated surface. It is not a substitute for playing the game, and no skill can tell you whether the loop is fun. Finally, the README does not document rollback, and the installer's overwrite protection is opt-in via --force, so re-installing over a modified skill folder is a decision you make deliberately.

How it differs from a starter template or a prompt library

The obvious alternative is a Three.js starter template plus a folder of prompts you paste yourself. The difference is state and routing. A template gives you files and stops. A prompt library gives you text and stops. This pack gives the agent a named entry point that reads each sibling skill's SKILL.md description and decides which ones apply, then carries a project note forward so a correction in session five does not invalidate work from session two. That is a real mechanical difference, not a marketing one.

A second alternative is asking a general coding agent to build the game with no skills installed. That works for a single-file demo. It breaks down on the parts this pack packages as scripts: deterministic test hooks, a seeded RNG, canvas-pixel inspection, and the visual-regression baseline workflow. Those are the pieces a model will not invent consistently across sessions, and they are the reason the QA and release skill exists as a separate unit rather than a paragraph in a prompt.

Maintenance, licence and what an upgrade actually costs

The repository is MIT licensed, and the LICENSE file sits at the top level alongside install.sh, package.json, scripts/ and skills/. MIT is permissive, so you can vendor the skills into an internal repo or modify them. Two practical consequences follow. First, the skills are copied into ~/.claude/skills or ~/.agents/skills at install time, so your installed copy and the repository can drift; the installer's default of skipping same-named skills means a re-run will not silently refresh them, and --force is how you overwrite. Second, if you edit a skill in place, that edit is yours to maintain, because nothing in the described flow reconciles local changes against upstream.

The package is private and versioned 0.1.0 in package.json, with no releases retrieved. The last push to the default branch was on 2026-09-05. The development dependencies are @playwright/test and pngjs, and package.json exposes check:scripts, validate:skills, test:helpers and the three install targets. Upgrading therefore means re-running the install command or the local installer, then re-checking the scaffold inside the gameplay skill if you had customised it. There is no migration tooling described, and the README does not document rollback. This is not legal advice; if you redistribute the skills or the generated assets, read the MIT text and the provider terms for Tripo and Gemini separately, since those govern the assets rather than the skills.

Editorial conclusion

Adopt it if you already run Codex or Claude Code and want an agent to hold art direction, gameplay scale and QA across a multi-session Three.js build, since the director's job is exactly the part agents usually lose between prompts. Skip it if you want a game engine, a runtime library, or a framework that works without an agent in the loop: this is a skills pack, and the scaffold inside it only runs when the agent invokes it. Verify three things first: that your skills CLI accepts the codex or claude-code target, that your runner actually loads skills from ~/.agents/skills or ~/.claude/skills, and that the bundled Playwright smoke and visual-regression templates run in your environment before you trust a release check.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. majidmanzarpour/threejs-game-skills on GitHub
4. README