Shader for Interfaces

What It Does

Shader for Interfaces is a doc-only Agent Skill by v2space-labs (Joshua Guo): one 100-line SKILL.md routing to 11 reference files (808 lines, 26 to 140 each) with no scripts and no runtime dependencies. When a coding agent loads it, the skill turns "add a shader effect to this interface" into a governed workflow: decide the renderer first (CSS, SVG, or Canvas 2D before any GPU option), write a visual contract naming the effect's UI role and protected content, build a no-post baseline, integrate the canvas without breaking layout or accessibility, and pass a 9-item browser gate before claiming completion. The skill handles contained Three.js/WebGL2/GLSL and vgpu/WebGPU/WGSL surfaces and explicitly refuses dependent render passes, ping-pong feedback, persistent simulations, adaptive-quality controllers, and renderer migrations. The intended user is a frontend or product developer whose agent touches GPU effects in shipped interfaces, in TypeScript or React.

The Good

The scope discipline is the product, and it is rare. The first thing the skill does is try to keep the effect out of the GPU: effect-selection.md is a decision ladder (CSS backgrounds, then SVG, then Canvas 2D, then fullscreen GLSL, then Three.js, then vgpu) with an explicit "escalate when" condition per rung and a reject-GPU rule when a small CSS or SVG implementation is credible. Every other shader skill in the registry jumps straight to WebGL. The refusal list is stated identically in SKILL.md, README, and two references, and the entrypoint orders the agent to name features outside scope and "never present a partial advanced system as complete" rather than half-delivering a simulation.

Every machine-checkable library claim is true. GearScope installed the real packages the skill documents and tested each claim: three.js 0.185.1 ships the tonemapping_fragment and colorspace_fragment ShaderChunks, the compileAsync and checkShaderErrors renderer methods, the SRGBColorSpace, NoColorSpace, and GLSL3 constants (all confirmed). The vgpu@0.3.1 reference cites error codes verbatim, and both strings (VGPU-SURFACE-NOT-IN-FRAME, VGPU-DEVICE-LOST) exist in the installed package. The documented CLI commands run as written: npx --no-install vgpu docs cat getting-started.md returned 5,972 bytes, and vgpu check prints Usage: vgpu check [--require-validation] exactly as the validation section describes. The reference is also honest about decay: it pins claims to "vgpu@0.3.1" by name and tells the agent to read the lockfile-pinned package docs instead of the live website.

The integration and accessibility contract is deeper than most vendor packs. ui-integration.md covers pointer-events pass-through, pointercancel and lost pointercapture, touch-scroll takeover, webglcontextlost and webglcontextrestored, a three-way canvas classification (decorative, content-bearing, interactive) with distinct ARIA treatment, and context budgets for repeated components in long lists. performance-accessibility.md defaults to reduced motion, cites WCAG 2.2 pause-stop-hide and animation-from-interactions with live W3C links (both returned HTTP 200, as did all 10 external links in the repo), and measures page outcomes like Interaction to Next Paint alongside frame time. color-direction.md closes with a 13-item acceptance checklist including grayscale, forced-colors, and runtime theme-switch checks.

The anti-slop color stance has the right nuance. color-direction.md bans the default cluster (unprompted purple-to-cyan gradients, neon-on-dark glow, glass cards) while stating plainly that "purple is not banned" when a product, material, or data source justifies it, requires a one-sentence palette rationale before implementation, and links the impeccable.style slop catalog alongside WCAG, USWDS, and D3 scale-chromatic as sources. This is the same design-taste position GearScope has only seen in dedicated design skills, applied here to the GPU layer specifically.

Install integrity is clean across agents. The README-verbatim install command works non-interactively (exit 0, lands files, no interactive picker stall), and explicit --agent claude-code and --agent hermes-agent runs both landed a 15-file, 112 KB skill directory byte-identical to the repo clone, with a skills-lock.json pinning the source to a sha256 content hash for reproducible reinstalls.

The Bad

Three days old, single author, zero third-party signal. The repo was created 2026-08-30, has 4 commits from one contributor (jshguo-labs), no forks, no issues, no pull requests, and one tag. The 79 stars are launch velocity from the pipeline's scan #194 flag, not validation. Nothing in the repo shows the contract being executed by an agent on a real project: no committed example runs, no eval harness, no worked before/after case. The entire value proposition is unproven in live sessions, which is exactly why Functional-Verified is partial.

A visual-effects skill with zero visuals. There are no screenshots, no demo HTML, no rendered examples of any effect the skill governs. The agent must imagine outcomes purely from prose, including still-frame composition judgment that the browser gate demands. Comparable skills ship evidence: archify commits rendered examples for every diagram mode, and even the one-file ip-as-logo skill ships a showcase image. One committed example page would make the visual contract concrete.

The deepest reference targets a pre-1.0 moving API. vgpu-wgsl.md is the largest reference (126 lines) and pins concrete advice to vgpu@0.3.1 specifics: compile() signature rules, binding ownership categories, error-code behavior. The skill itself states vgpu is pre-1.0 and its API can change. The mitigation (package-local docs, lockfile-first resolution, a companion vgpu skill by Vercel Labs) is the correct pattern, but version-specific prose still decays with every vgpu release, and nothing in the repo automates re-verification.

Registry absence and thin metadata. The skill is not on the skills.sh registry (a fuzzy search for shader-for-interfaces returns entries from five other sources and zero v2space entries), so discovery is GitHub-only. The frontmatter carries only name, description, and license: no version field even though the README claims 0.1.0, no OpenClaw metadata, no related-skills pointers to the vgpu companion it references in prose. A Polar.sh funding link sits in .github/FUNDING.yml on day 3, which is legitimate but notable ahead of any usage evidence.

Smoke Test Results

Host-based validation on macOS 26.5.2 (aarch64, Node 24.13.1) against a fresh clone (12 markdown files, 920 lines, 268 KB; repo state at test time: 79 stars, 0 forks, 0 open issues, MIT, created 2026-08-30, pushed 2026-09-01, tag v0.1.0). The sbx sandbox daemon was not authenticated in this session, so all checks ran directly on the host per the doc-only methodology, with full output captured to the logs referenced below. Real commands, real output.

Structural validation

$ python3 structure-checks.py: LICENSE present and MIT
✅ PASS (1,067 bytes)
$ python3 structure-checks.py: frontmatter has name + description + license
✅ PASS (name=shader-for-interfaces, license=MIT)
$ python3 structure-checks.py: frontmatter name matches repo slug
✅ PASS
$ python3 structure-checks.py: description under 1024 chars
✅ PASS (479 chars, use and do-not-use routing clauses)
$ python3 structure-checks.py: SKILL.md under 500 lines
✅ PASS (100 lines, 12,416 bytes)
$ python3 structure-checks.py: all SKILL.md routing-table links resolve
✅ PASS (11 of 11)
$ python3 structure-checks.py: inter-reference cross-links resolve
✅ PASS (7 links across 4 files)
$ python3 structure-checks.py: no orphan reference files
✅ PASS (all 11 routed from SKILL.md)
$ python3 structure-checks.py: no secret patterns in repo
✅ PASS (clean)
$ python3 structure-checks.py: README install command uses correct slug
✅ PASS
$ python3 structure-checks.py: README version claim matches tag
✅ PASS (0.1.0, tag v0.1.0)
$ python3 structure-checks.py: FUNDING.yml parses
✅ PASS (custom Polar.sh link)
$ python3 structure-checks.py: external links live
✅ PASS (10 of 10 HTTP 200: three W3C WCAG pages, USWDS, D3, threejs.org manual, impeccable.style, both vercel-labs/vgpu URLs)
$ python3 structure-checks.py: scope boundary stated in SKILL.md and README
✅ PASS (identical exclusion list)

Pass rate: 14 of 14. The doc-only structure is fully self-consistent: every routing target exists, no reference is orphaned, and every external citation resolves.

Full structural log →

Install verification

$ README-verbatim install, stdin closed (npx skills@latest add v2space-labs/shader-for-interfaces --skill shader-for-interfaces --yes)
✅ PASS (exit 0, lands .agents/skills/shader-for-interfaces/, no picker stall)
$ explicit claude-code target (--agent claude-code --copy --yes)
✅ PASS (SKILL.md at .claude/skills/shader-for-interfaces/)
$ installed SKILL.md byte-compared to clone
✅ PASS (identical)
$ references landed
✅ PASS (11 of 11 files)
$ explicit hermes-agent target (--agent hermes-agent --copy --yes)
✅ PASS (SKILL.md at .hermes/skills/shader-for-interfaces/)
$ hermes copy byte-compared to clone
✅ PASS (identical)
$ skills-lock.json written
✅ PASS (sha256 45c11a68cf6a..., sourceType github)

Pass rate: 7 of 7. Installs are clean and reproducible on both tested agent targets plus the default .agents path, 15 files and 112 KB per install.

Full install log →

Functional verification

Verified the skill's version-specific claims against the real libraries it documents (three 0.185.1 and vgpu 0.3.1 installed from npm in a scratch project).

$ npm view vgpu@0.3.1 version (version cited throughout vgpu-wgsl.md)
✅ PASS (0.3.1, also the latest)
$ three.ShaderChunk tonemapping_fragment exists (glsl-patterns.md output-chunk claim)
✅ PASS
$ three.ShaderChunk colorspace_fragment exists (glsl-patterns.md output-chunk claim)
✅ PASS
$ renderer.compileAsync exists (first-frame warm-up claim)
✅ PASS (this-method in three 0.185.1 build)
$ renderer.debug.checkShaderErrors exists (diagnostics claim)
✅ PASS
$ three.SRGBColorSpace export (textures-and-distortion.md claim)
✅ PASS ("srgb")
$ three.NoColorSpace export (data-texture claim)
✅ PASS
$ three.GLSL3 enum (GLSL3 output-alias pattern)
✅ PASS ("300 es")
$ VGPU-SURFACE-NOT-IN-FRAME error code real in installed vgpu@0.3.1
✅ PASS (verbatim string present)
$ VGPU-DEVICE-LOST error code real in installed vgpu@0.3.1
✅ PASS (verbatim string present)
$ vgpu contained-renderer API surface (init, surface, effect, draw, frameLoop, clock)
✅ PASS (all exported)
$ TargetSignature type real (compile() signature claim)
✅ PASS (present in shipped types)
$ npx --no-install vgpu docs cat getting-started.md (documented command, run as written)
✅ PASS (exit 0, 5,972 bytes)
$ vgpu check command exists (validation-gate claim)
✅ PASS (Usage: vgpu check <file.wgsl>)
$ --require-validation device-backed flag real
✅ PASS (documented in help)

Functional pass rate: 15 of 15. Notably, vgpu's export list also contains pingPong, pingPongStorage, and compute, capabilities the skill deliberately excludes from its own scope. The boundary is the skill's choice, not the library's limit, and the docs never confuse the two.

Full functional log →

What the runs tell you

The structure is airtight, the installs are byte-perfect, and every claim that can be checked without a live coding agent is true, including exact error-code strings in a pinned dependency. What no run can show is the thing that matters most: whether an agent given this contract produces better interface effects, which requires a real project session and is the honest limit of this review.

Setup Walkthrough

1. Run the README command verbatim: npx skills@latest add v2space-labs/shader-for-interfaces --skill shader-for-interfaces --yes. It works non-interactively and lands in .agents/skills/, or add --agent claude-code / --agent hermes-agent (verified byte-identical for both).
2. Start a new conversation so the agent rescans skills, then describe the task naturally ("decide whether this hero effect needs WebGL") or invoke the skill by name. The skill routes itself into Recommend, Diagnose, or Build mode.
3. Nothing else installs at setup: the skill has no runtime dependency. Three.js, R3F, or vgpu enter only if your project already uses them or the renderer decision justifies adding one, and the skill's effect-selection ladder will argue for CSS first.
4. Optional: if you use the WebGPU path, install vgpu in the target project (npm install vgpu) and, if you want the version-matched companion, the Vercel Labs vgpu skill. The shader-for-interfaces references work without it.

Post-install gotcha: the frontmatter has no version field, so agents that display skill versions will show none even though the README and git tag say 0.1.0.

Alternatives

1. vercel-labs/vgpu generated skill: the version-matched vgpu companion, generated from the package's own docs (575 skills.sh installs). Prefer it when WebGPU is already chosen and you want API reference depth without the product-integration framing; this skill explicitly defers to it as a companion.
2. bbeierle12/skill-mcp-claude shader family (shader-effects 202, shader-fundamentals 161, shader-noise 108, shader-sdf 89 installs): teaching-oriented GLSL knowledge across five split skills. Prefer for learning shader math; none of them cover renderer choice, UI integration, or accessibility.
3. nexu-io/open-design shader-dev (2,303 installs) and minimax-ai/skills shader-dev (2,219): shader skills bundled inside larger design suites. Prefer when the shader work is one lane of a broader design-agent workflow and you accept suite-level coupling.
4. pbakaus/impeccable (reviewed 2026-08-04, 4.5/5): deterministic anti-pattern detection for the DOM and CSS side of design. It complements rather than replaces this skill: impeccable audits the page, shader-for-interfaces governs the canvas.