Conciseness

The body is dense, imperative, and assumes competence — no basic-concept explanations — with concrete thresholds like '60ms/test or 120ms/file' and exact paths ('tooling/config/test-suites.mjs'). It falls short of a 5 because of genuine duplication: the `createSlateEditor` bullet list appears verbatim in both 'Seam Selection' and the `core` package section, and the 'Quick Reference' section restates rules already stated above (two lanes, lcov over Bun summary, package-locality).

Actionability

Guidance is concrete and executable: exact commands ('pnpm test:slowest -- --top 25 --rerun-each 3', 'bun run test:profile'), exact file-naming conventions ('*.spec.ts[x]' vs '*.slow.ts[x]'), exact paths, and numeric coverage-pass thresholds ('>= 6', then '>= 5'). It is not a 5 because some instructions are named but never shown — e.g. 'table-drive repeated node-type cases', 'extract one editor helper', and the hyperscript fixture style have no example snippet, leaving the reader to invent the pattern.

Workflow Clarity

The coverage workflow is explicitly sequenced with passes (>= 6 pass, rerun fresh lcov, >= 5 pass, architecture-safety pass, then explicit stop criteria for wrappers/crumbs/sludge) and includes validation checkpoints and feedback loops (profile -> rename to *.slow.ts -> pnpm test:slowest hard gate). It falls short of a 5 because the workflow is distributed across four sections ('Testing Goal', 'Coverage Strategy', 'Cleanup Heuristics', 'Quick Reference') rather than presented as one coherent ordered procedure.

Progressive Disclosure

Sectioning is clean and there are no dangling or nested references, but the entire rulebook — including package-specific rules (`autoformat`, `markdown`, `slate`, `docx`), allowlists, and the upstream slate-react mining list — lives inline in one 250-line SKILL.md with no reference files at all. That matches 'content that should be separate is inline'; it is above a 2 only because the sections are well-organized and the in-body file paths (e.g. 'tooling/config/bunTestSetup.ts', 'apps/www/src/__tests__/package-integration') are real and clearly signaled.

Specificity

The description is only 'Skill: testing' — it names no concrete action or capability whatsoever (no layering strategy, no coverage workflow, no commands), which matches the 'entirely vague; no concrete actions' anchor. It cannot score 2 because even the domain-naming-with-minimal-actions example ('Processes PDF files') describes an action verb plus target.

Completeness

Neither 'what does this skill do' nor 'when to use it' is answered in any form — 'Skill: testing' is even vaguer than the anchor example 'Helps with documents'. The missing 'Use when...' clause alone would cap this at 3; here nothing is stated at all.

Trigger Term Quality

The single keyword 'testing' is one generic term with no natural variations users would say when they need this skill (e.g. 'write tests', 'test coverage', 'hotspot', 'bun test', 'spec'), matching the 'one or two generic keywords; missing the natural phrases' anchor. It is above a 1 only because 'testing' is a real natural-language term rather than pure jargon.

Distinctiveness Conflict Risk

The description is entirely generic — 'testing' would match virtually any testing-related request, giving maximal conflict risk with any other test-related skill. It cannot score 2 because even the 'very broad' anchor example at least names a file category.