Conciseness

The body is largely lean and assumes competence — the constants table, the failure-annotated rules, and the per-frame ordering are exactly what Claude cannot derive itself, with no filler explaining Three.js or ray marching basics. It falls short of the 5 anchor because of minor trimmable material: the version-pinned stack line ('Three.js r170') and the provenance/cost anecdotes ('Source: extracted from Blue Hour...', 'load average about 60') are context that doesn't change the action, and the rubric flags unpinned version numbers specifically.

Actionability

The integration path is mostly executable: a real copy step, a concrete import (verified against the actual bundle module's exports), an explicit uniforms object, `createUnderwaterLight` setup, and an ordered per-frame sequence. It sits at the 4 anchor rather than 5 because the water and fish shader integration is given as comments ('Declare uSunDirection... then add ${LIGHT_GLSL}${WATER_GLSL} and in main()...') rather than copy-paste-ready shader code, leaving the host to assemble the final materials.

Workflow Clarity

The sequence is explicit and ordered — copy the module, build shared uniforms, create the light before the materials, then 'Every frame, in this order' with the march, scene passes, and tone map — and the Verify section is a true validation checklist where each item includes a symptom-to-cause diagnostic ('If they move with the lens, they are painted in screen space'). This matches the 5 anchor's explicit validation steps with feedback for error recovery; the 4 anchor's 'minor validation gaps' does not apply.

Progressive Disclosure

Structure is good: a single clearly signaled one-level reference to the reusable module [assets/underwater-light.mjs](assets/underwater-light.mjs) — which exists and exports what the SKILL.md imports — with the bulk detail appropriately in that file and a compact overview inline. It falls below the 5 anchor because two of the three referenced paths ([The demo](demo/index.html) and `demo/build.mjs`) do not exist in the provided bundle, breaking navigation for a reader following those links.

Specificity

The description lists multiple concrete capabilities — 'marching one drifting swell field along every view ray at half resolution', 'light shafts converge on the sun', 'parallax with the camera', 'rippling caustic streaks', 'shimmering surface underside', 'the same light dappling fish' — each a specific, verifiable action rather than generic language. It matches the 5 anchor (multiple specific concrete actions, comprehensive coverage) and is clearly above the 4 anchor, which allows coverage gaps; every major effect component is named.

Completeness

Both questions are answered explicitly: the 'what' is the detailed first sentence (add god rays with specific rendering behaviors), and the 'when' is the explicit 'Use for underwater scenes, oceans seen from below, aquariums...' clause with concrete trigger phrases. This is the 5 anchor verbatim in structure; the 4 anchor's 'when could be more explicit' does not apply.

Trigger Term Quality

Trigger coverage is comprehensive and natural: 'underwater scenes', 'oceans seen from below', 'aquariums', 'reefs', 'kelp forests', 'diving and shipwreck scenes', 'schools of fish', 'sunbeams or light shafts through water', 'caustics', 'watery ripples', plus the quoted user phrase '"rays of light shining through the ocean"' and 'god rays' in the capability clause. This matches the 5 anchor (natural terms including synonyms); file extensions are not applicable to a scene-effect skill.

Distinctiveness Conflict Risk

The niche is clear — volumetric underwater god rays in Three.js — and every trigger term ('underwater', 'oceans seen from below', 'aquariums', 'caustics') is water-specific, so overlap with sky-ray or surface-water skills is minimal. It matches the 5 anchor (clear niche, distinct triggers, minimal conflict risk) rather than the 4 anchor, which requires some overlap risk with closely related skills.