Conciseness

The body is dense with non-obvious measured facts ("gain 0.14 laid a milky haze across the plaque", "turning the studio reflections off raised the total score by 0.14", exact ACES constants and bias values) and never explains concepts Claude already knows — no three.js tutorial prose, no explanation of what tone mapping or shadow maps are. Every line carries a constant, a failure mode, or a measured outcome, so every token earns its place.

Actionability

Guidance is copy-paste executable: exact commands ("npm i playwright-core", "node references/scorecard.mjs --url --size 1440x900 --dpr 1 --target 8 --no-ablate --sync"), exact light values ("Key DirectionalLight 0xfff2df, intensity 2.0, 4096 shadow map... normalBias 0.0045"), shader formulas ("smoothstep(0.02, 0.34, y)", ACES "a=2.51 b=0.03 c=2.43 d=0.59 e=0.14"), and a full constants table. Specific values cover the common cases completely; there is no pseudocode or hand-waving.

Workflow Clarity

Two clearly numbered sequences ("Build order" 1-6 and "Scoring loop" 1-5) with explicit validation checkpoints: "exit code 1 if any item is short", "Score the baseline before changing anything", "The ablation is the check on the metrics", and a feedback loop of "Fix the lowest item's cheapest sub-metric first, re-run at the same size and DPR, and keep only what the picture confirms". A closing "Verify" checklist (metrics block equals references/metrics.js, console clean at two sizes, scorecard JSON matches claims) completes the error-recovery loop.

Progressive Disclosure

Good structure: the overview keeps rules and constants inline while pushing detail one level deep to clearly signaled files ("the numbers are `references/`", "scores the eight items in `references/rubric.md`", "run `node references/scorecard.mjs`"), all of which exist in the bundle. However, the referenced `demo.html` — which the body names as "The demo is `demo.html`" and which the scorecard's --sync and default URL depend on — is absent from the actual bundle, leaving a navigation/executability gap that keeps this below a 5.

Specificity

Multiple specific concrete actions are listed: "Light carved wood in a dark room in three.js, with procedural grain and pores, one warm key through a window, soft shadows that touch, light shafts, background rays and dust", then "score the render out of 10 on an anchored rubric with a runnable headless scorecard and iterate until each item reaches the target" — comprehensive coverage in third-person imperative voice. It does not sit at 4 because there are no coverage gaps; every named capability is a distinct concrete action, matching the anchor-5 example's breadth.

Completeness

The "what" is explicit and concrete (light carved wood with a full inventory of lighting features, then score and iterate on an anchored rubric), and the "when" is an explicit "Use for..." clause with concrete trigger phrases including quoted requests. This matches the anchor-5 pattern of clearly answering both what and when with concrete triggers; 4 would need a vaguer 'when', which is not the case.

Trigger Term Quality

Natural triggers include domain synonyms ("oiled timber, kumiko, joinery and workshop scenes"), problem phrases a user would actually say ("wood that reads flat, plastic or washed out"), and literal quoted requests ("score this out of 10"; "get the lighting to 8"), plus the platform term "three.js". This is comprehensive natural-term coverage with synonyms and quoted user phrasing; 4 would require missing natural terms, and none are evident for this domain.

Distinctiveness Conflict Risk

A clear niche (three.js carved-wood interior lighting with a measurable scoring loop) with distinct triggers like "kumiko", "workshop scenes", and "volumetrics that lift the blacks"; conflict risk with generic rendering or scoring skills is minimal because every trigger is anchored to wood/lighting context. The quoted "score this out of 10" is scoped by the surrounding wood-lighting triggers, so it does not pull in unrelated skills.