Three.js Web Projects

Use the project's installed versions and existing architecture. These instructions supplement the user's task; they do not authorize unrelated changes or external actions.

Establish the visible outcome, interaction, asset inputs, existing stack, and target devices from the request and repository. Preserve the chosen framework and art direction. Ask only about decisions that materially block implementation.

Inspect package manifests, lockfiles, routes, styles, current canvas ownership, and available assets. Record the installed Three.js revision, renderer backend, and companion package peer requirements. Use documentation or source matching those versions; do not upgrade the stack just to match an example.

Build a vertical slice first: a responsive canvas, representative subject, camera framing, one interaction, and a usable loading/error state. Then add requested detail. Keep product text, navigation, forms, and core actions in semantic HTML.

Choose only the relevant specialist instructions from the routing guide. Skills are optional focused guidance, not a requirement to run every workflow. When only this skill is installed, implement from the requirements and consult the official documentation directly.

Define asset and frame budgets for the actual devices. Add resize handling, explicit resource ownership, reduced motion, and a non-WebGL fallback as appropriate to the experience. Verify visible results in a browser, not just compilation. Report what was built, checks actually performed, and unresolved device or asset limitations. Shipping instructions do not authorize publication outside the user's request.

API reference

Consult the official documentation for exact signatures and revision-specific behavior. If documentation access is unavailable, inspect installed types/source and state any remaining uncertainty.