Conciseness

The body is dense and imperative with zero padding of concepts Claude already knows; every line carries a project-specific constraint Claude could not infer, e.g. "Never relabel imported geometry as img2threejs", "Do not claim a GLB or texture exists because code declares a future URL", and "Ground from foot/contact geometry, not the lowest weapon tip". Not 4 because there is no over-explanation anywhere to trim — every token earns its place.

Actionability

Concrete, executable guidance dominates: "Run `scripts/validate_pair.py <png> <model-source>`", "Store project-bound output under `public/asset-catalog/<category>/`", "Normalize catalog copies to 512×512 RGBA", "Attach equipment to named sockets". Not 5 because step 6 says "Run build, lint, full tests" without naming the actual commands, and much of the guidance is constraints rather than copy-paste-ready code — minor gaps, not missing steps.

Workflow Clarity

Seven clearly ordered steps with a dedicated validation step (6) covering the validation script, inventory tests, deterministic motion testing, build, lint, full tests, `git diff --check`, and browser verification, plus a handoff contract in step 7 ("Commit the narrow task and hand off its exact SHA"). Not 5 because there is no explicit error-recovery loop — nothing like "if validation fails, fix and re-validate" — even though step 6 is otherwise a thorough checkpoint; not 3 because validation checkpoints are very much present and explicit.

Progressive Disclosure

The body is a compact overview that keeps exactly one clearly signaled, one-level-deep reference: "Read [references/catalog-contract.md](references/catalog-contract.md) when changing catalog types, provenance language, or review-route behavior" — the referenced file exists and covers precisely those topics (surface mapping, provenance language, grounding, browser proof), and `scripts/validate_pair.py` exists at the cited path. Not 4 because there are no organization gaps: navigation is trivial, the split is appropriate, and no content that belongs in the reference is inlined.

Specificity

Multiple concrete actions are listed: "Build truthful Vesperfall asset-library review pairs from transparent PNG references and live Three.js, FBX, or img2threejs models", "creating a card-PNG plus inspector-model treatment", "exposing an isolated model or moveset route", "standardizing provenance, grounding, tests, and Codex-browser validation". Not 4 because coverage spans build, create, expose, and standardize comprehensively rather than leaving minor gaps.

Completeness

Both halves are explicit: the "what" is "Build truthful Vesperfall asset-library review pairs..." and the "when" is a full "Use when..." clause with concrete triggers ("adding a character, enemy, prop, or equipment asset to the Vesperfall catalog; creating a card-PNG plus inspector-model treatment; exposing an isolated model or moveset route"). This matches the 5 anchor exactly.

Trigger Term Quality

Good natural-term coverage: "character", "enemy", "prop", "equipment asset", "catalog", "card-PNG", "inspector", "moveset route", "provenance", "grounding", plus file formats PNG/FBX. Not 5 because a few natural terms a user would plausibly say are absent (e.g. GLB/GLTF, "3D model", "preview", "asset library" as a plain phrase); not 3 because coverage includes many concrete natural phrases and synonyms, not just a couple of keywords.

Distinctiveness Conflict Risk

The description carves out a clear niche — the project-named "Vesperfall asset-library review" domain with terms like card-PNG, inspector-model, moveset route, and provenance language — so it is highly distinguishable and unlikely to trigger for unrelated skills. Not 4 because the project-specific vocabulary leaves essentially no overlap risk with generic asset or catalog skills.