Conciseness

The body is dense and assumes competence — no basic-concept padding, every section teaches repo-specific machinery ("silver reads staging through the union_by_tag macro", "MIN_PEER_N in domain/metric_results/compiler.rs"). A few sections run longer than needed for a working author (the per-module isolation/clearing internals and several gotchas spell out behavior the library already enforces), fitting anchor 4 ("minor instances of over-explanation that could be trimmed") rather than 5.

Actionability

Fully executable, copy-paste-ready guidance: complete runnable commands ("uv run --project tests --frozen --group datapath --no-group dev python -c …", "./dev-compose.sh test-stand test --tree=tests/datapath/metrics/<class> --instance=datapath -q") and full worked templates (the module example, the bronze/description YAML shapes, the identity_aliases block) cover the common cases. Matches anchor 5 exactly; not a 4 because the templates are complete rather than having gaps.

Workflow Clarity

"Scaffolding a new test" is a numbered 1–6 sequence, "Validating a test (no stand needed)" gives explicit validation commands, and "Gotchas" supplies error-recovery feedback ("Let the run finish, then re-run"; "Lint before or after, never during"). Validation checkpoints are explicit, so the batch/destructive cap does not apply — this is the anchor-5 pattern (checklist + explicit validation + recovery loops).

Progressive Disclosure

No bundle files exist, and the body is a well-sectioned single file whose outward references are one level deep and clearly signaled ("Source of truth (reference — open only if you need the detail)" → tests/lib/insight_datapath/ and worked example specs). At ~450 lines, though, content that could live in reference files — the full format spec, the date-window design section, the complete module template — is inlined, which fits anchor 4 ("good structure; minor organization gaps") better than 5.

Specificity

"Author and validate a metric spec" plus a concrete artifact list ("tests/datapath/metrics/<class>/<name>.test.yaml fixture + test_<name>.py module, run against a compose test-stand instance", "POST /v1/metric-results", "assertion helpers (row/equals/contains, one/some over a view, approx)") names multiple specific concrete actions with comprehensive coverage — matching the anchor-5 example's breadth. It is not a 4 because the actions and artifacts named leave no minor gaps in what the skill does.

Completeness

It explicitly answers both what ("Author and validate a metric spec for the data-path suite…") and when ("Use when asked to…") with concrete trigger phrases — the exact anchor-5 pattern. Not a 4: the 'when' clause is explicit and enumerates specific triggering requests rather than being merely present.

Trigger Term Quality

"Use when asked to write/scaffold/validate a test for a metric, seed bronze data for a test, add a fixture for a dashboard metric, or check a spec" covers natural phrasings with synonym variations (write/scaffold/validate; test/fixture/spec) and concrete file paths. Anchor 5 asks for comprehensive natural-term coverage including synonyms — these are the phrases a user of this repo would actually say.

Distinctiveness Conflict Risk

The deep niche (data-path metric specs, compose test-stand, /v1/metric-results) makes it mostly distinct with minimal conflict risk, but the tail phrases "check a spec" and "validate… a test" are generic enough to overlap with other testing skills (e.g. the quality-vector-tests skill it references). This fits anchor 4 ("mostly distinct; minor overlap risk with closely related skills") better than 5, whose triggers are all unambiguous.