Conciseness

The ~30-line body is efficient: Quick Reference bullets, one-sentence Check/Fix sections, and a clearly signaled pointer to references/rule.md, with no padding or explanation of concepts Claude already knows. It is not a 5 because the "Explain" section ("Explain the catastrophic impact...") and the twice-repeated rule title inside the "Code Review" paragraph ("interactive states that affect Do not use aria-hidden on the document body") are trimmable filler.

Actionability

As an instruction-only skill the guidance is concrete: the Check names the exact element, attribute, and lifecycle scope ("the <body> element has aria-hidden=\"true\" applied at any point in the lifecycle"), and the Fix names the exact remedy and the correct alternative (background containers when modals are open). It is not a 5 because no inline verification command or code snippet is given — e.g. a selector to run or an axe/DevTools check — leaving the reader to construct the check themselves, and the "Explain" step is vague direction.

Workflow Clarity

The single task is unambiguous and well sequenced (Quick Reference → Check → Fix → Explain → Code Review), and the "Code Review" section references verifying the fix with browser accessibility tooling, satisfying the simple-skill case. It is not a 5 because verification is only gestured at ("note how to verify the fix with browser accessibility tooling") rather than given as an explicit checkpoint, and the overlapping Check/Code Review sections blur the sequence slightly.

Progressive Disclosure

The body is under 50 lines with well-organized sections and a single clearly signaled, one-level-deep reference ("For full implementation details, code examples, and framework-specific guidance, see references/rule.md") that exists in the bundle. Content is appropriately split — overview inline, examples and framework guidance in the reference file — so navigation is easy and nothing is inlined that belongs elsewhere.

Specificity

The description lists several concrete actions — "Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output" — which goes beyond naming the domain. It is not a 5 because the action list is review-procedural and omits the fix/report half of the skill's behavior, leaving minor gaps in coverage.

Completeness

Both parts are explicit: the what ("Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output") and the when ("Use when reviewing rendered HTML, interactive components, or design-system patterns"). It is not a 5 because the when-clause's trigger phrase "related to Do not use aria-hidden on the document body" inserts the rule title verbatim into the sentence, making the trigger grammatically awkward rather than a natural concrete trigger phrase.

Trigger Term Quality

Strong natural keywords are present: "aria-hidden", "the document body", "rendered HTML", "screen-reader", "interactive components". It misses common synonyms a user would naturally say — "accessibility", "a11y", "modal", "screen reader" as a noun phrase separate from output — so it falls short of the comprehensive anchor 5 but is well above anchor 3.

Distinctiveness Conflict Risk

The aria-hidden-on-body rule gives this a clear niche with distinct triggers, so conflict risk is low. It is not a 5 because the broad lead-in "reviewing rendered HTML, interactive components, or design-system patterns" overlaps with general accessibility-audit and modal/focus-management skills before the rule-specific narrowing kicks in.