Conciseness

The "Explain" section ("Explain how scrolljacking disrupts expected navigation patterns, interferes with assistive technologies, and creates unpredictable experiences for users with motor impairments or cognitive disabilities") repeats the opening paragraph nearly verbatim, and "Quick Reference" restates "Scrolljacking breaks assistive technologies and user expectations" already covered in the intro. Mostly efficient overall, but this duplication could be trimmed — below anchor 4's minor-trimming level, well above anchor 2's padded verbosity.

Actionability

Some concrete direction exists — "Check that scroll speed is not modified, scroll direction is not inverted, and scroll events are not hijacked" and "respect prefers-reduced-motion" — but the how is missing: no detection technique (e.g. searching for wheel/touchmove listeners calling preventDefault, or overscroll-behavior/scroll-behavior CSS), no commands, and no verification steps; the executable detail is entirely deferred to references/rule.md. This matches anchor 3's 'concrete guidance but incomplete, missing key details' rather than anchor 4's mostly-executable guidance.

Workflow Clarity

A clear Check → Fix → Explain → Code Review sequence with a verification checkpoint present ("note how to verify the fix with browser accessibility tooling or assistive tech"). Not 5 because the verification step is named but not concretely specified and "verify it feels native" is subjective; not 3 because the sequence is coherent and a fix-verification checkpoint is explicitly included.

Progressive Disclosure

A short (~30 line) body 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`" — and that file exists and indeed contains the implementation detail (bad-pattern code examples, definitions table). Content split between overview and reference is appropriate for a simple skill.

Specificity

Lists several concrete review actions — "Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output" — alongside the domain. Not 5 because coverage stops at inspection; what the skill produces (flagging violations, remediation guidance) is unstated, and the mid-sentence title reference "related to Avoid scrolljacking and custom scroll behavior" muddies the action statement. Clearly above anchor 3, which expects only 1-2 concrete actions.

Completeness

Explicitly answers both questions: when via "Use when reviewing rendered HTML, interactive components, or design-system patterns related to Avoid scrolljacking and custom scroll behavior" and what via the concrete check-then-inspect action sequence. The 'when' clause is explicit with concrete trigger contexts, matching the top anchor rather than the anchor-4 case where the 'when' is present but could be more specific.

Trigger Term Quality

Natural trigger terms include "scrolljacking", "custom scroll behavior", "rendered HTML", "interactive components", and "design-system patterns" — phrasings a user reviewing a page would plausibly say. Not 5 because common synonyms like the two-word "scroll hijacking", "parallax", "smooth scrolling", or "wheel events" are absent; not 3 since coverage is good rather than partial.

Distinctiveness Conflict Risk

The "scrolljacking" / "custom scroll behavior" niche is distinct, but generic a11y-review triggers like "keyboard behavior, focus flow, accessible names, and screen-reader output" and "design-system patterns" overlap with sibling accessibility review skills. Not 5 because those shared generic phrases could match other a11y rules; not 3 because the scroll-specific anchor term keeps the skill mostly distinguishable.