Conciseness

The ~30-line body is lean: a one-sentence rationale ("Conflicting canonical-url signals can lead search engines to ignore both declarations..."), short Quick Reference bullets, and terse Check/Fix/Explain/Code Review sections with no teaching of concepts Claude already knows. The three Quick Reference bullets ("Ensure the rel=canonical tag ... matches", "Avoid sending conflicting signals", "Maintain consistency across all methods") restate the same point three ways and could be trimmed, which is the minor over-explanation of anchor 4 rather than the tighter fit of 5.

Actionability

The Check section gives a concrete, unambiguous instruction ("Compare the HTML canonical tag with the HTTP Link header to ensure they point to the exact same URL") and Fix gives a remediation ("Update either the HTML tag or the HTTP header..."), but no executable commands or examples appear in the body — e.g., no 'curl -I <url>' to inspect the header or how to view rendered HTML — with code deferred to references/rule.md. That is some concrete guidance with missing key details, matching anchor 3 rather than 4's mostly-executable guidance.

Workflow Clarity

This is a simple, non-destructive single-task skill, and the section flow (Check → Fix → Explain → Code Review) lays out a coherent sequence with an unambiguous core action; the Code Review section even specifies flagging "exact routes or templates where search-facing output violates the rule" and how to "verify the final page output". It falls short of 5 only because no explicit verification checkpoint command is given in the body itself, leaving a minor validation gap typical of anchor 4.

Progressive Disclosure

The body is a concise overview 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" — a real file that exists in the bundle. This matches the simple-skill guidance and anchor 5's clear overview with well-signaled shallow references; nothing that belongs in a separate file is inlined.

Specificity

The description names the domain ("Sync HTML canonical tags and Link headers") and two concrete actions ("auditing metadata, crawlability, structured data, or indexability" and "Verify the rendered HTML and HTTP response"), but does not state what is actually checked (tag/header URL consistency) or any remediation, so coverage is not comprehensive. It matches anchor 3 (domain plus 1-2 concrete actions) rather than anchor 4, which expects several specific actions; it is clearly above anchor 2, where actions are minimal or generic.

Completeness

Both parts are explicit: the trigger "Use when auditing metadata, crawlability, structured data, or indexability related to Sync HTML canonical tags and Link headers" and the what "Verify the rendered HTML and HTTP response rather than relying only on source files". The 'what' could be more specific about the actual check (comparing the canonical tag against the Link header for an exact URL match), so it sits at anchor 4 rather than 5; it is clearly above anchor 3, where 'when' is missing or only weakly implied.

Trigger Term Quality

It includes strong natural phrases users would say: "auditing metadata", "crawlability", "structured data", "indexability", "canonical tags", "Link headers", "rendered HTML", "HTTP response". A few common synonyms are missing (e.g., "SEO", "duplicate content", "canonical URL"), which keeps it at anchor 4 rather than 5's comprehensive synonym/extension coverage, while it is well above anchor 3's partial keyword set.

Distinctiveness Conflict Risk

The canonical tag/Link header pairing is a clear niche with distinct triggers, giving minimal conflict risk there. The broad leading terms "metadata, crawlability, structured data, or indexability" overlap with other SEO-audit skills, which is a minor overlap risk consistent with anchor 4 rather than 5.