Conciseness

The body is largely lean: tables, checklists, short bullets, and a copy-paste hypothesis template, with every section earning its place. Minor over-explanation of concepts Claude already knows keeps it below anchor 5 — e.g., '95% confidence = p-value < 0.05 / Means <5% chance result is random' and the 'Peeking Problem' paragraph restate textbook statistics.

Actionability

Concrete, verified executable guidance: the bundled calculator is invoked with exact flags ('python3 scripts/sample_size_calculator.py --baseline 0.05 --mde 0.20 --json', '--daily-traffic') that match the script's actual argparse, plus a weak-vs-strong hypothesis example and specific metric tables. It falls short of anchor 5 only because the analysis section says 'Check confidence intervals' without a command or formula for actually computing significance.

Workflow Clarity

The lifecycle is clearly sequenced (Initial Assessment → Hypothesis → Design → Sample Size → Pre-Launch Checklist → Running → Analysis → Documentation) with explicit checkpoints: the pre-launch checklist, 'Paste sample_size_per_variation... before any test is approved to run', the DO/DON'T list, and the 6-step analysis checklist. It misses anchor 5 because there is no error-recovery loop (e.g., what to do when QA or tracking verification fails) and the overall sequence is implied by section order rather than stated as one master workflow.

Progressive Disclosure

The body acts as a clean overview with well-signaled, one-level-deep references that all exist in the bundle: 'See [references/sample-size-guide.md](references/sample-size-guide.md)' for detailed tables, 'See [references/test-templates.md](references/test-templates.md)' for templates, and the bulk calculation logic delegated to scripts/sample_size_calculator.py. Content is appropriately split — only the small quick-reference table and usage examples stay inline — matching the anchor-5 example structure.

Specificity

The description names the domain ('A/B test or experiment') and a small set of actions ('plan, design, or implement'), but these are near-synonymous verbs for one activity and no concrete outputs (test plans, sample-size calculation, variant design, results analysis) are stated. It matches anchor 3 (domain plus 1-2 concrete actions, not comprehensive) better than anchor 4, which expects several distinct specific actions.

Completeness

The 'when' is explicit and rich (two 'use when' clauses with concrete trigger phrases), and a 'what' is present but folded inside the when-clause ('plan, design, or implement an A/B test') rather than stated as a standalone capability list. It answers both what and when but sits below the anchor-5 example, which pairs a full capability sentence with an equally explicit trigger sentence; the delegation note ('For tracking implementation, see analytics-tracking') is a plus.

Trigger Term Quality

Comprehensive natural-language coverage including synonyms: '"A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "conversion experiment," "statistical significance," or "test this." These are phrases a user would naturally say when needing this skill, matching the anchor-5 example's breadth (e.g., 'PDF files, PDFs, forms, document extraction, .pdf').

Distinctiveness Conflict Risk

The A/B-testing vocabulary is distinctive, but generic triggers '"test this," "test this change," "experiment," and "hypothesis" would also naturally occur in code-testing and general engineering contexts, creating overlap risk with test-writing or experimentation-adjacent skills. This matches anchor 3 (somewhat specific but could still overlap) rather than anchor 4's 'minor overlap risk'.