Conciseness

Mostly brief, but includes removable material: the rationale sentence "Invalid HTML causes unpredictable rendering across browsers, breaks accessibility tools, and makes debugging significantly harder" explains consequences Claude already knows; "Common issues: unclosed tags, invalid nesting, missing attributes" (Quick Reference) is duplicated nearly verbatim in Fix ("fix reported errors including unclosed tags, missing attributes, and invalid nesting"); and the Explain section reiterates why validation matters. Not a 4: there are several instances of duplication and known-concept padding; not a 2: the body is short overall with no tutorial-style prose.

Actionability

Some concrete guidance exists — "Use validator.w3.org or browser extensions", "Integrate validation into CI/CD with html-validate", and specific error types — but there are no executable commands or code in the body (e.g., an actual html-validate invocation), and "Run HTML through W3C validator and fix reported errors" is a high-level instruction rather than an executable step. Not a 4: nothing in the body is copy-paste ready, even though the deferred references/rule.md likely contains it; not a 2: specific tools and concrete error classes are named.

Workflow Clarity

The Check → Fix → Explain → Code Review sections give a clear sequence, and "Fix errors first, then warnings (errors cause rendering issues)" is an explicit prioritization checkpoint. Not a 5: the workflow implies fixing but never states a re-validate-after-fixing feedback loop (the fix/verify loop is implicit), so the checkpoint coverage is incomplete; not a 3: the sequence is clear and a prioritization rule is stated.

Progressive Disclosure

The body is a concise overview that clearly signals a single one-level-deep reference: "For full implementation details, code examples, and framework-specific guidance, see `references/rule.md`" — and that file exists in the bundle with substantive content (673 lines including code examples). Sections are well-organized and navigation is trivial, matching the 5 anchor.

Specificity

Quotes: "reviewing templates, rendered HTML, or shared components" and "Validate the final browser-facing markup" name the domain and 1-2 concrete actions (review markup artifacts, validate rendered output). Not a 4: it does not list several actions (no fixing, CI integration, or error handling in the description). Not a 2: the actions are concrete and target specific artifacts rather than generic.

Completeness

Explicitly answers both: what — "Validate the final browser-facing markup, not just the source framework abstraction" (against W3C standards); when — "Use when reviewing templates, rendered HTML, or shared components". The 'when' clause contains concrete trigger phrases, matching the 5 anchor; a 4 would require the 'when' to be less explicit or specific than it is here.

Trigger Term Quality

Natural terms users would say are present: "templates", "rendered HTML", "shared components", "W3C standards", "HTML". Not a 5: misses common variations and synonyms such as "validator", "invalid markup", "check my HTML", or file extensions. Not a 3: coverage is genuinely good, not just partial.

Distinctiveness Conflict Risk

W3C HTML validation of rendered markup is a clear niche with distinct triggers ("W3C standards", "rendered HTML"), but phrases like "reviewing templates... or shared components" carry minor overlap risk with general code-review or accessibility-focused skills. Not a 5 due to that overlap; not a 3 since the W3C validation focus is well-differentiated.