Conciseness

The body is dense and assumes Claude's competence (no concept explanations of git, grep, Promise.all, or N+1), but the four-headings-only rule is restated across Step 0, Step 2's mid-run check, '## Report shape', and the final check ('Never add a fifth `##`' / 'Both must print `4`'), and Step 0 pads one instruction across four sentences ('The file is the deliverable: a run that leaves a differently-shaped file has produced nothing... Leaving it until the end is how a section goes missing'). This is noticeably above anchor 3's 'some unnecessary explanation' but not the lean 5 — the repetition is deliberate compliance emphasis, yet it could be trimmed.

Actionability

The report skeleton heredoc, git base-resolution block, and shape-check greps ('grep -c \'^## \(...\)$\' PERFORMANCE-REVIEW.md ... It must print `4`') are copy-paste ready, and fixes name concrete idioms ('an `EXISTS (…)` or a joined column', 'Promise.all', 'Effect.all (with concurrency: "unbounded")', 'a single-use `sessionStorage` key'). Slightly below 5 because routing-table patterns like 'two `await`s in a row in one function', 'a route file', and 'a role or entitlement gate' are prose descriptions that must be translated into regex before the given `grep -nE '<pattern>'` command can run.

Workflow Clarity

Steps 0→1→2 are explicitly sequenced with a mandated pre-flight artifact, and validation is embedded with feedback loops: the mid-run shape check 'as soon as the first finding is in the file' with expected output ('It must print `4`. If it prints less... restore the 4 headings, put the finding back under the right one'), the final two-count check, record-as-you-go instructions, and resume behavior ('a run that a usage limit or an error stops keeps what the file already holds'). This matches anchor 5's explicit checkpoints, error recovery, and checklists.

Progressive Disclosure

The body keeps only the dominant section (Database round trips, Shared middleware) and clearly signals the one-level-deep reference: 'Eight more sections live in `references/checklists.md` ... open the file whenever Step 1 routes to one of them', and the verified bundle file exists with matching section headings plus its own usage header. The Step 1 routing table maps grep hits to named sections, making navigation easy; the split rationale (sections the eval suite does not exercise) is stated. A minor accuracy slip ('Eight more sections' when ten are named and ten exist in the file) does not impair navigation since all names verbatim-match the reference file's headings.

Specificity

The description enumerates multiple concrete defect classes — 'redundant database round trips, N+1 queries, unbounded reads, per-request layer rebuilds, wasted client fetches, and build steps that ship a broken artefact' — plus a concrete output convention ('reporting findings with P-C/W/I IDs in the four-field format'), matching anchor 5's comprehensive coverage of specific actions. It is above anchor 4 because nothing within its stated scope is left to inference.

Completeness

It explicitly answers both questions with a concrete trigger phrase: 'Use when reviewing a branch diff for performance defects — ... — and reporting findings with P-C/W/I IDs in the four-field format', mirroring the anchor-5 pattern of what + when with concrete triggers. Not 4, because the 'when' clause is explicit rather than merely present.

Trigger Term Quality

Good natural keyword coverage: 'performance defects', 'branch diff', 'N+1 queries', 'database round trips', 'client fetches', 'build' are phrases a developer would actually say. Below anchor 5 because common synonyms a user might reach for first — 'slow', 'latency', 'optimize', 'profiling', 'perf' — are absent.

Distinctiveness Conflict Risk

The enumerated defect classes and the P-C/W/I ID convention carve a clear performance niche distinct from correctness or security review, but the opening trigger 'reviewing a branch diff' overlaps with general code-review skills when a user asks to 'review this branch' without naming performance. Minor overlap risk with closely related skills is exactly anchor 4; anchor 5 would require the trigger itself to be unambiguous across the skill family.