Conciseness

The ~30-line body assumes Claude's competence — no explanations of what HTML or headings are — with each section delivering one directive ("Find any heading tags (h1 through h6) that are empty or contain only non-perceivable whitespace"). It falls at anchor 4 rather than 5 because the Quick Reference bullets ('Add visible, descriptive text to all heading elements', 'Avoid using headings solely for styling...') partially duplicate the Check/Fix sections and could be trimmed, and the Explain section is a meta-instruction that adds little.

Actionability

For an instruction-only skill the guidance is actionable: the Check gives a specific criterion (headings h1-h6 that are empty or whitespace-only), and the Fix gives two concrete options ("Add descriptive text content to the empty heading or remove the heading tag if it's not needed"), with executable code examples delegated to references/rule.md. It stays at 4 rather than 5 because no concrete detection mechanism (e.g., a selector like h1:empty, an axe/Lighthouse rule, or a grep pattern) is given inline — a minor gap per the instruction-only scoring note.

Workflow Clarity

The Check → Fix → Explain → Code Review sequence is coherent and the single action (find and fix empty headings) is unambiguous, with Code Review gesturing at verification ("note how to verify the fix with browser accessibility tooling or assistive tech"). It is not 5 because the verification step is vague — no specific tool or check is named — matching anchor 4's 'clear sequence with most checkpoints present; minor validation gaps'. No cap applies since this is not a destructive or batch operation.

Progressive Disclosure

The body is a lean overview with well-organized sections (Quick Reference, Check, Fix, Explain, Code Review) and a single, clearly signaled, one-level-deep pointer: "For full implementation details, code examples, and framework-specific guidance, see `references/rule.md`" — the file exists (63 lines with good/bad HTML examples) and nothing is nested further. This matches the anchor-5 pattern exactly.

Specificity

The description names the domain and a few review actions ("Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output"), but these are generic accessibility-review actions rather than heading-specific ones — it never states what the skill actually does about empty headings (e.g., flag or fix them). It matches anchor 3 (domain plus 1-2 concrete actions, not comprehensive) rather than 4, which would require several specific actions covering the skill's actual capabilities; it is above 2 because the actions are concrete, not minimal.

Completeness

Both parts are present: the "what" ("Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output") and an explicit "Use when reviewing rendered HTML, interactive components, or design-system patterns related to Ensure headings contain text" trigger clause. It falls short of the anchor-5 example because the trigger conditions are broad template language rather than concrete phrases users would naturally say (e.g., "when you find empty h1-h6 tags"), and the "what" is generic review boilerplate; it is clearly above 3 since the 'when' is explicit, not weakly implied.

Trigger Term Quality

Trigger terms include "reviewing rendered HTML", "interactive components", "design-system patterns", and the rule name "Ensure headings contain text", but natural user phrasings like "empty heading", "heading has no text", "a11y", or "screen-reader navigation" are missing. This fits anchor 3 (some relevant keywords, missing common variations/synonyms) — better than 2 because the terms are domain-relevant, short of 4-5 because the key synonyms a user would naturally say are absent.

Distinctiveness Conflict Risk

The rule-specific phrase "related to Ensure headings contain text" carves out a clear niche, but the rest ("reviewing rendered HTML, interactive components, or design-system patterns... Check native semantics first, then inspect keyboard behavior, focus flow, accessible names...") is boilerplate that would equally match sibling accessibility-rule skills, creating minor overlap risk with closely related skills — fitting anchor 4 rather than 5.