A/B Test Planner Skill

Design statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments.

A/B Test Planner 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/ab-test-planner.
  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/ab-test-planner#main ~/.claude/skills/ab-test-planner

For one project only, change the path to .claude/skills/ab-test-planner.

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 A/B Test Planner Skill

Show the full text140 lines
namedescription
ab-test-plannerDesign 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.

A/B Test Planner Skill

Design experiments that produce trustworthy results — not just directional signals. Every test output includes hypothesis, success metrics, sample size, duration, and a results interpretation guide.

Required Inputs

Ask the user for these if not provided:

  • What is being tested (feature, UI change, copy, pricing, onboarding step)
  • Hypothesis (or ask to help formulate one)
  • Primary metric (conversion rate, click-through, completion rate, etc.)
  • Baseline rate and minimum detectable effect (MDE)
  • Daily eligible users (to calculate duration)

Experiment Design Checklist

Before running any test, confirm:

  • Clear hypothesis with predicted direction
  • Single primary metric (plus up to 2 guardrail metrics)
  • Minimum detectable effect (MDE) defined
  • Sample size calculated
  • Test duration estimated
  • Segment isolated (no overlap with other running tests)
  • Rollback plan defined

Hypothesis Template

"We believe that [change] will cause [primary metric] to [increase/decrease] by [X%] for [user segment], because [rationale based on data or insight]."

Never run a test without a directional hypothesis. "Let's just see what happens" is not a hypothesis.

Sample Size Calculator Logic

Use this formula (provide the output, not the formula, to the user):

  • Baseline conversion rate: Current rate of primary metric
  • MDE: Smallest change worth detecting (recommend 10–20% relative lift for most features)
  • Statistical power: 80% (standard)
  • Significance level: 95% (p < 0.05)

For common scenarios, provide pre-calculated estimates:

Baseline Rate MDE (Relative) Required Sample per Variant
5% 20% ~19,000
10% 15% ~14,000
20% 10% ~15,000
40% 10% ~9,500
60% 5% ~42,000

Always warn: "These are estimates. Use a tool like Evan Miller's calculator or Statsig for precision."

Test Duration Guidance

Minimum: 2 full weeks (to capture weekly seasonality) Maximum: 4 weeks (novelty effect distorts results beyond this)

Duration = Required sample ÷ (Daily traffic × % exposed)

Flag if traffic is too low to reach significance in under 8 weeks — recommend a different approach (e.g., holdout test, qualitative research).

Output Format

A/B Test Plan — [Test Name] — [Date]

Hypothesis:

[Filled hypothesis template]

Variants:

  • Control (A): [Current experience]
  • Treatment (B): [Changed experience — be specific]

Primary Metric: [Metric name + how measured] Guardrail Metrics: [Metrics that must not degrade]

Target Segment: [Who sees the test — % of traffic, user type] Traffic Split: [50/50 recommended unless ramp-up needed]

Sample Size Required: ~[N] users per variant Estimated Duration: [X] weeks (based on [Y] daily eligible users) Significance Threshold: 95% confidence, 80% power

Exclusions: [Any user segments to exclude and why]

Rollback Trigger: If [guardrail metric] degrades by [X%], stop the test immediately.

Results Interpretation Guide:

  • ✅ Ship if: Treatment shows [X%]+ lift on primary metric at 95% confidence AND guardrail metrics are stable
  • 🔄 Iterate if: Direction is positive but not significant — consider extending or redesigning
  • ❌ Reject if: No lift or negative direction at significance
  • ⚠️ Inconclusive: Do not ship. Do not call it a win.

Guidelines

  • Always recommend against peeking at results before the test reaches planned sample size — explain p-hacking risk
  • If user wants to test multiple variants, explain the multiple comparisons problem and recommend a Bonferroni correction or a Bayesian approach
  • If traffic is very low (<1,000 users/day), recommend qualitative alternatives: moderated testing, 5-second tests, or user interviews
  • Never approve a test with no guardrail metrics — always protect revenue, retention, or core engagement

Anti-Patterns

  • Do not run a test without a directional hypothesis — "let's see what happens" produces uninterpretable results
  • Do not declare a winner before reaching the pre-planned sample size — peeking at results inflates false positive rates
  • Do not test multiple independent changes in a single variant — you won't know which change caused the result
  • Do not use engagement metrics (clicks, time-on-page) as the primary metric when the goal is revenue or retention — proxy metrics mislead
  • Do not ignore guardrail metrics — a conversion lift that causes a support ticket spike is not a win

Deeper Materials

This skill ships with support files — use them when they are available:

  • references/test-validity-traps.md — The Validity Traps That Quietly Invalidate A/B Tests. Apply it while producing the output; it carries the calibration and judgment calls the method summary above compresses.
  • templates/test-plan.md — a fill-in version of the deliverable with the quality gates inline. Offer it when the user wants to work the document themselves rather than have it generated.

Scoring Rubric (0–40)

Score any output of this skill before handing it over; 32+ is ship-quality.

Dimension 0 5 10
Statistical rigour No sample size, or a number with no stated baseline/MDE behind it Sample size present but MDE is guessed or copied from the lookup table without checking the actual baseline; power/significance unstated Sample size derived from the stated baseline and MDE at 80% power / 95% confidence, duration checked against real daily traffic and the 2–4 week window, and the low-traffic escape hatch invoked if it doesn't fit
Hypothesis discipline "Let's see what happens" — no direction, no magnitude, or multiple changes bundled into one variant Directional hypothesis but missing magnitude, segment, or the evidence-based because; variant purity not confirmed Full template filled (change, metric, direction, magnitude, segment, rationale citing data), and the treatment isolates exactly one change with excluded ideas named as follow-up tests
Guardrails & rollback No guardrail metrics, or a rollback line with no threshold Guardrails named but denominators/definitions ambiguous; rollback trigger vague ("if things look bad") 1–2 guardrails protecting revenue or core engagement with pre-agreed definitions, concrete rollback thresholds, and the peeking-vs-harm-monitoring distinction handled explicitly
Decision readiness No interpretation guide; results will be argued about after the fact Ship/iterate/reject listed but thresholds fuzzy; inconclusive outcome missing or treated as a soft win All four outcomes (ship / iterate / reject / inconclusive) mapped to pre-committed thresholds, including what an inconclusive result costs and what each outcome changes next

Quality Checks

  • Hypothesis is directional (predicts a specific direction and magnitude, not "let's see")
  • Primary metric is singular (guardrail metrics are secondary)
  • Sample size is calculated from actual MDE and baseline (not guessed)
  • Test duration accounts for weekly seasonality (minimum 2 weeks)
  • Guardrail metrics are defined (at least one to protect revenue or core engagement)
  • Rollback trigger is specified with a concrete threshold
1---
2name: ab-test-planner
3description: "Design 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."
4---
5 
6# A/B Test Planner Skill
7 
8Design experiments that produce trustworthy results — not just directional signals. Every test output includes hypothesis, success metrics, sample size, duration, and a results interpretation guide.
9 
10## Required Inputs
11 
12Ask the user for these if not provided:
13- **What is being tested** (feature, UI change, copy, pricing, onboarding step)
14- **Hypothesis** (or ask to help formulate one)
15- **Primary metric** (conversion rate, click-through, completion rate, etc.)
16- **Baseline rate** and **minimum detectable effect** (MDE)
17- **Daily eligible users** (to calculate duration)
18 
19## Experiment Design Checklist
20 
21Before running any test, confirm:
22- [ ] Clear hypothesis with predicted direction
23- [ ] Single primary metric (plus up to 2 guardrail metrics)
24- [ ] Minimum detectable effect (MDE) defined
25- [ ] Sample size calculated
26- [ ] Test duration estimated
27- [ ] Segment isolated (no overlap with other running tests)
28- [ ] Rollback plan defined
29 
30## Hypothesis Template
31 
32> "We believe that [change] will cause [primary metric] to [increase/decrease] by [X%] for [user segment], because [rationale based on data or insight]."
33 
34Never run a test without a directional hypothesis. "Let's just see what happens" is not a hypothesis.
35 
36## Sample Size Calculator Logic
37 
38Use this formula (provide the output, not the formula, to the user):
39 
40- **Baseline conversion rate:** Current rate of primary metric
41- **MDE:** Smallest change worth detecting (recommend 10–20% relative lift for most features)
42- **Statistical power:** 80% (standard)
43- **Significance level:** 95% (p < 0.05)
44 
45For common scenarios, provide pre-calculated estimates:
46 
47| Baseline Rate | MDE (Relative) | Required Sample per Variant |
48|---|---|---|
49| 5% | 20% | ~19,000 |
50| 10% | 15% | ~14,000 |
51| 20% | 10% | ~15,000 |
52| 40% | 10% | ~9,500 |
53| 60% | 5% | ~42,000 |
54 
55Always warn: "These are estimates. Use a tool like Evan Miller's calculator or Statsig for precision."
56 
57## Test Duration Guidance
58 
59Minimum: 2 full weeks (to capture weekly seasonality)
60Maximum: 4 weeks (novelty effect distorts results beyond this)
61 
62`Duration = Required sample ÷ (Daily traffic × % exposed)`
63 
64Flag if traffic is too low to reach significance in under 8 weeks — recommend a different approach (e.g., holdout test, qualitative research).
65 
66## Output Format
67 
68### A/B Test Plan — [Test Name] — [Date]
69 
70**Hypothesis:**
71> [Filled hypothesis template]
72 
73**Variants:**
74- Control (A): [Current experience]
75- Treatment (B): [Changed experience — be specific]
76 
77**Primary Metric:** [Metric name + how measured]
78**Guardrail Metrics:** [Metrics that must not degrade]
79 
80**Target Segment:** [Who sees the test — % of traffic, user type]
81**Traffic Split:** [50/50 recommended unless ramp-up needed]
82 
83**Sample Size Required:** ~[N] users per variant
84**Estimated Duration:** [X] weeks (based on [Y] daily eligible users)
85**Significance Threshold:** 95% confidence, 80% power
86 
87**Exclusions:** [Any user segments to exclude and why]
88 
89**Rollback Trigger:** If [guardrail metric] degrades by [X%], stop the test immediately.
90 
91**Results Interpretation Guide:**
92- ✅ Ship if: Treatment shows [X%]+ lift on primary metric at 95% confidence AND guardrail metrics are stable
93- 🔄 Iterate if: Direction is positive but not significant — consider extending or redesigning
94- ❌ Reject if: No lift or negative direction at significance
95- ⚠️ Inconclusive: Do not ship. Do not call it a win.
96 
97---
98 
99## Guidelines
100 
101- Always recommend against peeking at results before the test reaches planned sample size — explain p-hacking risk
102- If user wants to test multiple variants, explain the multiple comparisons problem and recommend a Bonferroni correction or a Bayesian approach
103- If traffic is very low (<1,000 users/day), recommend qualitative alternatives: moderated testing, 5-second tests, or user interviews
104- Never approve a test with no guardrail metrics — always protect revenue, retention, or core engagement
105 
106## Anti-Patterns
107 
108- [ ] Do not run a test without a directional hypothesis — "let's see what happens" produces uninterpretable results
109- [ ] Do not declare a winner before reaching the pre-planned sample size — peeking at results inflates false positive rates
110- [ ] Do not test multiple independent changes in a single variant — you won't know which change caused the result
111- [ ] Do not use engagement metrics (clicks, time-on-page) as the primary metric when the goal is revenue or retention — proxy metrics mislead
112- [ ] Do not ignore guardrail metrics — a conversion lift that causes a support ticket spike is not a win
113 
114## Deeper Materials
115 
116This skill ships with support files — use them when they are available:
117 
118- **`references/test-validity-traps.md`** — The Validity Traps That Quietly Invalidate A/B Tests. Apply it while producing the output; it carries the calibration and judgment calls the method summary above compresses.
119- **`templates/test-plan.md`** — a fill-in version of the deliverable with the quality gates inline. Offer it when the user wants to work the document themselves rather than have it generated.
120 
121## Scoring Rubric (0–40)
122 
123Score any output of this skill before handing it over; 32+ is ship-quality.
124 
125| Dimension | 0 | 5 | 10 |
126|---|---|---|---|
127| Statistical rigour | No sample size, or a number with no stated baseline/MDE behind it | Sample size present but MDE is guessed or copied from the lookup table without checking the actual baseline; power/significance unstated | Sample size derived from the stated baseline and MDE at 80% power / 95% confidence, duration checked against real daily traffic and the 2–4 week window, and the low-traffic escape hatch invoked if it doesn't fit |
128| Hypothesis discipline | "Let's see what happens" — no direction, no magnitude, or multiple changes bundled into one variant | Directional hypothesis but missing magnitude, segment, or the evidence-based *because*; variant purity not confirmed | Full template filled (change, metric, direction, magnitude, segment, rationale citing data), and the treatment isolates exactly one change with excluded ideas named as follow-up tests |
129| Guardrails & rollback | No guardrail metrics, or a rollback line with no threshold | Guardrails named but denominators/definitions ambiguous; rollback trigger vague ("if things look bad") | 1–2 guardrails protecting revenue or core engagement with pre-agreed definitions, concrete rollback thresholds, and the peeking-vs-harm-monitoring distinction handled explicitly |
130| Decision readiness | No interpretation guide; results will be argued about after the fact | Ship/iterate/reject listed but thresholds fuzzy; inconclusive outcome missing or treated as a soft win | All four outcomes (ship / iterate / reject / inconclusive) mapped to pre-committed thresholds, including what an inconclusive result costs and what each outcome changes next |
131 
132## Quality Checks
133 
134- [ ] Hypothesis is directional (predicts a specific direction and magnitude, not "let's see")
135- [ ] Primary metric is singular (guardrail metrics are secondary)
136- [ ] Sample size is calculated from actual MDE and baseline (not guessed)
137- [ ] Test duration accounts for weekly seasonality (minimum 2 weeks)
138- [ ] Guardrail metrics are defined (at least one to protect revenue or core engagement)
139- [ ] Rollback trigger is specified with a concrete threshold
140 

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 · 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 · MITSignup Flow CROWhen the user wants to optimize signup, registration, account creation, or trial activation flows. Also use when the user mentions "signup conversions," "registration friction," "signup form optimization," "free trial signup," "reduce signup dropoff," "account creation flow," "people aren't signing up," "signup abandonment," "trial conversion rate," "nobody completes registration," "too many steps to sign up," or "simplify our signup." Use this whenever the user has a signup or registration flow that isn't performing. For post-signup onboarding, see onboarding. For lead capture forms (not account creation), see cro.Marketing · MIT