Three.js WebGPU Skill Pack vs official Three.js docs

Short answer

Use the official Three.js documentation as the primary reference for documented APIs, imports, and properties. For exact behavior, inspect the installed revision's source and run a minimal reproduction on the relevant backend. Use this skill pack when an agent must select a defensible rendering architecture, implement a multi-system WebGPU or TSL workflow, and verify the result with inspectable evidence. For serious work, use both.

The two resources are complementary. The official project owns the library. This pack owns a narrower agent workflow for advanced rendering decisions at its declared revision boundary.

What each resource owns

The official WebGPURenderer manual is the primary reference when the question is whether it documents support for ShaderMaterial, onBeforeCompile, or EffectComposer. When the decision depends on exact behavior, inspect the installed revision's source and reproduce the behavior on the relevant backend. The skill pack is the stronger route when the question is how depth, normal, velocity, history, exposure, and final-output ownership should be divided across a real pipeline.

Choose the official docs when

• You need the current constructor, property, import, or compatibility contract.
• You are checking whether an addon, material, renderer feature, or post-processing node exists.
• You want the upstream example closest to one isolated feature.
• You need release notes or a migration change between Three.js revisions.
• You are learning the library broadly rather than solving one advanced rendering system.

The official examples are also the cleanest way to discover what the upstream project currently demonstrates. They should be read as feature examples. Your production constraints, lifecycle, diagnostic coverage, and target devices still need separate verification.

Choose this pack when

• An agent must select the smallest relevant set of rendering specialists.
• Several systems share scene signals or compete for final-output ownership.
• The workload needs a representation choice, resource accounting, invalidation rule, and failure conditions.
• The result must include a fixed-view capture, diagnostic view, negative control, backend identity, or other falsifiable evidence.
• You need a repository-local workflow that can be reviewed with the implementation.

For example, the official TSL specification documents RenderPipeline, MRT, pass(), and renderOutput(). The image-pipeline skill adds the adoption decision: allocate an attachment only when a consumer requires it, keep one owner for tone mapping and output conversion, and mark the graph dirty when its output node changes.

Use both in one workflow

1. Define the workload and target devices in the project prompt.
2. Use choose skills to select the smallest specialist set.
3. Confirm documented r185 APIs against the official docs; confirm exact behavior against installed-revision source and a minimal runtime reproduction.
4. Implement within the existing repository conventions.
5. Run the specialist validation procedure and inspect its important images.
6. Re-check the live upstream source before relying on a fact that may have changed after r185.

This division keeps authority clear. The pack should not paraphrase an API signature and then pretend to replace upstream documentation. The docs should not be treated as proof that an agent implemented the correct mechanism in a particular repository.

Limitations

This pack is not a complete Three.js reference, a beginner JavaScript course, or a guarantee that every current upstream feature has a specialist owner. Its canonical claims are bounded to the declared 0.185.1 dependency and the evidence present in the repository.

The official docs do not promise to choose an architecture for a user, modify a repository, or produce task-specific evidence. Their live content can also move beyond this pack's revision. When behavior is disputed, inspect the exact installed Three.js revision and its source, then reproduce it on the relevant runtime backend before changing code.

For a learning-path comparison, continue to Three.js WebGPU learning resources. For a concrete existing codebase, use the existing-project adoption guide.

Relevant product evidence