webgpu-spec-lookup

---

name: webgpu-spec-lookup description: Ground any answer about the WebGPU platform itself — browser support/compatibility, feature availability, limits, what's shipping or behind a flag, and exact spec behavior — in the live Chrome WebGPU docs and the W3C spec before responding, instead of answering from memory. Use whenever a question is about WebGPU as a platform rather than OGPU's own code: "is X supported in Chrome/Safari/Firefox", "are 64-bit atomics available", "what's the default maxStorageBufferBindingSize", "does WebGPU have feature Y yet", "what's new in WebGPU", "is timestamp-query / shader-f16 / float32-filterable shipping", origin-trial/flag status, or whether some API is in the spec at all. WebGPU moves fast and memory goes stale — fetch the sources first.

Answer WebGPU-platform questions from the live docs, not from memory

WebGPU is a moving target: features ship per Chrome milestone, limits get raised, things sit behind flags or origin trials, and the spec adds capabilities on a rolling basis. Whatever you recall about "is X supported" or "what's the default limit" is liable to be months stale, and a confident wrong answer about browser support or a feature name wastes the user's time. The cost of fetching is a few seconds. So for platform questions, check the sources before answering.

This skill is for questions about WebGPU the platform — support, features, limits, spec behavior. It is NOT for questions about OGPU's own engine code (that's the codebase) or the webgpu-utils library (that's the webgpu-utils-lookup skill).

Sources

Two sources answer different things — query each its own way:

1. Chrome WebGPU docs / "What's New" — reality of what's shipped. (WebFetch) https://developer.chrome.com/docs/web-platform/webgpu This is the entry point; the per-release "What's New in WebGPU (Chrome NNN)" posts are where feature-shipping, flags, origin trials, and raised limits are announced. The landing page links to them — if the answer needs a specific milestone, follow the link (or WebSearch What's New in WebGPU Chrome to find the most recent post). Use this for: "is it shipping / in which Chrome / behind a flag / in an origin trial", and browser-compat reality.

2. W3C WebGPU spec — authoritative API surface. (local cache, grep — not WebFetch) The spec is one 4.5 MB page; WebFetch'ing it per question is slow and lossy. Instead query a preprocessed local copy:

   # Prints the cache path; (re)downloads + strips to text only when the cached
   # copy's date != today. Run it first, then grep the path it prints.
   python3 .claude/skills/webgpu-spec-lookup/update_spec.py
   grep -n -i "maxStorageBufferBindingSize" .claude/skills/webgpu-spec-lookup/webgpu-spec.txt
   

   The text keeps each heading prefixed [#anchor], so a grep hit traces back to a spec section (open https://www.w3.org/TR/webgpu/#<anchor> for the source). Use this for: exact feature names (the GPUFeatureName enum — e.g. timestamp-query, shader-f16, float32-filterable, depth32float-stencil8, texture-compression families), default and required limit values (GPUSupportedLimits), and whether a capability exists in the spec at all versus being a proposal. Quote the exact identifier and value.

You usually need both: the spec says what the feature is called and what it guarantees; the Chrome docs say whether it's actually available and where. Cross-browser nuance (Safari/Firefox) isn't covered by either — if the question hinges on a non-Chrome browser, say what the spec defines and what Chrome ships, and flag that the other browsers' status isn't in these sources (MDN/caniuse would be needed, and the user didn't point there).

Worked example: "are 64-bit atomics supported?"

Don't answer from memory. Fetch the spec to find the real feature name (64-bit integer atomics are gated behind a WGSL/feature flag, not baseline), then the Chrome "What's New" posts to see if/when it shipped or whether it's still experimental / flagged. Report the exact GPUFeatureName, the Chrome status, and that the user must feature-detect it (adapter.features.has(...)) — never assume presence.

Tie back to OGPU

When the platform answer affects engine code, connect it: Renderer.initDevice (src/core/Renderer.js) keeps a wantedFeatures wishlist and feature-detects each entry against adapter.features before requesting the device, dropping (and console.warn-ing) anything missing — so the engine boots anywhere but optional features may be absent at runtime. Any code path depending on a feature you just researched must guard on device.features.has(...) (precedent: TimingHelper gating 'timestamp-query'). See the "Browser floor" section of CLAUDE.md.

How to apply what you find

• Quote exact identifiers and values from the spec (feature names, limit defaults) rather than paraphrasing.
• State the Chrome version / flag / origin-trial status when support is the question, and cite which "What's New" post it came from.
• If the sources disagree with what you half-remember, trust the sources and say so. If a question can't be settled from these two (e.g. Safari timeline), say what's missing instead of guessing.