experiment-receipts
Skill3 starsChanged 5 days agoMITView on GitHub
Plans and reads out product experiments (A/B tests, variant tests, usability pilots) with the decision stated first, a precise primary metric, sample size as a planning assumption, guardrails, a privacy-scoped event contract, and a clear split between what was verified and what was simulated. Use when the user designs an A/B test, picks an experiment metric, estimates sample size, instruments analytics events, or writes an experiment readout.
In this repository5 other files it gives its agents.
- ai-eval-receiptsSkill
- claim-receiptsSkill
- metric-receiptsSkill
- plain-copySkill
- prd-receiptsSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Decision first: Write the decision as a question with two outcomes, e.g.
- Very specific: line 14
Sample size as an assumption: Run scripts/sample_size.py with a stated baseline and minimum detectable effect.
- Distinctive: line 18
Readout: Use the template. Keep "verified", "simulated", and "not yet run" in separate sections.
- Distinctive: line 60
Never report a synthetic simulation's conversion rates as evidence that a variant works.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Experiment receipts
An experiment plan should let a skeptical reader see the decision, the metric, and exactly what has and has not been checked. This skill writes the plan and the readout.
Workflow
- Decision first. Write the decision as a question with two outcomes, e.g. "Should intake show every field at once or guide the user through steps?"
- Primary metric. Define it precisely: eligible population, exposure event, success event, counting rule (each participant once), and what success is not (e.g. reaching review is not approval or revenue).
- Sample size as an assumption. Run
scripts/sample_size.pywith a stated baseline and minimum detectable effect. Label the output "planning assumption" until a pilot gives a real baseline. - Guardrails. Metrics that must not get worse (errors, handoffs, time to complete) and the business rules both arms must share.
- Event contract. Allowlist the event names and properties. Exclude free text, names, contact details, and anything not needed for the metric.
- Stopping rule. Fix eligibility, exclusions, horizon, and the stopping rule before collecting randomized traffic.
- Readout. Use the template. Keep "verified", "simulated", and "not yet run" in separate sections.
Sample size script
python3 scripts/sample_size.py --baseline 0.40 --mde 0.15
# per arm: 173 (two-sided alpha 0.05, power 0.80)Options: --alpha (default 0.05), --power (default 0.80). The script uses the standard two-proportion normal approximation and only the Python standard library.
Readout template
# [Experiment name] readout
**Decision:** ...
**Primary metric:** ... (definition)
**Guardrails:** ...
## Verified
- Implementation facts that were actually tested (assignment repeatable, events delivered, properties stripped)
## Simulated or illustrative
- Anything produced with synthetic data, with a note that its rates are authored, not observed
## Not yet run
- Real-user sessions, powered test, business outcomes
## Result
- [Only observed results, with n per arm, interval, and date. If none: "No real-user results yet."]
## Next decision
- ...Example (planning)
Baseline completion 40%, minimum detectable effect 15 percentage points, two-sided 5% significance, 80% power: about 173 participants per arm. Plan for 200 per arm as headroom, and revisit after a usability pilot. These are assumptions, not results.
Rules
- Never report a synthetic simulation's conversion rates as evidence that a variant works.
- A missing user identifier is not enrollment.
- Count exposure before success; ignore success events that precede exposure.
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.

