Conciseness

Almost every line carries project-specific rules rather than concepts Claude already knows, but the prose could be tightened substantially: the instruction to read the playbook "before creating a plan, running a benchmark or changing runtime code" appears twice nearly verbatim (lines 19-20 and 26-27), the defer/gate rule is restated in step 5 and again in the following paragraph, and multi-clause run-ons like the cohort-noise rule ("A cohort's noise is the larger of its same-code gap and the furthest any pair ... because a same-code arm divides by the same base runs ...") demand several re-reads. Matches mostly-efficient-but-could-be-tightened, not noticeably padded with unnecessary explanations (2).

Actionability

There are genuinely concrete commands scattered throughout ("node tooling/scripts/proof-worktree.mjs", "node .agents/rules/benchmark/scripts/paired-timing.mjs", "node tooling/scripts/review-ledger.mjs lookup <scope>", "pnpm bench:editor:install", "--reporter=verbose --silent=false"), but the central Pre-Acceptance Probe workflow is dense policy law ("Reuse an honest existing budget when one exists", "Size each line relative to the baseline and above the timer resolution") whose executable mechanics are delegated to a playbook and scripts outside this bundle. Some concrete guidance, incomplete within the body — matching anchor 3 rather than mostly-executable anchor 4.

Workflow Clarity

The probe is a numbered 5-step sequence with abundant validation checkpoints and feedback loops: a planted-slowdown control the budget line must reject, a known-bad input that "must fail with the probe's own assertion text", inconclusive results branching to defer/gate, and conclusive misses sending the target "back to `architect` at once". Not a 5 because the full end-to-end workflow is interleaved across external cross-references (the perf-issue playbook, `pstack:benchmark-checklist`, `verify`'s command recipes) that a reader must assemble themselves, leaving minor sequence gaps in the body alone.

Progressive Disclosure

The two key references are clearly signaled with when-to-read guidance ("For `review <scope-or-plan>`, read the full [performance review method](./references/performance-review.md)"; "Read [methodology.md](./references/methodology.md) completely before creating a plan..."), but the structure has real gaps against the actual bundle: `references/autoresearch.md` is never mentioned, the ~100-line Pre-Acceptance Probe law is inlined where a reference would fit, and script paths point outside the bundle (`.agents/rules/benchmark/scripts/paired-timing.mjs`, `.agents/rules/benchmark/scripts/benchmark-contract.test.mjs`) instead of the colocated `scripts/` files. Between anchor 3 and anchor 4; the orphaned file, path mismatches, and heavy inline section pull it to 3.

Specificity

Names a precise domain ("Plate/Plite performance") and three concrete actions — "Measure and repair ... performance, or review a performance design before running its applicable benchmark lanes" — matching the several-specific-actions anchor. Not a 5 because coverage of capabilities is narrow (no mention of comparison, diagnosis, or harness repair work the body actually does); not a 3 because it goes beyond 1-2 generic actions with the lane/gate specifics.

Completeness

Explicitly answers what ("Measure and repair Plate/Plite performance, or review a performance design before running its applicable benchmark lanes") and when, with an unusually thorough trigger enumeration ("Use before writing, reviewing, running, rerunning, checking, skipping or deferring a performance gate ... before writing a benchmark script, before explaining a benchmark result or failure, and when a review or panel finds a latency or scaling cost"). Matches the anchor for both what and when with concrete trigger phrases; anchor 4's caveat (when could be more explicit) does not apply.

Trigger Term Quality

Good natural keyword coverage: "performance", "benchmark", "latency", "scaling cost", "performance gate", "benchmark script", "benchmark result or failure" are phrases a developer in this repo would say. Not a 5 because common synonyms like slow, speed, regression, or profiling are missing, and some trigger phrasing ("a plan's scale gate", "a review or panel finds") is internal process jargon rather than user-natural language.

Distinctiveness Conflict Risk

The Plate/Plite product names and performance-gate/benchmark-lane vocabulary define a clear niche with distinct triggers, so minimal conflict risk with other skills. It is not a 4 because no closely related skill in a typical bundle would claim this same product-specific measurement/gate territory.