Mostly efficient and dense, but it pads with background Claude does not need — the Fowler quote opening that defines a non-deterministic test, the etymology paragraph ('practitioner-emergent, popularized by the Google Testing Blog... there is no standards-body definition behind it'), and the 'note on where flakes concentrate' section citing Google's 4.2M-test analysis. It is not a verbose wall of basics, but it carries real contextual fat, so it lands at 'mostly efficient but includes some unnecessary explanation'.

Fully concrete guidance: real runner flags (--showSeed, --seed, --repeat-each, --workers, --maxWorkers, --runInBand, --randomize), an executable two-proportion z formula with the pooled-p definition, a copy-paste report-shape template, and a worked axis table — instruction-only but maximally actionable, matching the 'specific examples; copy-paste ready' anchor.

A clearly sequenced Step 1–6 protocol with sub-steps (5a/5b/5c) and an explicit feedback loop — screen at N=20, shortlist on a 2x hit, re-measure baseline plus implicated axis at N=60, then apply the z rule before editing code — so the validation/confirm-before-act checkpoints the rubric demands for batch/measurement operations are present rather than missing.

The body is the protocol; the heavy lookup material (p-to-N table, Wilson intervals, worked comparisons) and the eight-resource collision walk are split into two real, one-level-deep reference files that are linked inline at the relevant steps and re-listed with descriptions in a 'Deep references' section, matching the 'clear overview with well-signaled one-level-deep references' anchor.

Lists multiple concrete actions — 'holding the test constant and varying one axis at a time', 'recording a pass/fail count per variation', 'testing whether the gap between two conditions exceeds sampling noise' — plus the statistics and collision-walk sub-capabilities, matching the 'lists multiple specific concrete actions' anchor.

Explicitly answers both: what ('Locates the condition a known-flaky test actually depends on...') and when ('Use when a specific test is already known to fail intermittently, reading its source has not explained why, and a decision about what to change must rest on measurement'), matching the 'clearly answers both what AND when with explicit triggers' anchor.

Natural practitioner terms are well covered — 'known-flaky test', 'fail intermittently', 'reading its source has not explained why' — which are exactly what a user would say; the jargon sits in the capability list rather than the trigger clause, so it does not dilute the natural triggers.

The 'Use when' clause narrows to a specific scenario (one known-intermittent test, source inspection exhausted, measurement-driven decision needed), giving it a clear niche unlikely to fire for generic test-debugging or commit-search skills; not merely 'somewhat specific'.