agentleFS
ai-analyst-labai-analyst-lab/ai-analyst/.claude/skills/experiment/SKILL.md

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

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.
  • maxvaegaSkill

    cost

    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

  • dirienSkill

    decide

    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

  • javatarzSkill

    wiki

    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

  • HeshamFSSkill

    loop

    Run a command or check on a recurring interval

    Also in 3 projects that use this

  • VercelSkill

    workflow

    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

  • ibahgatSkill

    autopilot

    Run autonomous multi-stage execution loops until acceptance criteria pass or blockers are reached.

    Also in 3 projects that use this

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
  1. Distinctive:

    Purpose: Create a pre-registered experiment config.

    line 26
  2. Distinctive:

    Run Experiment Brief skill to capture hypothesis, north star, guardrails

    line 29
  3. Very specific:

    Read experiments/{slug}/experiment.yaml for metric type, baseline, MDE

    line 37
  4. Very specific:

    Update experiment.yaml with computed values (sample_size, duration, viable)

    line 42
  5. Very specific:

    If NOT_VIABLE → suggest /causal select as alternative

    line 43
  6. Distinctive:

    Purpose: Run statistical tests on experiment data.

    line 47
  7. Very specific:

    Read experiments/{slug}/experiment.yaml for pre-registered config

    line 50
  8. Very specific:

    Read analysis results from experiments/{slug}/working/analysis_results.json

    line 84
  9. Distinctive:

    Read analysis results (structured JSON, not re-computing)

    line 101
  10. Very specific:

    Read experiment.yaml for context

    line 102
  11. Very specific:

    Read experiment.yaml for expected allocation and guardrail thresholds

    line 111
  12. Very specific:

    Run srm_check() with p < 0.0005 threshold (Microsoft production standard)

    line 112
  13. Distinctive:

    Run guardrail tests (one-sided where appropriate)

    line 113
  14. Distinctive:

    No agent needed — direct YAML read and format

    line 124
  15. Very specific:

    Checkpoints: All Type C checkpoints fire.

    line 129
  16. Very specific:

    All statistical work uses coded helpers from helpers/stats/experiment_stats/:

    line 146

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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:

  1. Run Experiment Brief skill to capture hypothesis, north star, guardrails
  2. Invoke Experiment Designer agent
  3. Output: experiments/{slug}/experiment.yaml (from templates/experiment.yaml) Checkpoint: Config review (Type B — skippable with --just-do-it)

/experiment power

Purpose: Power analysis + duration estimation. Flow:

  1. Read experiments/{slug}/experiment.yaml for metric type, baseline, MDE
  2. Call helpers/stats/experiment_stats/power.py:
    • Proportion metric → power_proportion(baseline_rate, mde)
    • Continuous metric → power_mean(baseline_mean, baseline_std, mde)
  3. Call duration_estimate(total_sample, daily_traffic, allocation)
  4. Update experiment.yaml with computed values (sample_size, duration, viable)
  5. If NOT_VIABLE → suggest /causal select as 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:

  1. Read experiments/{slug}/experiment.yaml for pre-registered config
  2. 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
  3. 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)
  4. Effect size: cohens_d(control, treatment)
  5. Multiple comparisons: adjust_pvalues(all_p_values, method="holm")
  6. Guardrail checks against thresholds from experiment.yaml
  7. Segment analysis (Simpson's paradox check)
  8. Output: experiments/{slug}/working/analysis_results.json Checkpoint: 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:

  1. Read analysis results from experiments/{slug}/working/analysis_results.json
  2. 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
  3. Apply Spotify's EwL classification: Ship / Abort / Learn / Invalid
  4. Reference pre-registered decision rules from experiment.yaml
  5. 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:

  1. Read analysis results (structured JSON, not re-computing)
  2. Read experiment.yaml for context
  3. Fill report template (templates/experiment-report.md)
  4. Adapt to audience (executive/technical/cross-functional)
  5. 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:

  1. Read experiment.yaml for expected allocation and guardrail thresholds
  2. Run srm_check() with p < 0.0005 threshold (Microsoft production standard)
  3. Run guardrail tests (one-sided where appropriate)
  4. Track sample accumulation vs. required sample size
  5. 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:

  1. Read experiments/{slug}/experiment.yaml
  2. Display: current status, key metrics, timeline, any blockers
  3. 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}}.md

Helper Function Reference

All statistical work uses coded helpers from helpers/stats/experiment_stats/:

FunctionModuleUse For
welch_test()ab_testsContinuous metric A/B test
proportion_test()ab_testsBinary metric A/B test
ratio_metric_test()ab_testsRatio metric (delta method)
winsorize()ab_testsOutlier-robust pre-processing
power_proportion()powerSample size for proportions
power_mean()powerSample size for means
detectable_effect()powerMDE from fixed sample
duration_estimate()powerTimeline planning
srm_check()srmSample ratio mismatch
srm_diagnose()srmSegmented SRM root cause
cohens_d()effect_sizeStandardized effect size
relative_lift()effect_sizePercentage change
adjust_pvalues()correctionsMultiple comparison correction
cuped_adjust()variance_reductionCUPED variance reduction
confidence_sequence()sequentialAlways-valid CI (peeking ok)
bayesian_proportion()bayesianBayesian A/B (proportions)
bayesian_mean()bayesianBayesian 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

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.