Run any Skill in Manus with one click

webgpu-spec-lookup

Stars125

Forks7

UpdatedJune 30, 2026 at 08:07

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.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

oframe

oframe/ogpu

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

2 files

SKILL.md

readonly

name

webgpu-spec-lookup

description

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:

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.
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.

More from this repository

same repository

naga-setup

oframe/ogpu

Get naga WGSL validation working in a repo — installs the `naga`/`jq` toolchain, a PostToolUse hook that compiles every .wgsl on write, and a batch validate-shaders script, so shader checking then happens automatically with no skill involved. Use for the setup act: "set up naga here", "add the shader validation hook", "wire up WGSL checking in my new repo", "port my naga setup over", scaffolding a fresh WebGPU project — and also on a fresh clone of a repo that already ships the hook, since the config arrives with the clone but the naga binary does not, leaving a hook that silently does nothing. Do NOT use this to validate a shader; validating is the installed hook's job or a plain `naga <file>`.

2026-07-22130

scaffold-shader

oframe/ogpu

Scaffold a new simple WGSL shader for the OGPU engine, wired for a RenderPipeline + Mesh. Use whenever the user wants to create a new shader, start a shader from scratch, add a .wgsl file for a mesh, get a shader boilerplate/template/starting point, or "make me a basic shader" / "scaffold a shader". Produces a minimal vs/fs WGSL file following the engine's reflection conventions, optionally with the JS pipeline wiring.

2026-07-22130

shadow-mapping

oframe/ogpu

Fold real-time shadow mapping into an existing RenderPipeline/shader in the OGPU engine. Use whenever the user wants cast shadows, a depth-pass / shadow-map shadow, a character or mesh to drop a shadow on a floor, self-shadowing, PCF soft shadows, "make it cast a shadow", "add shadows", or real-time shadows on a custom (skinned, displaced, instanced, IBL-lit) shader. Covers the depth-only caster pass + the receiver sampling fold.

2026-07-20130

scaffold-app

oframe/ogpu

Scaffold a new OGPU example/app from scratch — a Renderer + Camera + Orbit + update loop and a single spinning cube wired through the vanilla Box primitive -> RenderPipeline -> Mesh setup. Use whenever the user wants a new OGPU example, a base/starter scene, a blank WebGPU sketch in this repo, "scaffold an app", "new example called X", "boilerplate a OGPU scene", "set me up a starting point", or just "new scene"/"new example" when OGPU is the implied target. Generates the example class + shader and wires it into src/main.js so it boots at ?src=<name>.

2026-06-25130

pbr-shading

oframe/ogpu

Fold PBR/IBL shading into a RenderPipeline in the OGPU engine. Use whenever the user wants physically based shading, IBL, image-based lighting, metallic/roughness materials, an environment-lit mesh, "make this look like a real material", or wants to combine their own custom vertex/fragment work with the engine's PBR lighting. Also use when a mesh has no textures and needs sensible fallback (factor-only) material setup.

2026-06-25130

webgpu-utils-lookup

oframe/ogpu

Ground any answer about the webgpu-utils library (greggman/webgpu-utils) in its actual API before responding. Use whenever a question or task touches a webgpu-utils function, class, or option — makeShaderDataDefinitions, makeStructuredView, createBuffersAndAttributesFromArrays, createTextureFromImage(s)/Source(s), generateMipmap, primitives.*, setStructuredView, the reflected uniform/storage views, bind-group-layout generation, attribute/buffer creation, mip generation, or anything imported from 'webgpu-utils'. In the OGPU engine this library backs RenderPipeline, ComputeShader, Geometry, Texture, and IBLUtils, so it surfaces constantly — consult it before claiming a signature, option name, default, or behavior, rather than guessing from memory. Trigger even when the user doesn't name the library, if the symbol clearly belongs to it.

2026-06-25130

name

webgpu-spec-lookup

description

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

Sources

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

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.
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.

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

Tie back to OGPU

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.