Conciseness

The body is largely lean: terse one-line descriptions ('Illuminates all objects equally. No direction, no shadows.') followed by code. However, shadow bias/frustum configuration is duplicated between 'DirectionalLight Shadows' and 'Optimizing Shadows', and the RectAreaLightHelper import/example appears in both the RectAreaLight and Light Helpers sections. Fits anchor 4 (efficient, minor instances that could be trimmed) rather than 5.

Actionability

Nearly all examples are executable copy-paste code with concrete values (e.g., 'dirLight.shadow.mapSize.width = 2048', 'dirLight.shadow.bias = -0.0001', 'RectAreaLightUniformsLib.init()'). One defect: 'import { ContactShadows } from "three/examples/jsm/objects/ContactShadows.js"' — ContactShadows is a @react-three/drei component and does not exist in three's examples directory, so that snippet fails to import. Mostly executable with minor gaps = anchor 4, not 5.

Workflow Clarity

Shadow setup is presented as a clear numbered sequence ('1. Enable on renderer', '2. Enable on light', '3. Enable on objects') with error-recovery guidance for shadow acne via bias/normalBias, and helper update guidance. This is a reference skill without destructive or batch operations, so no validation cap applies; fits anchor 4 (clear sequence, most checkpoints present) rather than 5, which expects explicit validation loops.

Progressive Disclosure

The single file is well-organized with clear section headers and a Quick Start, but at ~480 lines it inlines everything: per-light shadow API detail, IBL, light probes, and animation would each fit a references/ file. The rubric's 50-line single-file exception does not apply, and no bundle references exist, so this matches anchor 3 ('content that should be separate is inline') rather than 4, which expects most bulk detail split out with clear references.

Specificity

The 'when' clause lists several concrete actions ('adding lights, configuring shadows, setting up IBL, or optimizing lighting performance'), but the 'what' half is stated as topic nouns ('light types, shadows, environment lighting') rather than concrete verbs. This matches anchor 4 (several specific actions, minor gaps) better than 5, whose example lists multiple concrete actions with comprehensive coverage.

Completeness

Explicitly answers both questions: the what ('Three.js lighting - light types, shadows, environment lighting') and the when ('Use when adding lights, configuring shadows, setting up IBL, or optimizing lighting performance') with concrete trigger phrases. It is not anchor 4, since the 'when' is fully explicit with specific triggers rather than needing more specificity.

Trigger Term Quality

Includes natural phrases users would actually say ('adding lights', 'configuring shadows', 'setting up IBL', 'optimizing lighting performance'). Common synonyms and variations like 'HDR', 'environment maps', or specific light names ('ambient light', 'spotlight', 'shadows not working') are missing, so it fits anchor 4 (good coverage, a few natural terms missing) rather than 5.

Distinctiveness Conflict Risk

'Three.js lighting' establishes a clear niche, and all triggers (shadows, IBL, lighting performance) are lighting-specific and would not plausibly fire a materials, textures, or post-processing skill. Minimal conflict risk matches anchor 5 rather than 4's 'minor overlap risk with closely related skills'.