mcpbeat Sign in

Rigorous Experiments Agent Skill

This skill should be used when designing, running, validating, or auditing statistical experiments on personal or observational time-series data (health metrics, speech/text corpora, behavioral logs, diaries, n-of-1 self-tracking). It enforces pre-registration, exact permutation tests, FDR discipline, data-validation gates, adversarial code review, and cross-validation with external models. Triggers on "design an experiment", "test this hypothesis on my data", "is this correlation real", "audit these findings", "pre-register", "validate this dataset", or any n-of-1 / quantified-self analysis request.

21k tokens
context cost
the whole folder, loaded on every use
16
files
ships runnable scripts
0
copies elsewhere
how many repositories repackaged it
337
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/glebis/claude-skills --skill rigorous-experiments

What comes with it

78 871 bytes besides the instruction
dist.zip
evals/cases/bad_exp.py
evals/cases/bad_results.json
evals/cases/cases.json
evals/cases/good_exp.py
evals/cases/good_results.json
evals/run_evals.py
references/cross-validation.md
references/data-validation.md
references/design.md
references/lead-investigation.md
references/statistics.md
scripts/explorer.py
scripts/perm_stats.py
scripts/triage.py

The instruction itself

6 sections, as written by the author

Rigorous Experiments

Run statistical experiments on observational/personal time-series data that

survive scrutiny. Distilled from a 54-experiment n-of-1 program in which

sampled permutation tests, missing-data artifacts, app-categorization bugs

and collinear mechanisms repeatedly manufactured — and then destroyed —

"findings". Every rule here exists because its absence once produced a

wrong conclusion.

Modes

Pick the mode matching the request; chain them for a full study.

| Mode | When | Reference |

|------|------|-----------|

| design | New hypothesis or study | references/design.md |

| conduct | Implementing + running the experiment | references/statistics.md |

| validate-data | Before trusting ANY new data source | references/data-validation.md |

| cross-validate | Findings worth defending; code review; external model review (e.g. GPT Pro) | references/cross-validation.md |

| investigate-leads | A sweep/run produced leads (p<0.06, not FDR-confirmed) | references/lead-investigation.md |

| audit | Re-examining past claims, registries of findings | references/statistics.md §Audit |

Non-negotiable core (all modes)

  • Pre-register before computing. Hypotheses, exact tests, family size

m, and the acceptance threshold go in the script docstring BEFORE the

first run. Post-hoc tests are reported as descriptive, never promoted.

  • Exact permutation, never sampled, on small n. A session sequence of

n=19 has 18 circular shifts: the minimum honest p is ~1/19≈0.05.

Sampling 2000 shifts with replacement fabricates precision (this killed

a flagship "q=0.028" finding). Use scripts/perm_stats.py.

  • Permute over the full calendar, not the compressed series. Shifting

a gap-compressed series breaks the timeline; keep missingness as NaN

masks re-applied per shift. Event indicators must be pure 0/1 with no

gaps — missingness lives only in the outcome series.

  • BH with FIXED family size m, a LITERAL CONSTANT declared at design

time — never len(tests) (that defeats pre-registration; the linter

rejects it). Assert the run matches the declared m. Confirmatory

families small and separate from exploratory sweeps; pooling everything

into one BH buries true effects, cherry-picking families manufactures

them. Plain BH assumes independent/positively-dependent tests; for

strongly dependent lag families use BH-Yekutieli or maxT resampling.

  • Stationarity check before correlating trending series. Exact

circular shift on a trending series is "exactly, reproducibly wrong":

report prewhitened-r (AR1 residuals) and stationary bootstrap alongside.

  • Stratify before pooling (Simpson check): within group (e.g.

therapy/coaching) and within regime (pre/post known breaks). A pooled

r=−0.25 once hid therapy −0.64 vs coaching +0.53.

  • Controls can re-describe a finding, not just kill it. When a control

collapses an effect, check collinearity of control and predictor —

r(self-focus, session-length)=0.79 meant "mechanism ambiguous", not

"effect fake". Report the decomposition.

  • Honest statuses: confirmed (q<0.10 exact) ≠ lead (p<0.06) ≠ null ≠

descriptive. Status flips are recorded, never silently edited. Nulls

with adequate power are findings. Robust ≠ significant: a lead

surviving leave-one-out at small n is still underpowered — a candidate

for prospective test, not a finding.

8b. Series scope is part of the test. A lagged "[t+1]" means the next

unit in the series the hypothesis is about, not the next pooled row;

define scope before lagging (it once flipped a sign). When recomputing

a prior result, reproduce a stored artifact on that scope first.

  • Privacy: raw text/audio never enters output files or external

uploads — statistics, rates and embedding-derived scores only.

10. Plain-language reporting: every statistic carries its practical

meaning inline; define r/p/q/n once per report; no untranslated jargon

calques. Narrative first, numbers as support.

Workflow (full study)

  • validate-data gate on any new source (see reference — the checklist

has caught: zero-vs-missing conflation, dedup semantics, substring

category bugs, rolling purge windows, timezone conventions).

  • design: pre-registered hypotheses + family + power sanity.
  • conduct: implement with scripts/perm_stats.py; run; write results

JSON with tests, statuses, and caveats including known limitations.

  • cross-validate: adversarial code review (e.g. Codex read-only) BEFORE

trusting results; fix findings; re-run. For major claims, external

model review with a privacy-screened archive.

  • investigate-leads on anything that surfaced as a lead (not at the

same scale — the triage battery: LOO, directionality, detrend-vs-step,

within-cycle, prewhiten+bootstrap; consolidate same-direction leads

into one composite). Mark diagnostic runs descriptive_only: true.

  • Verdicts in honest prose (mixed/rejected allowed); report; registry

update with status provenance.

Viewing results

Launch the bundled explorer over any directory of results JSONs:

python3 scripts/explorer.py <results_dir> [--port 8799] [--pattern "exp*.json"] [--sort newest|oldest]

Generates explorer.html in the directory, starts (or reuses) a loopback

http server on the port, and opens the browser: experiment list with

confirmed/lead badges, filter, sortable test tables color-coded by

status, verdicts, caveats, raw JSON. The page fetches result files live —

re-running experiments updates the view; re-run the script only when new

result files appear. Serve over localhost, never file:// (CDN fonts) and

never on a non-loopback interface (results may contain personal

statistics).

Evals

Run python3 evals/run_evals.py (from the skill directory) to lint an

experiment script/results pair against the standards (pre-registration

present, fixed literal m, exact perm usage, caveats, no raw text in

outputs). A diagnostic/triage run that intentionally mints no new tests

sets descriptive_only: true in its results JSON to satisfy the

"has tests" check. Eval cases in evals/cases/ document expected

pass/fail examples.

Other skills for the same job

different authors, same section of the catalogue
Update Solution Analyzer
by Azure

MANDATORY guidelines for ANY edit to ANY file under Tools/Solutions Analyzer/ — including the mapper (map_solutions_connectors_tables.py), doc generator (generate_connector_docs.py), interactive docs (generate_interactive_docs.py), ASIM browser, collect_table_info, collect_asim_fields, upload_to_kusto, compare_runs, solution_analyzer_overrides.csv, filter_field_resolution.yaml, or any other script/config in that folder. Use when: editing/modifying/refactoring/fixing/renaming/tweaking ANY logic in those files, even one-line fixes such as renaming a classification, escaping a character, adjusting a regex, adding an override row, suppressing a false positive, or changing a constant. Covers: keeping script-docs in sync, README Version History changelog rules (required for feature/behavior changes; optional for small bug fixes), CSV output sync with upload_to_kusto.py, static/interactive index synchronization, and markdown/HTML entity page synchronization.

1k tokens
Pr Triage Report
by microsoft
vendor

> Generate a Markdown triage report for open, non-draft pull requests in microsoft/ebpf-for-windows, including CI, freshness, sign-offs, and next-owner routing.

3k tokens
Report Bug
by artokun

Self-heal + report bugs to make the ecosystem better. When you hit ANY defect in comfyui-mcp / the sidebar panel, OR in a third-party custom node / ComfyUI core, use this: diagnose it, and for OUR repos (comfyui-mcp / comfyui-mcp-panel) **fix it locally FIRST** — patch the code where it actually runs so the user is unblocked immediately — then file a report that includes the diff, so reports arrive as near-PRs, not just tickets. (Attempt the fix exactly ONCE; if it's genuinely upstream-only, mark it and include the precise change needed.) Report it the right way: our intake Worker for our repos; the node's own GitHub for third-party. For OUR repos (artokun/comfyui-mcp, comfyui-mcp-panel, comfyui-mcp-issue-worker) act **autonomously** — fix-then-file and just inform the user, no per-step permission. For THIRD-PARTY / ComfyUI-core it is **offer-and-ask**: propose the workaround/report and act only with the user's go-ahead. **BETA — bias HARD toward fix-then-file (our repos):** trigger on any comfyui-mcp/panel defect you notice — an error, a crash, a tool that returns wrong/misleading/empty output, a silent failure, a confusing result, or a limitation that forced an awkward workaround — EVEN IF you recovered or worked around it. You do NOT need to be blocked. Also on "report this" / "fix this bug". If a future user would hit the same friction, fix-and-file it — the intake Worker dedupes, so over-reporting is cheap and under-reporting costs us the bug. THIRD-PARTY / ComfyUI-core bugs stay offer-and-ask.

4k tokens
Tech Debt Tracker
by borghei

> Scan codebases for technical debt with AST parsing, prioritize by impact, and generate trend dashboards. Use when tracking tech debt, prioritizing refactoring, calculating cost-of- delay, planning sprint debt, or reporting debt to execs.

86k tokens scripts
Report Revisions
by Azure

List APIView revisions created or actually opened/viewed in a date range, broken out by language and type. Use for: created revisions, opened revisions, viewed revisions, revision counts, how many revisions, revisions for March, revision breakdown, revision types, automatic vs manual revisions, PR revisions, pull request revisions, page views, actually viewed, who opened reviews, opened revision breakdown.

1k tokens
Product UI Review
by JasonxzWen

Load when an existing Web product, especially a dashboard, dense-data view, or multi-step app, needs a deep evidence-backed experience review; report findings only, and use design-taste-frontend for marketing-page direction, code-review for source diffs, web-design-guidelines for checklist compliance, or frontend-design for implementation.

2k tokens
Cto Advisor
by aAAaqwq

> Technical leadership guidance for engineering teams, architecture decisions, and technology strategy. Includes tech debt analyzer, team scaling calculator, engineering metrics frameworks, technology evaluation tools, and ADR templates. Use when assessing technical debt, scaling engineering teams, evaluating technologies, making architecture decisions, establishing engineering metrics, or when user mentions CTO, tech debt, technical debt, team scaling, architecture decisions, technology evaluation, engineering metrics, DORA metrics, or technology strategy.

21k tokens scripts
Otel Weaver
by ollygarden

OpenTelemetry Weaver registry authoring, codegen, and CI enforcement. Use when adopting Weaver, authoring or reviewing a registry (manifest, attributes, metrics, spans, events), writing Jinja2 templates against the resolved schema, migrating hand-maintained telemetry constants, or wiring `weaver registry check`/`generate`/`diff` into CI.

9k tokens scripts

How to use it

Copy the folder

Take glebis/rigorous-experiments from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.