Conciseness

The body is short and mostly lean, but there is real redundancy: the 'Explain' section ("Explain how autoplaying media interferes with screen readers, startles users...") restates the intro paragraph almost verbatim, and the Quick Reference bullets duplicate the Check/Fix content (e.g., the 5-second rule appears twice). This matches 'mostly efficient but includes some unnecessary explanation or could be tightened'.

Actionability

The Fix section gives genuinely concrete direction ("Remove autoplay attributes from media elements... add muted attribute and provide prominent, keyboard-accessible pause controls") and the 5-second stop rule is a concrete criterion. But the body contains no markup examples or selectors (e.g., video[autoplay]:not([muted])), and the Code Review section's "note how to verify the fix with browser accessibility tooling or assistive tech" is vague direction with no named tool or command — some concrete guidance but incomplete, with executable detail deferred to the reference file.

Workflow Clarity

The Check → Fix → Explain → Code Review sections give a coherent detect/fix/communicate/verify sequence for a single-purpose review task, and verification is mentioned ("confirm media is muted by default and pause controls are immediately accessible via keyboard"). Not a 5 because the verification step names no explicit method or tool, leaving the checkpoint implicit rather than a concrete feedback loop.

Progressive Disclosure

The body is a clear ~30-line overview with well-organized sections, and the single external reference is explicitly and accurately signaled: "For full implementation details, code examples, and framework-specific guidance, see references/rule.md" — the file exists and contains exactly that (HTML/TSX examples, framework guidance), one level deep with easy navigation.

Specificity

The description names several concrete actions — "Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output" — giving a real review procedure, though the actions are generic accessibility checks rather than autoplay-specific ones. Not a 5 because no action is specific to media autoplay (e.g., muted-by-default checks, 5-second stop rule), which the domain implies it covers.

Completeness

Both parts are explicitly 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 Avoid autoplaying media' trigger clause. Not a 5 because the 'when' clause is awkwardly phrased around the rule title and could name more concrete trigger situations.

Trigger Term Quality

"Autoplaying media" is a natural trigger phrase, but the most common words a user would say — "audio", "video", "sound", "muted" — are absent from the description. It has some relevant keywords ("rendered HTML", "keyboard", "screen-reader") yet misses the core synonyms, matching the 'some relevant keywords but missing common variations' anchor.

Distinctiveness Conflict Risk

"Avoid autoplaying media" carves out a niche, but the second sentence is generic boilerplate (native semantics, keyboard behavior, focus flow, accessible names) that would appear verbatim in many sibling accessibility-review skills, creating real overlap risk. Not a 2 because the autoplay trigger phrase does distinguish it from non-media a11y rules.