experiment-design
Skill759 starsChanged 28 days agoMITView on GitHub
Framework for running single-variable cold email experiments. Defines experiment types (list-only, copy-only, combined), confidence weighting, minimum sample sizes, and success criteria. Use when the user wants to improve a campaign, test a new list vs old one, or compare copy variants. Prevents the #1 learning-loop mistake — changing list + copy + offer at once and losing all signal.
We split this skill into the rules it gives an agent
19 rules. 0 are common, 17 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 21 edited versions we read keep these.
17
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
If you change your list, your copy, and your offer at the same time, you learn nothing.
- Distinctive: line 34
What stays fixed: only infrastructure
- Distinctive: line 42
Every experiment starts with a one-sentence hypothesis:
- Distinctive: line 50
If you can't write the hypothesis in one sentence, you don't understand the experiment yet.
- Distinctive: line 54
Write down exactly what changes and what stays the same.
- Distinctive: line 70
If ANY constant is actually changing, stop.
- Distinctive: line 74
Before running any experiment, confirm your baseline is healthy: overall reply rate ≥1% after 200+ sends.
- Distinctive: line 115
Wait until the full sequence (typically Day 0, 3, 7, 11 + reply grace period) has finished for ALL leads.
- Distinctive: line 130
Use this framework when reporting:
- Distinctive: line 154
Winner by 10-20% lift, HIGH confidence: run a replication experiment with fresh leads.
- Distinctive: line 156
Loser: document WHY you think it lost.
- Distinctive: line 157
Combined experiment winner: do NOT adopt as a new baseline.
- Distinctive: line 161
If you're just starting out, don't experiment at all until you have a baseline from a single shipped campaign running for 3 weeks.
- Distinctive: line 172
Don't jump to step 6 when step 1 is broken.
- Distinctive: line 178
Calling it early: Wait 21 days minimum. Cold email replies trickle in over weeks.
- Distinctive: line 179
Changing infrastructure mid-test: If one arm uses new domains and one uses old, deliverability skews everything.
- Distinctive: line 180
Ignoring bounce rate: If variant's bounce rate is 2x control, the list is bad — not the copy.
- Very specific: line 234
Then wait 21 days: before evaluating — reply rate needs that long to stabilize.
- Very specific: line 236
Or wait: if you don't have 2,000+ leads per experiment arm, you can't detect normal-sized effects.
“Common” is measured: kept by at least 6 in 10 of the 21 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Experiment Design
If you change your list, your copy, and your offer at the same time, you learn nothing. This skill forces you to isolate one variable per experiment so you actually learn what's working.
Why this exists
Most cold email operators run "throw-everything" experiments. Campaign 1 gets a new list, new copy, and a new offer. It works better. They declare victory. But they can't tell you WHY — was it the list? The copy? The offer?
Then campaign 2 changes all three again. Regression. Nobody knows why.
This skill is the antidote: plan each experiment around ONE variable, keep everything else constant, and confidence-weight the results.
The three experiment types
A. List-only experiment
- What varies: the list (targeting criteria)
- What stays fixed: copy, offer, sending infrastructure, sequence timing
- What you learn: whether this segment is a better fit than the baseline
- Confidence on learnings: HIGH on targeting, LOW on copy (because copy wasn't tested)
B. Copy-only experiment
- What varies: the copy (subject, body, sequence, or A/B variant)
- What stays fixed: list, offer, infrastructure
- What you learn: whether this copy resonates with this audience
- Confidence on learnings: HIGH on copy, LOW on targeting
C. Combined experiment (use sparingly)
- What varies: list AND copy (and sometimes offer)
- What stays fixed: only infrastructure
- When to use: launching a whole new campaign for a new ICP. You can't isolate because everything is new.
- Confidence on learnings: MEDIUM on everything. Use as hypothesis-generation, not conclusion.
The Framework
Step 1: Name your hypothesis
Every experiment starts with a one-sentence hypothesis:
"Targeting Heads of Marketing at 50-200 person B2B SaaS companies will get a higher positive reply rate than our current VP Sales baseline, because [reason]."
Or:
"Leading with a question about their recent product launch will get a higher reply rate than our current benefit-focused opener, because [reason]."
If you can't write the hypothesis in one sentence, you don't understand the experiment yet. Go back.
Step 2: Identify the single variable
Write down exactly what changes and what stays the same.
Variable: Target job title
Change: "VP Sales" → "Head of Marketing"
Constants:
- Industry filter: unchanged
- Headcount: unchanged
- Geography: unchanged
- Copy: unchanged (same 4-step sequence)
- Offer: unchanged (same lead magnet)
- Sending infrastructure: unchanged (same 20 domains, 40 inboxes)
- Send schedule: unchangedIf ANY constant is actually changing, stop. Either lock it down, or reclassify as a combined experiment.
Baseline sanity check — the 1% rule
Before running any experiment, confirm your baseline is healthy: overall reply rate ≥1% after 200+ sends. If your baseline is below 1% after 200 sends, the problem isn't your experiment — your infrastructure or copy is already broken. Run /email-deliverability-audit first.
Running an experiment on a broken baseline is wasted effort: you'll learn that "both arms are bad," not "which arm wins."
Step 3: Calculate minimum sample size
The smaller your effect, the more leads you need. Use these rough rules for cold email:
| Current baseline | Expected lift | Minimum sends per arm |
| 1% positive reply rate | 2x (1% → 2%) | ~500 |
| 1% positive reply rate | 1.5x (1% → 1.5%) | ~2,000 |
| 1% positive reply rate | 1.2x (1% → 1.2%) | ~10,000 |
| 2% positive reply rate | 2x (2% → 4%) | ~250 |
| 2% positive reply rate | 1.5x (2% → 3%) | ~1,000 |
Rule of thumb: if your test has fewer than 500 sends per arm, you can't tell signal from noise.
For most beginners, 2,000 sends per arm is the right default.
Step 4: Build the success criteria up front
Before launching, write:
Success = positive reply rate > X% (our current baseline is Y%)
Failure = positive reply rate < Z%
Inconclusive = between X and Z
Required sample: at least N sends per arm, reported after day 21 of sequenceDecide now — not after seeing the data. This prevents "oh we learned something else instead" rationalization.
Step 5: Launch both arms simultaneously
Same day, same sending infrastructure split, same sequence. If your control arm sends Monday and your variant arm sends Thursday, day-of-week effects will confound the test.
Best practice in Smartlead/Instantly: create two campaigns, assign each half of your inboxes, launch at the exact same time, same schedule.
Step 6: Measure at day 21
Wait until the full sequence (typically Day 0, 3, 7, 11 + reply grace period) has finished for ALL leads. Measuring earlier biases toward the first email's reply rate.
Pull metrics via /positive-reply-scoring skill:
- Total sent (per arm)
- Total replies (per arm)
- Positive replies (per arm, classified by Claude)
- Positive reply rate = positive replies / total sent
Secondary metrics (report but don't optimize for):
- Overall reply rate (positive replies / total sent is primary, but this shows raw engagement)
- Open rate (if available)
- Bounce rate (sanity check — if one arm bounces more, your list is bad, not your copy)
Step 7: Weight the learnings
Use this framework when reporting:
Experiment: <name>
Type: List-only | Copy-only | Combined
Variable: <what changed>
Result: <winner name> at <positive reply rate>% vs <baseline>%
Confidence: HIGH | MEDIUM | LOW (based on experiment type + sample size)
Learnings (by confidence):
HIGH confidence:
- <thing you can trust>
MEDIUM confidence:
- <thing that looks good but needs replication>
LOW confidence:
- <thing you're speculating about>HIGH only if: experiment type isolates the variable AND sample size meets the minimum.
Step 8: Decide what to do with the result
- Winner by ≥20% lift, HIGH confidence: adopt as new baseline. Document. Move to next experiment.
- Winner by 10-20% lift, HIGH confidence: run a replication experiment with fresh leads. If it wins again, adopt.
- Winner by <10% lift: inconclusive. Run bigger next time or drop.
- Loser: document WHY you think it lost. Don't just move on — the loss is a learning.
- Combined experiment winner: do NOT adopt as a new baseline. Instead, split into single-variable follow-ups to figure out which part actually drove the lift.
What NOT to experiment on (at first)
If you're just starting out, don't experiment at all until you have a baseline from a single shipped campaign running for 3 weeks. You need a control before you can run tests.
Once you have a baseline, the priority order of experiments is usually:
- List (biggest impact — bad list kills any copy)
- Offer / lead magnet (second biggest — "book a call" vs a real magnet)
- Subject line (cheap to test, drives open rate)
- Opener / first line (after subject, the big lever)
- CTA (how you end the email)
- Sequence timing (Day 3 vs Day 2 follow-up)
- Sequence length (4-step vs 6-step)
Don't jump to step 6 when step 1 is broken.
Common mistakes
- A/B testing inside one campaign. Smartlead's A/B variant feature mixes the data — fine for small copy tweaks, terrible for hypothesis testing. Use TWO campaigns for real isolation.
- "I'll test 3 things at once." You'll learn nothing.
- Calling it early. Wait 21 days minimum. Cold email replies trickle in over weeks.
- Changing infrastructure mid-test. If one arm uses new domains and one uses old, deliverability skews everything.
- Ignoring bounce rate. If variant's bounce rate is 2x control, the list is bad — not the copy. Disqualify the test.
Output: experiment plan file
At the end of planning, write to:
~/cold-email-ai-skills/profiles/<business-slug>/experiments/YYYY-MM-DD-<name>.yamlSchema:
experiment:
name: <short name>
hypothesis: <one sentence>
type: list-only | copy-only | combined
variable: <what changes>
constants: <list of what stays fixed>
success_criteria:
positive_reply_rate_target: <float>
baseline: <float>
minimum_sends_per_arm: <int>
measurement_date: <YYYY-MM-DD>
arms:
control:
smartlead_campaign_id: <tbd until launch>
description: <what's in the control>
variant:
smartlead_campaign_id: <tbd until launch>
description: <what's in the variant>
results: <empty until day 21>
control_positive_reply_rate: null
variant_positive_reply_rate: null
winner: null
confidence: null
decision: nullReferences
references/sample-size-calculator.md— longer math for power calculationsreferences/example-experiments/— 3 worked examples (list, copy, combined)/positive-reply-scoringskill — how to actually measure the outcome
What to do next
Launch the planned experiment via /smartlead-campaign-upload-public (manual) or /auto-research-public (automated). Use the variants.yaml from /campaign-copywriting.
Then wait 21 days before evaluating — reply rate needs that long to stabilize. After 21 days, /positive-reply-scoring on each arm.
Or wait: if you don't have 2,000+ leads per experiment arm, you can't detect normal-sized effects. Build a bigger list (/prospeo-full-export, /disco-like) first.
Related skills
/campaign-copywriting— produces the copy variants this experiment tests/smartlead-campaign-upload-public— launches each arm/positive-reply-scoring— measures the outcome after 21 days
Other versions29 projects use a version of this.
Word for word · 0
None found.
Edited · 1
- automatewithuday/GTM-Skills★ 190% same
Wrote their own version · 28
- microsoft/hve-core★ 1.6ksame name
- lingzhi227/agent-research-skills★ 350same name
- Yeachan-Heo/My-Jogyo★ 241same name
- flonat/flonat-research★ 145same name
- voidful/academic-skills★ 126same name
- itseffi/agentic-os★ 114same name
- pratikshadake/claude-product-management-skills★ 33same name
- TashanGKD/tashan-research-skills★ 19same name
- opensite-ai/opensite-skills★ 15same name
- lenar-amirov/product-pipeline-public★ 13same name
18 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository51 other files it gives its agents.
- auto-research-publicSkill
- blitz-list-builderSkill
- campaign-copywritingSkill
- campaign-strategySkill
- cold-email-kickoffSkill
- cold-email-starter-kitSkill
- cold-email-weekly-rhythmSkill
- competitor-engagersSkill
- deliverability-incident-responseSkill
- deliverability-test-publicSkill
- disco-likeSkill
- email-deliverability-auditSkill
- google-maps-list-builderSkill
- icp-onboardingSkill
- icp-prompt-builderSkill
- inbox-lifecycle-managerSkill
- lead-magnet-brainstormSkill
- list-builderSkill
- list-expanderSkill
- list-quality-scorecardSkill
- perfect-company-listSkill
- personalization-subagent-patternSkill
- clay-playbooksSkill
- playbook-ad-librarySkill
- playbook-ai-specificitySkill
- playbook-case-study-pageSkill
- playbook-company-name-cleaningSkill
- playbook-creative-ideasSkill
- playbook-first-name-cleaningSkill
- playbook-fundraisingSkill
- playbook-google-site-searchSkill
- playbook-hiring-surgeSkill
- playbook-job-posting-languageSkill
- playbook-linkedin-engagementSkill
- playbook-lookalikesSkill
- playbook-name-to-other-prospectsSkill
- playbook-new-in-roleSkill
- playbook-pricing-pageSkill
- playbook-social-link-findingSkill
- playbook-social-postsSkill
- playbook-tech-on-websiteSkill
- playbook-warm-introsSkill
- positive-reply-scoringSkill
- prospeo-full-exportSkill
- prospeo-search-apiSkill
- smartlead-apiSkill
- smartlead-campaign-upload-publicSkill
- smartlead-inbox-managerSkill
- smartlead-spintaxSkill
- spam-word-checkerSkill
- zapmail-domain-setup-publicSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

