Building and testing a three.js game with the harness

The harness runs the game in a headless Chrome on a paused, seeded clock: you send inputs frame by frame and read back the game's state as JSON, so what you see is exact and repeatable.

The goal is the highest-quality result for what the user asked: how it looks, plays and feels. A reply with no fault lines is the floor, not the finish. Decide what to improve from the request and from your own picture of the page: what it is, what a viewer should feel, and what is missing in the scene, in the HUD, menus and text a viewer reads, and in each control and feature the request names. Work that out before you look; a look then shows whether a change worked. Do not take the next idea from the screenshot: that patches what it shows and keeps the weak decisions under it. A fault line or a glitch is different: close those one at a time with the method in references/lighting.md.

Build first, then polish

Write the page whole and make the first version as impressive as you can: interesting, detailed, creative. Take risks in the code: the tools below find and fix what breaks cheaply, so a bold build that needs polishing beats a safe one that needs growing. Give it a window.__game following the convention below; ${CLAUDE_PLUGIN_ROOT}/skills/threejs-game/templates/ shows the shape in a working page: plain.html (one page, an import map, no build, set up with stage()), viewer.html (a product configurator: references/configurator.md), r3f.tsx (React Three Fiber under vite) and rapier.ts (the window.__game bridge for a Rapier world, with either). An existing game works as it is; add window.__game when you need its state.

What each tool shows

Every option of these tools: references/tools.md.