Conciseness

The body is short but noticeably redundant: the 'Quick Reference' bullets restate the intro ('Autofocus disrupts screen reader users who lose page context') and the Check/Fix sections, and the 'Code Review' section largely repeats the frontmatter description ('Review the rendered markup and interactive states that affect Avoid autofocus on form fields'). This fits 'mostly efficient but includes some unnecessary explanation or could be tightened' rather than anchor 4's 'minor instances', since whole sections are duplicative; it is far from anchor 2's heavy padding.

Actionability

Concrete, executable instruction-only guidance: 'Search for autofocus attributes on form elements', 'Remove autofocus attributes from form elements', 'use JavaScript to set focus after user interaction rather than automatically on page load'. Per the code-vs-instruction note, absent code is not penalized since the guidance is actionable; minor gaps remain (no grep pattern, no named browser a11y tooling) keeping it below 5 but above anchor 3's 'incomplete, missing key details'.

Workflow Clarity

A clear implied sequence — Check (find autofocus, verify focus doesn't jump on load) → Fix (remove attribute / JS focus after interaction) → Explain → Code Review (flag elements, 'note how to verify the fix with browser accessibility tooling') — with the verification step present but generic. Not 5 because verification names no specific tool or procedure; not 3 because the sequence and its verify step are explicit rather than missing.

Progressive Disclosure

The body is a concise overview and cleanly delegates detail with a well-signaled, one-level-deep reference — 'For full implementation details, code examples, and framework-specific guidance, see references/rule.md' — and references/rule.md exists as a real 131-line file with code examples and framework guidance. This matches the anchor for a clear overview with appropriately split content and easy navigation.

Specificity

Names several concrete actions — 'Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output' — which are specific review procedures, though they are generic a11y-review actions not unique to autofocus. This fits 'lists several specific actions; minor gaps in coverage' rather than score 3 (only 1-2 actions) and falls short of 5 (no autofocus-specific actions like 'search for autofocus attributes' or 'remove the autofocus attribute').

Completeness

Both parts are present: an explicit 'Use when reviewing rendered HTML, interactive components, or design-system patterns related to...' trigger and a 'what' (check semantics, inspect keyboard behavior, focus flow, accessible names, screen-reader output). Not score 5 because the 'what' reads as generic inspection steps rather than concrete capability statements, and the trailing 'where relevant' hedges; not score 3 because both what and when are explicit.

Trigger Term Quality

Good natural keyword coverage: 'autofocus', 'form fields', 'rendered HTML', 'keyboard behavior', 'focus flow', 'screen-reader', 'accessible names'. Missing some common variations users would say ('focus on page load', 'autofocus attribute', 'login page focus') and the phrasing 'related to Avoid autofocus on form fields' awkwardly restates the title rather than adding natural terms — fits anchor 4, not 3 (keywords are more than 'some relevant') and not 5 (synonym coverage is incomplete).

Distinctiveness Conflict Risk

The rule-specific phrase 'Avoid autofocus on form fields' carves a clear niche, but the boilerplate opening 'Use when reviewing rendered HTML, interactive components, or design-system patterns' would identically match sibling accessibility-rule skills, creating minor overlap risk with closely related skills — anchor 4 rather than 5; clearly more distinct than anchor 3's broad 'works with document files' level.