Experiment Designer Skill

Design statistically rigorous A/B tests and interpret experiment results.

Experiment Designer Skill — The Skill Playground: pick the Executive Update skill, fill in a few notes, hit run, and watch a structured executive… (from the mohitagw15856/pm-claude-skills README)

From the mohitagw15856/pm-claude-skills README — shows the whole collection, not only this skill. · view on GitHub

How to use it

Claude Code
  1. Run the line below. It pulls the whole folder into ~/.claude/skills/experiment-designer.
  2. Describe your job in plain words. Claude Code follows the skill from there.
Claude Code — installs the whole folder, not just SKILL.md
npx degit mohitagw15856/pm-claude-skills/skills/experiment-designer#main ~/.claude/skills/experiment-designer

For one project only, change the path to .claude/skills/experiment-designer.

Claude (web or desktop app)
  1. On this page open ⋯ → Download .md.
  2. Save it as SKILL.md in a folder, zip the folder, then Customize → Skills → + → Create skill → Upload a skill.
  3. Pick the file and Save. Claude shows the name and description and runs a security scan.
  4. Check the skill is switched on.
  5. Start a new chat and describe your job in plain words. The AI follows the skill from there.
ChatGPT or another app
  1. ChatGPT: make a Project and paste it into Instructions.
  2. Neither? Paste it at the top of a new chat — it works for that chat.
Not working?
  • Check which app you pasted it into — the steps above name the right one.
  • Some skills need the paid tier of Claude or ChatGPT.
Step-by-step guide with screenshots · Ask in the forum

Paste into Claude, ChatGPT or Cursor.

Source of Experiment Designer Skill

Show the full text78 lines
namedescription
experiment-designerDesign statistically rigorous A/B tests and interpret experiment results. Use when asked to design an experiment, run an A/B test, calculate sample size, interpret test results, or assess whether an experiment was successful. Produces a complete experiment design with hypothesis, sample size, run time, success criteria, and risk flags — or a results interpretation with ship/iterate/kill recommendation.

Experiment Designer Skill

Produce rigorous experiment designs from product hypotheses, and interpret results with statistical and practical significance — so you can defend every decision to a sceptical engineering lead or data scientist.

Required Inputs

Ask the user for these if not provided: For experiment design:

  • Hypothesis (what change, what metric, what expected movement)
  • Current baseline metric value
  • Minimum detectable effect (MDE) — the smallest lift worth caring about
  • Available daily sample size

For results interpretation:

  • Control and variant results (raw numbers or percentages)
  • P-value or confidence interval
  • Run duration (days)
  • Any anomalies observed during the test

Two-Phase Process

Phase 1: Experiment Design
  1. Restate hypothesis as: "If we [change], we expect [metric] to [move by X%] because [reason]"
  2. Define control and variant clearly
  3. Select primary metric (one only) and secondary guardrail metrics (2-3 max)
  4. Calculate required sample size from MDE and baseline
  5. Estimate run time in days
  6. Set pre-defined success criteria before the test runs — no moving goalposts
  7. Flag design risks: novelty effects, seasonal confounds, multiple testing issues, network effects, sample ratio mismatch
Phase 2: Results Interpretation
  1. Assess statistical significance (p < 0.05 threshold)
  2. Assess practical significance: was the lift meaningful for the business, not just real?
  3. Interpret confidence intervals
  4. Investigate confounding factors
  5. Recommend: Ship / Iterate / Kill / Run follow-up test
  6. Validate — Confirm the test ran for the full planned duration. Flag if it was stopped early (peeking problem). Confirm sample ratio mismatch did not occur.

Output Structure

[Design or Results header based on phase]

Hypothesis: "If we [change], we expect [metric] to [move by X%] because [reason]"

Primary metric: [One metric only] Guardrail metrics: [2-3 max] Required sample size: [n per variant] Estimated run time: [days] Pre-defined success threshold: [specific number] Design risk flags: [any concerns]

Results (Phase 2 only): Statistical significance: [p-value and conclusion] Practical significance: [lift size vs. business threshold] Recommendation: Ship / Iterate / Kill / Follow-up — [rationale]

Quality Checks

  • Hypothesis specifies the change, the metric, the direction, and the reason
  • Primary metric is singular — guardrail metrics are secondary
  • Success criteria are defined before the test launches (not after seeing results)
  • Test was not stopped early (or flagged clearly if it was)
  • Practical significance assessed separately from statistical significance
  • Sample ratio mismatch is checked in results interpretation

Anti-Patterns

  • Do not define success criteria after seeing preliminary results — post-hoc success definitions are HARKing (Hypothesising After Results are Known) and invalidate the experiment
  • Do not stop a test early because the result looks significant — early stopping dramatically inflates false positive rates; the test must run to the planned sample size
  • Do not treat statistical significance as the same as practical significance — a p < 0.05 result with a 0.1% lift is real but may not be worth shipping
  • Do not run the same experiment on the same population multiple times without correction — multiple testing inflates the chance of a false positive proportionally
  • Do not use more than one primary metric — multiple primary metrics require multiple hypothesis corrections and make the ship/kill decision ambiguous
1---
2name: experiment-designer
3description: "Design statistically rigorous A/B tests and interpret experiment results. Use when asked to design an experiment, run an A/B test, calculate sample size, interpret test results, or assess whether an experiment was successful. Produces a complete experiment design with hypothesis, sample size, run time, success criteria, and risk flags — or a results interpretation with ship/iterate/kill recommendation."
4---
5 
6# Experiment Designer Skill
7 
8Produce rigorous experiment designs from product hypotheses, and interpret results with statistical and practical significance — so you can defend every decision to a sceptical engineering lead or data scientist.
9 
10## Required Inputs
11 
12Ask the user for these if not provided:
13**For experiment design:**
14- Hypothesis (what change, what metric, what expected movement)
15- Current baseline metric value
16- Minimum detectable effect (MDE) — the smallest lift worth caring about
17- Available daily sample size
18 
19**For results interpretation:**
20- Control and variant results (raw numbers or percentages)
21- P-value or confidence interval
22- Run duration (days)
23- Any anomalies observed during the test
24 
25## Two-Phase Process
26 
27### Phase 1: Experiment Design
281. Restate hypothesis as: "If we [change], we expect [metric] to [move by X%] because [reason]"
292. Define control and variant clearly
303. Select primary metric (one only) and secondary guardrail metrics (2-3 max)
314. Calculate required sample size from MDE and baseline
325. Estimate run time in days
336. Set pre-defined success criteria before the test runs — no moving goalposts
347. Flag design risks: novelty effects, seasonal confounds, multiple testing issues, network effects, sample ratio mismatch
35 
36### Phase 2: Results Interpretation
371. Assess statistical significance (p < 0.05 threshold)
382. Assess practical significance: was the lift meaningful for the business, not just real?
393. Interpret confidence intervals
404. Investigate confounding factors
415. Recommend: Ship / Iterate / Kill / Run follow-up test
426. **Validate** — Confirm the test ran for the full planned duration. Flag if it was stopped early (peeking problem). Confirm sample ratio mismatch did not occur.
43 
44## Output Structure
45 
46**[Design or Results header based on phase]**
47 
48*Hypothesis:* "If we [change], we expect [metric] to [move by X%] because [reason]"
49 
50*Primary metric:* [One metric only]
51*Guardrail metrics:* [2-3 max]
52*Required sample size:* [n per variant]
53*Estimated run time:* [days]
54*Pre-defined success threshold:* [specific number]
55*Design risk flags:* [any concerns]
56 
57**Results (Phase 2 only):**
58*Statistical significance:* [p-value and conclusion]
59*Practical significance:* [lift size vs. business threshold]
60*Recommendation:* Ship / Iterate / Kill / Follow-up — [rationale]
61 
62## Quality Checks
63 
64- [ ] Hypothesis specifies the change, the metric, the direction, and the reason
65- [ ] Primary metric is singular — guardrail metrics are secondary
66- [ ] Success criteria are defined before the test launches (not after seeing results)
67- [ ] Test was not stopped early (or flagged clearly if it was)
68- [ ] Practical significance assessed separately from statistical significance
69- [ ] Sample ratio mismatch is checked in results interpretation
70 
71## Anti-Patterns
72 
73- [ ] Do not define success criteria after seeing preliminary results — post-hoc success definitions are HARKing (Hypothesising After Results are Known) and invalidate the experiment
74- [ ] Do not stop a test early because the result looks significant — early stopping dramatically inflates false positive rates; the test must run to the planned sample size
75- [ ] Do not treat statistical significance as the same as practical significance — a p < 0.05 result with a 0.1% lift is real but may not be worth shipping
76- [ ] Do not run the same experiment on the same population multiple times without correction — multiple testing inflates the chance of a false positive proportionally
77- [ ] Do not use more than one primary metric — multiple primary metrics require multiple hypothesis corrections and make the ship/kill decision ambiguous
78 

Discussion

Alternatives

Also in A/B testingSee all 364 in Marketing →
A/B Test SetupWhen the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program," or "experiment playbook." Use this whenever someone is comparing two approaches and wants to measure which performs better, or when they want to build a systematic experimentation practice. For tracking implementation, see analytics. For page-level conversion optimization, see cro.Marketing · MITAd Copy Generator + A/B TesterGenerate and A/B test Google Ads copy. Use when asked to write ad copy, headlines, descriptions, create ad variants, test ad messaging, improve CTR, or generate RSA (Responsive Search Ad) components. Trigger on "ad copy", "write ads", "headlines", "descriptions", "RSA", "responsive search ad", "ad text", "ad creative", "improve CTR", "ad A/B test", "ad variants", "write me an ad", "ad variation experiment", or when the user wants to improve click-through rate on existing ads.Marketing · MITA/B Test Planner SkillDesign statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, design an A/B test, calculate sample size, or interpret test results. Produces a complete test plan with hypothesis, variant definitions, sample size, duration estimate, guardrail metrics, and a results interpretation guide.Marketing · MITConversion Rate Optimization (CRO)When the user wants to optimize, improve, or increase conversions on any marketing page or form — including homepage, landing pages, pricing pages, feature pages, lead capture forms, or contact forms. Also use when the user says 'CRO,' 'conversion rate optimization,' 'this page isn't converting,' 'improve conversions,' 'why isn't this page working,' 'my landing page sucks,' 'form abandonment,' 'nobody's converting,' 'low conversion rate,' or 'this page needs work.' Use this even if the user just shares a URL and asks for feedback. For signup/registration flows, see signup. For post-signup activation, see onboarding. For popups/modals, see popups.Marketing · MIT