ds-experiment

Executes and records auditable main research experiments against an accepted baseline.

1.1k|116|Updated Feb 26, 2026
One-click install
npx skills add https://github.com/OpenLAIR/dr-claw --skill ds-experiment
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ds-experiment
Source: https://github.com/OpenLAIR/dr-claw/tree/main/skills/ds-experiment
Command: npx skills add https://github.com/OpenLAIR/dr-claw --skill ds-experiment

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Running a research experiment is easy, but producing trustworthy, reproducible evidence is hard. This Skill enforces a disciplined run contract so every main experiment is comparable to its baseline, fully logged, and honestly reported.

Core Features & Use Cases

  • Run Contract Definition: Locks the hypothesis, baseline, dataset split, primary metric, stop condition, and budget before any code is executed.
  • Structured Planning Artifacts: Generates PLAN.md and CHECKLIST.md from canonical templates to control implementation, smoke tests, and the full run.
  • Auditable Execution & Recording: Runs all commands through managed bash sessions with durable logs, then records results via artifact.record_main_experiment with metrics, verdicts, and next-action routing.
  • Use Case: After selecting a research idea and accepting a baseline, use this Skill to implement the change, run a bounded pilot, execute the full training run, and produce a recorded result with a clear supported/refuted/inconclusive verdict.

Quick Start

Ask the agent to run the main experiment for the selected idea against the accepted baseline and record the results with metrics and a verdict.

Frequently Asked Questions about ds-experiment

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run a reproducible machine learning experiment against a baseline?

Define a run contract first: hypothesis, baseline reference, dataset split, primary metric, stop condition, and budget. Then run a bounded smoke test, execute the full run with durable logging, and record metrics with an explicit supported, refuted, or inconclusive verdict.

What should an experiment plan document include before running training?

A main experiment plan should state the research question, null and alternative hypotheses, baseline comparability rules, code touchpoints, smoke and full-run commands, fallback options, monitoring cadence, and a revision log for any route changes.

When should I not start a main experiment run?

Do not start when the baseline gate is unresolved, the idea stage has open tradeoffs, or the evaluation contract is unclear. Resolve those through a decision step first, otherwise the run produces non-comparable evidence.

How do I monitor a long-running training job without losing logs?

Launch the run as a detached managed session, monitor through durable logs with a wait-and-check cadence, and use structured single-line progress markers with ETA. Export the session log into the experiment artifact directory when recording results.

Why are my experiment results not comparable to the baseline?

Comparability breaks when dataset splits, metric definitions, or evaluation code differ between runs. Verify the baseline metric contract, keep the baseline read-only, and record any evaluation change explicitly as supplementary rather than replacing the canonical comparator.

What artifacts should a finished experiment produce?

A complete run leaves a run manifest, metrics.json and metrics.md, summary.md, exported shell logs, config and command pointers, and a claim-validation record mapping each claim to its observed verdict and next action.