Conciseness

The intro sentence ('Lazy loading defers non-critical resources until needed—this reduces initial page weight, speeds up first paint...') and the 'Explain' section both restate basic lazy-loading concepts Claude already knows and duplicate each other. Otherwise the body is lean, so this is unnecessary explanation that could be tightened rather than severe padding.

Actionability

'Check' gives concrete directives ('Verify that images and other heavy resources below the fold are lazy loaded. Only report this when the code or route context makes offscreen placement clear'), but 'Fix' is a high-level hint ('using native loading='lazy' or JavaScript solutions') with no code or named technique, and 'describe the measurement method used to confirm the issue' leaves the method unspecified.

Workflow Clarity

A clear Check → Fix → Explain → Code Review sequence is present with real checkpoints ('If fold position is unclear from the snippet, do not invent a lazy-loading defect'; 'Only report this when the code or route context makes offscreen placement clear'). The minor gap is that post-fix verification (PageSpeed/throttled trace) lives only in the reference file and is not surfaced as a step in the body.

Progressive Disclosure

The body is a concise, well-sectioned ~35-line overview that appropriately defers code examples and framework-specific guidance to a clearly signaled, one-level-deep reference ('For full implementation details, code examples, and framework-specific guidance, see references/rule.md'), which exists in the bundle.

Specificity

Two concrete actions are named ('Verify the actual bottleneck in DevTools, Lighthouse, or field data before recommending changes'; 'auditing slow page loads, heavy assets, or rendering delays'), but the core capability — implementing lazy loading — never appears as its own action statement, only embedded inside the trigger clause. Not 4 because the 'what' actions are not comprehensively listed.

Completeness

Both elements are present: an explicit 'Use when auditing slow page loads, heavy assets, or rendering delays...' trigger and the capability phrase 'Implement lazy loading for offscreen content'. Not 5 because the 'what' is awkwardly embedded inside the 'when' clause ('...rendering delays related to Implement lazy loading for offscreen content') rather than stated as a clear capability sentence.

Trigger Term Quality

Good natural keyword coverage: 'slow page loads', 'heavy assets', 'rendering delays', 'lazy loading', and 'loading='lazy'' are phrases users would actually say. A few natural terms are missing (e.g., 'below the fold', 'LCP', 'page performance'), so it falls short of the comprehensive-synonym anchor 5.

Distinctiveness Conflict Risk

The lazy-loading niche is identifiable, but the leading triggers ('slow page loads', 'heavy assets', 'rendering delays') are broad performance complaints that would also fire for image-optimization, bundling, and code-splitting skills. Somewhat specific, but overlap with closely related performance skills remains.