The body is lean and well-organized with no padding: a one-line rationale plus terse Quick Reference and Check/Fix/Explain/Code Review sections that assume Claude's competence. Not 2 because it avoids unnecessary explanation of concepts Claude already knows (e.g., what the DOM is).

Provides concrete review criteria ('Render only what is visible plus a small overscan buffer', 'Introduce list or table virtualization') but no executable code or specific library/commands in the body; copy-paste-ready TSX examples live only in references/rule.md. Not 3 because the body's Fix guidance is somewhat abstract and not copy-paste ready; not 1 because the guidance names a specific approach and specific review signals rather than being vague.

The Check/Fix/Explain/Code Review phasing gives a clear sequence, and 'Measure scroll smoothness, memory use, and DOM node count before and after the change' is an explicit checkpoint. Not 3 because a full validate-fix-retry feedback loop is absent from the body (it lives in the reference's Verification section); not 1 because the sequence and a before/after measurement checkpoint are present rather than missing.

The body is a concise overview that clearly signals a one-level-deep pointer to references/rule.md ('For full implementation details, code examples, and framework-specific guidance, see references/rule.md'), and that file exists. Not 2 because the reference is explicitly signaled and only one level deep rather than inline or nested.

Names the domain ('dashboards, admin tables, search results, or feeds with many repeated items') and a couple of actions ('Confirm the bottleneck is DOM or rendering cost', 'introducing virtualization'), but does not list multiple specific concrete capabilities. Not 3 because it lacks a comprehensive set of concrete actions like the 'extract, fill, merge' example; not 1 because it is far from vague boilerplate like 'Helps with documents'.

Explicitly answers 'when' with a 'Use when reviewing dashboards, admin tables, search results, or feeds...' trigger clause, and answers 'what' via 'Confirm the bottleneck is DOM or rendering cost before introducing virtualization'. Both what and when are present and explicit. Not 2 because the when is not merely implied and the what is concrete rather than missing.

Includes several natural terms users would say when reviewing performance ('dashboards, admin tables, search results, feeds', 'DOM or rendering cost', 'virtualization'), but omits common variations a user would naturally say such as 'long lists', 'large tables', 'thousands of rows', or 'scroll jank'. Not 3 because coverage of natural phrasings is incomplete; not 1 because the terms present are relevant and natural rather than jargon-only.

The narrow frontend-performance niche ('DOM or rendering cost', 'virtualization', 'repeated items') is distinct and unlikely to trigger for unrelated skills. Not 2 because the DOM/rendering-cost qualifier narrows it well beyond a generic 'works with tables/dashboards' scope.