experiment
Skill304 starsChanged 2 months agoMITView on GitHub
The analysis and lifecycle owner for experiments. Full experiment lifecycle: design, power analysis, statistical analysis, interpretation, reporting, and monitoring of A/B tests. Invoke as /experiment. Trigger on "A/B test", "experiment", "treatment vs control", "sample size", "MDE", "statistical significance", "ship decision", "test readout", "is this result significant?". Runs the SRM gate first.
29 other projects use a version of this.
Adopted by
Most recently taken up by
- adithyanraj03/dsh-skills-packtheir own version, first seen Nov 15, 2026
- HiteSit/real-scientist-skillstheir own version, first seen Nov 15, 2026
- SethGammon/Citadeltheir own version, first seen Nov 4, 2026
- DaeSeokSong/oh-my-ouroborostheir own version, first seen Nov 1, 2026
- Anglesite/anglesite-skillstheir own version, first seen Oct 27, 2026
- simota/agent-skillstheir own version, first seen Oct 23, 2026
Used with
Projects with it also use cost, decide and 8 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
maxvaegaSkillcost
Estimate what Claude Cowork / Claude Code conversations would cost if run on the pay-per-token Claude API instead of the subscription. Reports token counts and cache-aware API cost in USD and EUR, for the current conversation or for the whole history (cost per conversation). Trigger when the user asks things like "how much would this conversation cost on the API", "API cost of my Cowork conversations", "token usage / token count", "cost per conversation", "/cost", or wants to compare subscription vs API pricing.
Also in 3 projects that use this
dirienSkilldecide
Three-agent adversarial debate protocol for strategic decisions. Two advocates steelman opposing positions while a moderator identifies risks and synthesizes a binding consensus. Use when choosing between alternatives, evaluating tradeoffs, or making high-stakes decisions.
Also in 3 projects that use this
javatarzSkillwiki
Access and manage the local GitHub Wiki clone. Use this skill when you need to read wiki content (architecture, design docs, guides), update wiki documentation, check wiki status, or push wiki changes. The wiki contains high-level system design and architectural documentation.
Also in 3 projects that use this
HeshamFSSkillloop
Run a command or check on a recurring interval
Also in 3 projects that use this
VercelSkillworkflow
Creates durable, resumable workflows using Vercel's Workflow SDK. Use when building workflows that need to survive restarts, pause for external events, retry on failure, or coordinate multi-step operations over time. Triggers on mentions of "workflow", "durable functions", "resumable", "workflow sdk", "queue", "event", "push", "subscribe", or step-based orchestration.
Also in 3 projects that use this
ibahgatSkillautopilot
Run autonomous multi-stage execution loops until acceptance criteria pass or blockers are reached.
Also in 3 projects that use this
Other versions29 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 29
- rohanpsingh/LearningHumanoidWalking★ 1.2ksame name
- SethGammon/Citadel★ 927same name
- menkesu/awesome-pm-skills★ 441same name
- simota/agent-skills★ 99same name
- sunnnybala/Rstack★ 69same name
- Kastalien-Research/thoughtbox★ 64same name
- logly/mureo★ 64same name
- alirezarezvani/gaios★ 37same name
- skyf0xx/gambit★ 29same name
- HiteSit/real-scientist-skills★ 27same name
19 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 repository65 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- always-compareSkill
- analysis-designSkill
- analyst-coreSkill
- archaeologySkill
- archive-analysisSkill
- auth-preflightSkill
- businessSkill
- causalSkill
- chart-to-driveSkill
- close-the-loopSkill
- codex-reviewSkill
- compare-datasetsSkill
- connect-dataSkill
- connect-snowflakeSkill
- context-compareSkill
- context-traceSkill
- data-inspectSkill
- data-mapSkill
- data-profilingSkill
- data-quality-checkSkill
- datasetsSkill
- distribution-profilerSkill
- evalSkill
- evaluate-graderSkill
- experiment-briefSkill
- exploreSkill
- exportSkill
- forecastSkill
- google-doc-exportSkill
- google-slides-exportSkill
- guardrailsSkill
- historySkill
- improve-contextSkill
- knowledge-bootstrapSkill
- log-correctionSkill
- maintain-contextSkill
- metric-specSkill
- metricsSkill
- monitor-evalsSkill
- notion-exportSkill
- paceSkill
- patternsSkill
- question-framingSkill
- question-routerSkill
- reliabilitySkill
- resume-pipelineSkill
- run-pipelineSkill
- runsSkill
- score-analysisSkill
- session-handoffSkill
- setup-dev-contextSkill
- setup-notionSkill
- setupSkill
- setup-slackSkill
- setup-snowflakeSkill
- srm-checkSkill
- stakeholder-communicationSkill
- stress-testSkill
- switch-datasetSkill
- The first 60 shown.
The file
Show its rules and text
We split this skill into the rules it gives an agent
16 rules. 0 are common, 6 are distinctive, and 10 are very specific to this project.
0
Common
Most of the 27 edited versions we read keep these.
6
Distinctive
This author's own choices. Worth a look.
10
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 26
Purpose: Create a pre-registered experiment config.
- Distinctive: line 29
Run Experiment Brief skill to capture hypothesis, north star, guardrails
- Very specific: line 37
Read experiments/{slug}/experiment.yaml for metric type, baseline, MDE
- Very specific: line 42
Update experiment.yaml with computed values (sample_size, duration, viable)
- Very specific: line 43
If NOT_VIABLE → suggest /causal select as alternative
- Distinctive: line 47
Purpose: Run statistical tests on experiment data.
- Very specific: line 50
Read experiments/{slug}/experiment.yaml for pre-registered config
- Very specific: line 84
Read analysis results from experiments/{slug}/working/analysis_results.json
- Distinctive: line 101
Read analysis results (structured JSON, not re-computing)
- Very specific: line 102
Read experiment.yaml for context
- Very specific: line 111
Read experiment.yaml for expected allocation and guardrail thresholds
- Very specific: line 112
Run srm_check() with p < 0.0005 threshold (Microsoft production standard)
- Distinctive: line 113
Run guardrail tests (one-sided where appropriate)
- Distinctive: line 124
No agent needed — direct YAML read and format
- Very specific: line 129
Checkpoints: All Type C checkpoints fire.
- Very specific: line 146
All statistical work uses coded helpers from helpers/stats/experiment_stats/:
“Common” is measured: kept by at least 6 in 10 of the 27 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
Skill: /experiment — OpenXP Experimentation Platform
Purpose
Multi-mode skill for the full experiment lifecycle — from design through analysis to ship/no-ship decision. Orchestrates experiment agents and calls coded statistical helpers from helpers/stats/experiment_stats/ instead of improvising Python.
When to Use
Invoke as /experiment [mode] or trigger on experiment-related intents:
- "I want to run an experiment"
- "Analyze this A/B test"
- "Did this experiment work?"
- "What's the power for this test?"
Modes
/experiment design
Purpose: Create a pre-registered experiment config.
Agent: agents/experiments/experiment-designer.md
Flow:
- Run Experiment Brief skill to capture hypothesis, north star, guardrails
- Invoke Experiment Designer agent
- Output:
experiments/{slug}/experiment.yaml(fromtemplates/experiment.yaml) Checkpoint: Config review (Type B — skippable with --just-do-it)
/experiment power
Purpose: Power analysis + duration estimation. Flow:
- Read
experiments/{slug}/experiment.yamlfor metric type, baseline, MDE - Call
helpers/stats/experiment_stats/power.py:- Proportion metric →
power_proportion(baseline_rate, mde) - Continuous metric →
power_mean(baseline_mean, baseline_std, mde)
- Proportion metric →
- Call
duration_estimate(total_sample, daily_traffic, allocation) - Update
experiment.yamlwith computed values (sample_size, duration, viable) - If NOT_VIABLE → suggest
/causal selectas alternative Checkpoint: Power viability (Type C — NOT_VIABLE fires mandatory checkpoint)
/experiment analyze
Purpose: Run statistical tests on experiment data.
Agent: agents/experiments/experiment-analyzer.md
Flow:
- Read
experiments/{slug}/experiment.yamlfor pre-registered config - SRM Gate (mandatory first step):
from helpers.stats.experiment_stats import srm_check # Positional lists ONLY — do not pass dicts. # First arg: observed counts per variant (order must match expected_ratios). # Second arg: expected allocation ratios, summing to 1.0. result = srm_check([4218, 4196], [0.5, 0.5]) # result = {"chi2_stat": 0.058, "p_value": 0.81, "verdict": "PASS", ...} if result["verdict"] == "BLOCK": # HALT — do not proceed to treatment effect analysis - Treatment effect analysis using coded helpers:
from helpers.stats.experiment_stats import welch_test, proportion_test, ratio_metric_test # Select based on metric type from experiment.yaml if metric_type == "proportion": result = proportion_test(c_success, c_n, t_success, t_n) elif metric_type == "continuous": result = welch_test(control_values, treatment_values) elif metric_type == "ratio": result = ratio_metric_test(num_c, den_c, num_t, den_t) - Effect size:
cohens_d(control, treatment) - Multiple comparisons:
adjust_pvalues(all_p_values, method="holm") - Guardrail checks against thresholds from experiment.yaml
- Segment analysis (Simpson's paradox check)
- Output:
experiments/{slug}/working/analysis_results.jsonCheckpoint: SRM gate (Type C — BLOCK halts everything)
/experiment interpret
Purpose: Walk the Result Interpretation Tree and classify the outcome.
Agent: agents/experiments/experiment-interpreter.md
Flow:
- Read analysis results from
experiments/{slug}/working/analysis_results.json - Walk the Result Interpretation Tree:
- Positive result + clean guardrails → SHIP
- Positive result + degraded guardrails → INVESTIGATE (Mixed Results Framework)
- Null result (powered) → ABORT (no evidence of benefit)
- Null result (underpowered) → LEARN (extend or re-design)
- Negative result → ABORT
- SRM or data quality issue → INVALID
- Apply Spotify's EwL classification: Ship / Abort / Learn / Invalid
- Reference pre-registered decision rules from experiment.yaml
- Output: classification + rationale Checkpoint: Ship decision (Type C — always fires); INVALID → refuse to proceed
/experiment report
Purpose: Generate markdown report from analysis results.
Agent: agents/experiments/experiment-readout.md
Flow:
- Read analysis results (structured JSON, not re-computing)
- Read experiment.yaml for context
- Fill report template (
templates/experiment-report.md) - Adapt to audience (executive/technical/cross-functional)
- Output:
experiments/{slug}/reports/experiment_report_{{DATE}}.md
/experiment monitor
Purpose: SRM check + guardrail status + sample tracking during a running experiment.
Agent: agents/experiments/experiment-monitor.md
Flow:
- Read experiment.yaml for expected allocation and guardrail thresholds
- Run
srm_check()with p < 0.0005 threshold (Microsoft production standard) - Run guardrail tests (one-sided where appropriate)
- Track sample accumulation vs. required sample size
- Output:
experiments/{slug}/working/monitoring_update.md- Traffic light status: GREEN (on track) / YELLOW (watch) / RED (halt) Checkpoint: RED guardrail (Type C — triggers halt)
/experiment status
Purpose: Show experiment lifecycle state. Flow:
- Read
experiments/{slug}/experiment.yaml - Display: current status, key metrics, timeline, any blockers
- No agent needed — direct YAML read and format
/experiment full
Purpose: End-to-end: design → power → analyze → interpret → report. Flow: Runs design, power, analyze, interpret, report in sequence. Checkpoints: All Type C checkpoints fire. Type B skipped with --just-do-it.
State Management
experiments/{slug}/
├── experiment.yaml # Pre-registered config (tracked)
├── working/ # Intermediates (gitignored)
│ ├── analysis_results.json
│ ├── monitoring_update.md
│ └── ...
└── reports/ # Final reports (tracked)
└── experiment_report_{{DATE}}.mdHelper Function Reference
All statistical work uses coded helpers from helpers/stats/experiment_stats/:
| Function | Module | Use For |
welch_test() | ab_tests | Continuous metric A/B test |
proportion_test() | ab_tests | Binary metric A/B test |
ratio_metric_test() | ab_tests | Ratio metric (delta method) |
winsorize() | ab_tests | Outlier-robust pre-processing |
power_proportion() | power | Sample size for proportions |
power_mean() | power | Sample size for means |
detectable_effect() | power | MDE from fixed sample |
duration_estimate() | power | Timeline planning |
srm_check() | srm | Sample ratio mismatch |
srm_diagnose() | srm | Segmented SRM root cause |
cohens_d() | effect_size | Standardized effect size |
relative_lift() | effect_size | Percentage change |
adjust_pvalues() | corrections | Multiple comparison correction |
cuped_adjust() | variance_reduction | CUPED variance reduction |
confidence_sequence() | sequential | Always-valid CI (peeking ok) |
bayesian_proportion() | bayesian | Bayesian A/B (proportions) |
bayesian_mean() | bayesian | Bayesian A/B (means) |
Cross-Product Handoffs
/experiment power→ NOT_VIABLE → suggest/causal select(quasi-experimental)/causal select→ "Can you randomize? YES" → suggest/experiment design/experiment analyze→ SRM BLOCK → suggest investigating assignment logic
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.

