fix(skills): every team-template skill binding now resolves

55 of 85 role skill bindings pointed at skills that were never authored,
so 10 of 11 team templates bound a smaller context bundle than their role
prompts assumed. Three roles bound nothing at all (gpu.bench_engineer,
threejs.shader_author, threejs.perf_engineer) while their prompts described
procedures they had no way to read.

The loader comment at team_template_loader.rs:167 already diagnosed this —
snake_case slugs in TOML against kebab-case skill files — and it was
half-fixed: the kebab names were corrected, the snake_case ones left.

It was invisible because both existing tests assert authored ⊆ referenced
(30/30, green) and the second explicitly declines to check the other
direction. So the failing half was the half nobody asserted.

Resolved every name by one of three explicit choices:

  - 23 skills authored where the role genuinely needed the procedure
    (gpu, threejs, research, analysis, frontend, mobile, backend, platform)
  - renames onto authored skills where one existed in substance, including
    the four-near-duplicate cases that collapse onto one real skill
  - 22 aspirational references deleted — a binding an agent cannot read is
    a promise, not a capability

Two tests now hold it. The unit test checks referenced ⊆ authored against
the files. The new integration test runs both loaders in boot order and
asserts the bindings survive the trip through the database, which is a
different question: resolution goes through skills_catalog rows, so a skill
file that exists but fails to ingest still leaves the role empty.

Negative controls: the unit test failed naming all 55; the integration test
fails naming the exact role when one name is reverted.

threejs.shader_author and .perf_engineer gained a second and third skill
after the collapse — pin_in_context pins idx < 2, so a role left with one
skill silently pins less than the policy intends.

Co-Authored-By: Claude Opus 5 <[email protected]>

skills/threejs/shader-authoring-glsl-wgsl.md

@@ -0,0 +1,55 @@
+---
+name: shader-authoring-glsl-wgsl
+description: Writing GLSL and WGSL shaders that compile on both, and the precision and uniform traps that only appear on some hardware.
+when_to_use: You are the shader author on a three.js/WebGL team, writing or porting a shader.
+tags: [threejs, shaders]
+---
+
+# GLSL and WGSL are the same ideas, spelled differently
+
+WebGL2 takes GLSL ES 3.0; WebGPU takes WGSL. Porting is mostly mechanical, and
+the mechanical parts are not where the bugs are.
+
+| | GLSL ES 3.0 | WGSL |
+|---|---|---|
+| entry | `void main()` | `@fragment fn fs_main(...) -> @location(0) vec4f` |
+| varyings | `in`/`out` at global scope | struct fields with `@location(n)` |
+| uniforms | `uniform` block | `var<uniform>` in a bind group |
+| texture | `texture(sampler2D, uv)` | `textureSample(t, s, uv)` — texture and sampler are SEPARATE |
+| vec | `vec3` | `vec3f` (alias of `vec3<f32>`) |
+
+The separated texture/sampler split is the one that changes structure: WGSL
+binds them independently, so a GLSL shader using four samplers becomes four
+textures plus (often) one shared sampler.
+
+## Precision is not decoration
+
+`mediump` in a fragment shader means **at least** 10 bits of mantissa, and on
+mobile GPUs it means exactly that. A computation that is fine on a desktop
+where `mediump` is silently promoted to 32-bit will band, banding-clamp or
+NaN on a phone.
+
+Rules that avoid the whole class:
+- World-space positions and time accumulators are `highp`. Always. A `mediump`
+  time uniform visibly stutters within minutes of page load.
+- Normalise in `highp`, then downcast.
+- Test on a real mobile device or an emulator that honours precision. Desktop
+  Chrome will not show you this bug.
+
+## Uniforms are a budget
+
+Each uniform, varying and texture unit is a hardware-limited slot, and the
+limits are much lower than desktop defaults suggest (`MAX_VARYING_VECTORS` can
+be 8). Pack related scalars into a `vec4` rather than declaring four floats, and
+query the limits rather than assuming.
+
+## Shader compile errors are silent by default
+
+three.js logs a compile failure to the console and renders black. That is
+indistinguishable from a material bug, a camera bug or a culling bug. When
+something renders black, check the shader log FIRST — it is a two-second check
+that eliminates a large fraction of the search space.
+
+Keep a flat-colour fallback: a shader that fails to compile should show
+magenta, never black. Black is a colour the scene might legitimately be;
+magenta is not.