Conciseness

The Check and Fix sections are tight, but the body includes unnecessary explanation Claude already knows — 'A single main landmark allows keyboard and screen reader users to jump directly to the primary content of the page, bypassing repetitive navigation' — plus a redundant Quick Reference bullet ('Provides a clear starting point for the page's primary content') that repeats it, and wordy boilerplate in the Explain and Code Review sections. It is mostly efficient but could be noticeably tightened, matching anchor 3 better than 4.

Actionability

Concrete, executable instructions are present: 'Count the number of <main> elements or elements with role='main' on the page' and 'Combine multiple main content areas into a single <main> element or remove the 'role=main' attribute from extra containers.' It is not a 5 because no example selector or command for the counting check is given and the Explain/Code Review sections are generic directives rather than rule-specific guidance.

Workflow Clarity

For this simple single-rule skill, the Check → Fix → Explain sequence is clear and the single action (verify exactly one main landmark) is unambiguous, with verification mentioned ('note how to verify the fix with browser accessibility tooling or assistive tech'). It is not a 5 because explicit validation steps are deferred to references/rule.md's Verification section rather than stated or linked in the body's own workflow, leaving minor validation gaps.

Progressive Disclosure

The body is a concise overview and the single bundle file, references/rule.md (verified to exist), correctly holds the code examples, best practices, and verification details. The reference is well signaled — 'For full implementation details, code examples, and framework-specific guidance, see references/rule.md' — one level deep with easy navigation, matching the 5 anchor.

Specificity

The description lists several concrete inspection actions — 'Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant' — tied to a specific domain. It falls short of the 5 anchor because the awkwardly embedded rule title ('related to Use exactly one main landmark') leaves minor gaps in coverage rather than a comprehensive, cleanly phrased action list.

Completeness

Both parts are explicitly stated: the 'when' is a concrete 'Use when reviewing rendered HTML, interactive components, or design-system patterns related to...' clause, and the 'what' is 'Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant.' This mirrors the 5-anchor structure of explicit what-and-when with concrete trigger phrases; it is not a 4 because neither half is missing or weakly implied.

Trigger Term Quality

Natural phrases a user would say are present: 'rendered HTML', 'interactive components', 'design-system patterns', 'keyboard behavior', 'focus flow', 'screen-reader output', and 'main landmark'. It is not a 5 because common variations and synonyms are missing — notably 'accessibility', 'a11y', 'ARIA', 'main element', and 'role=main' — so keyword coverage is good but not comprehensive.

Distinctiveness Conflict Risk

The rule name 'Use exactly one main landmark' carves a clear niche with a distinct trigger ('main landmark'), so conflict risk is low. It is not a 5 because the boilerplate scope ('reviewing rendered HTML, interactive components, or design-system patterns') would be shared verbatim by sibling accessibility-rule skills from the same source, creating minor overlap risk among closely related skills.