Conciseness

The body is compact, but the Quick Reference bullets ("Tooltips must have an accessible name or be referenced by `aria-describedby`") nearly duplicate the Check section ("Verify that all elements with role="tooltip" have an accessible name or are linked... via aria-describedby"), and the "Code Review" section is generic boilerplate that largely restates the description. This is mostly efficient but could be noticeably tightened, matching anchor 3 rather than the minor-trim profile of anchor 4.

Actionability

The Check section is concrete (specific role="tooltip" and aria-describedby attributes to look for), but the Fix section — "Assign an accessible name to the tooltip or ensure it is correctly referenced" — never states how (e.g., aria-label) and the body includes no correct/incorrect markup example, deferring all specifics to the reference. Some concrete guidance but missing key executable details (anchor 3); anchor 4 would require concrete code or commands in the body with only minor gaps.

Workflow Clarity

This is a simple, single-purpose review skill under 50 lines, and the single action is unambiguous: Check states exactly what to verify (tooltip elements have an accessible name or an aria-describedby association). The Quick Reference → Check → Fix → Explain → Code Review sequence is clear and well-organized, so the simple-skill exception applies.

Progressive Disclosure

The body is a concise overview with a clearly signaled one-level-deep reference — "For full implementation details, code examples, and framework-specific guidance, see `references/rule.md`" — and that file actually exists with exactly that class of content (code examples, why-it-matters, exceptions, verification steps). Content is appropriately split between overview and reference with easy navigation.

Specificity

Quotes several concrete actions — "Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output" — which are specific inspection actions. Not a 5 because the capability is stated only through the awkwardly embedded clause "related to Provide accessible names for tooltips" and the actions are all inspection/review verbs with no fix-side coverage, leaving minor gaps.

Completeness

Both parts are explicitly present: the trigger clause "Use when reviewing rendered HTML, interactive components, or design-system patterns related to..." answers 'when', and "Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output" answers 'what'. Not a 5 because the core 'what' (verifying tooltip naming/association) is buried in the templated "related to Provide accessible names for tooltips" clause rather than stated as a concrete capability.

Trigger Term Quality

Includes natural phrases users would say — "rendered HTML", "interactive components", "tooltips", "accessible names", "screen-reader" — but omits the most common natural terms for this domain: "accessibility", "a11y", "ARIA", and "aria-describedby". This is good coverage with a few natural terms missing (anchor 4), not comprehensive synonym coverage (anchor 5).

Distinctiveness Conflict Risk

The tooltip-specific trigger ("Provide accessible names for tooltips") carves out a clear niche with minimal conflict risk against unrelated skills. Not a 5 because the generic review-protocol boilerplate ("Check native semantics first, then inspect keyboard behavior, focus flow, and screen-reader output") would read identically across sibling accessibility skills, creating overlap risk with closely related a11y rules.