Conciseness

The body is mostly lean, but the intro paragraph ('Traditional SSR waits for all data fetches to complete before sending a single byte of HTML... dramatically improving perceived performance and LCP') explains concepts Claude already knows and duplicates the 'Explain' section. Matches anchor 3 — efficient with some removable explanation — rather than anchor 4's 'minor instances'.

Actionability

Concrete anchors are present — 'renderToPipeableStream', 'ReadableStream', 'Suspense boundaries', 'renderToString calls', and a measurable threshold ('values above 600ms') — but the body contains no executable code or commands; e.g., 'Monitor TTFB in Lighthouse' gives no method, and the fix defers entirely to the reference. Matches anchor 3 (concrete guidance but incomplete), not anchor 4 (mostly executable guidance).

Workflow Clarity

The Check → Fix → Explain → Code Review sequence is coherent, with specific detection criteria ('renderToString calls, missing Suspense boundaries around data-fetching components, and use of await on slow queries before returning a response') and a TTFB threshold acting as a checkpoint. Not anchor 5 because the monitoring step is not operationalized and there is no verify-after-fix loop; clearly above anchor 3's implicit checkpoints.

Progressive Disclosure

Clear 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') — verified to exist and to contain the deferred code examples. Matches anchor 5: content appropriately split and easy to navigate.

Specificity

The description names concrete domains ('server-side rendering setup, Next.js App Router pages, or Node.js HTTP handlers') and one concrete action ('verify that HTML is streamed incrementally rather than buffered until completion'). This matches anchor 3 — one clear action in a named domain — but not anchor 4, which requires several specific actions; fix/refactor capabilities from the body are absent from the description.

Completeness

Explicitly answers both questions: 'when' via the 'Use when reviewing server-side rendering setup, Next.js App Router pages, or Node.js HTTP handlers' clause with concrete triggers, and 'what' via 'to verify that HTML is streamed incrementally rather than buffered until completion'. Matches anchor 5; not anchor 4 since the 'when' is fully explicit and specific rather than improvable.

Trigger Term Quality

Good natural keyword coverage: 'server-side rendering', 'Next.js App Router', 'Node.js HTTP handlers', 'streamed', 'buffered' — phrases users would plausibly say. Not anchor 5 because common synonyms like 'SSR', 'React', 'streaming SSR', or 'TTFB' are missing, but coverage is well above anchor 3's 'some relevant keywords'.

Distinctiveness Conflict Risk

Clear niche — verifying HTML streaming in SSR contexts — with named frameworks that constrain triggering. Minor overlap risk remains with general Next.js or performance-review skills since 'reviewing Next.js App Router pages' is broad; not anchor 5, well above anchor 3's generic overlap.