Conciseness

The intro paragraph ('Modern HTTP protocols significantly reduce the impact of latency and allow multiple resources to be downloaded simultaneously...') explains HTTP/2 concepts Claude already knows, and the Quick Reference bullets largely restate the same ideas — mostly efficient but with unnecessary explanation that could be cut, fitting anchor 3 rather than 4.

Actionability

'Enable HTTP/2 or HTTP/3 in your web server (Nginx, Apache) or via a CDN/load balancer' and 'using browser DevTools or online checkers' are high-level hints with no commands or config in the body; the concrete steps are deferred entirely to references/rule.md. Some guidance exists and the pointer is explicit, so anchor 3 fits better than 2, but key executable details (e.g., the nginx listen directive, the DevTools Protocol column) are absent from the body.

Workflow Clarity

Check → Fix → Explain → Code Review implies a measure-then-fix sequence, but there is no explicit ordering, no validation checkpoints beyond the implicit 'Check' step, and the Code Review section only asks to 'describe the measurement method used to confirm the issue' — sequence present, checkpoints implicit, matching anchor 3.

Progressive Disclosure

A short, well-sectioned overview with a clearly signaled one-level-deep reference ('For full implementation details, code examples, and framework-specific guidance, see references/rule.md' — verified to exist and contain the concrete Nginx config and DevTools steps); content is appropriately split and navigation is easy, matching anchor 5.

Specificity

Names concrete actions ('Verify the actual bottleneck in DevTools, Lighthouse, or field data', 'auditing slow page loads, heavy assets, or rendering delays') with specific tools, but the fix-side capability (enabling the protocol) is only implied, so it falls between anchors 3 and 4 — noticeably above several-actions gap but short of comprehensive.

Completeness

Explicitly answers both: what ('Verify the actual bottleneck in DevTools, Lighthouse, or field data before recommending changes') and when ('Use when auditing slow page loads, heavy assets, or rendering delays related to Enable HTTP/2 or HTTP/3') with concrete trigger phrases, matching the anchor-5 example; anchor 4's deficiency ('when could be more explicit') does not apply.

Trigger Term Quality

Natural user phrases like 'slow page loads', 'heavy assets', 'rendering delays', 'HTTP/2 or HTTP/3', 'DevTools', and 'Lighthouse' are present, but common variations such as 'page speed', 'network latency', or 'site is slow' are missing — good coverage, not comprehensive.

Distinctiveness Conflict Risk

The 'related to Enable HTTP/2 or HTTP/3' qualifier gives it a clear niche, but the opening triggers ('slow page loads', 'rendering delays') could also match general performance-optimization skills — minor overlap risk with closely related skills rather than a fully distinct trigger set.