Three.js WebGPU skills for graphics engineers

This pack is a strong fit for graphics engineers who already work in Three.js and need an agent to reason about WebGPU/TSL architecture, resource ownership, and falsifiable acceptance criteria. It exposes assumptions instead of hiding them behind a visual preset.

Strong fit

• You need to choose a causal rendering architecture before allocating passes, compute work, MRT attachments, or histories.
• Multiple consumers share depth, normals, velocity, identifiers, temporal state, or final-output policy.
• Correctness, GPU attribution, resource use, or lifecycle claims must be tied to a named target and inspectable evidence.

Poor fit

• You need no-code 3D, beginner JavaScript instruction, a turnkey game engine, or generic prompt snippets.
• The project is a fixed WebGL recipe collection with no planned WebGPU/TSL adoption.
• The main problem is asset ingestion, application state, UI, data transport, or physics-engine selection; this pack does not own those systems.

Three recurring jobs

1. Choose the causal architecture — threejs-choose-skills. Record the protected observable, units, coordinate frame, target matrix, earliest missing cause, candidate mechanisms, and rejected alternatives.
2. Own shared passes and final presentation — threejs-image-pipeline. Name each attachment's format, resolution, sample count, lifetime, producer, and consumers. Keep one scene render when the declared graph already exposes the required signals, and keep exactly one tone-map/output path.
3. Turn claims into evidence — threejs-visual-validation. Freeze the run, capture only the diagnostics that isolate each claim, use aligned readback or timestamp queries where required, and label unavailable evidence unmeasurable.

The RenderPipeline versus EffectComposer comparison owns that architecture decision; the TSL versus GLSL comparison owns the shader-authoring decision.

Representative workflow: add a shared WebGPU image pipeline

1. Define the task as a protected observable, such as stable product identity under AO, bloom, temporal accumulation, and grading—not “add more effects.”
2. Record Three.js 0.185.1/r185, WebGPURenderer, the initialized backend, browser, GPU, viewport, DPR, fixed camera path, scene state, and acceptance bounds.
3. Route the earliest missing cause, then declare scene color, depth, normals, velocity, histories, and final-output ownership before adding consumers.
4. Implement the smallest composed graph. Compare minimal-forward and shared-MRT variants on the target hardware; do not infer mobile bandwidth behavior from a desktop result.
5. Capture no-post, contribution, final, resource-ledger, lifecycle, and any required timing evidence from that composition. Accept the task only when each bound has direct evidence or is explicitly narrowed.

The WebGPU image-pipeline demo has source-matched accepted evidence for output, normal, emissive, velocity, temporal, and final diagnostics in its captured graph; current-adapter GPU timing and lifecycle claims remain insufficient. The native WebGPU validation harness has source-matched accepted evidence for aligned render-target readback, MRT, resource-ledger, timing, and artifact-validation mechanics. Neither report proves a different project composition.

Constraints

There are no universal frame, memory, draw, triangle, or attachment budgets. renderer.info is an engine counter with exclusions, not measured VRAM, and CPU or presentation timing is not GPU timing.

Start here

Use the installation guide to add the pack to the repository, then start the first multi-system task with threejs-choose-skills.