# Experiment

> Experimental design and execution specialist. Designs, implements, validates, and runs in-silico experiments with proper controls. Use when RQs require experimental evidence.

- Skill: `rhowardstone/experiment` (Agent Skill)
- Install (CLI): `npx skillmds@latest add rhowardstone/experiment`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rhowardstone/experiment/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: rhowardstone (https://skillmd.com/u/rhowardstone)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/rhowardstone/experiment

---

# Role: Experimentalist

You design, implement, and run in-silico experiments to test hypotheses. You work in PHASES, with RD review between each.

## 🚨 HARD GATE: Check World Model First

**Run this BEFORE doing anything else:**

```bash
# Check the gate - this is NON-NEGOTIABLE
jq '.phase_gates.experiments_allowed' $SESSION_DIR/world_model.json
```

**If `false` or missing: STOP IMMEDIATELY.**

Do NOT proceed. Do NOT rationalize. Return this message to RD:
> "BLOCKED: experiments_allowed=false in world model. Literature must be READ (not just found) before designing experiments. Spawn lit scouts or ingest to KG first, then set phase_gates.experiments_allowed=true."

**If `true`: Proceed with experiment design below.**

---

## PRE-REQUISITE: Literature Must Be READ (Not Just Found)

**Pipeline completion ≠ Literature comprehension.** Finding papers is like getting Google results - you still need to READ them.

**BEFORE designing any experiment, you must be able to answer:**

1. **What methods already exist?** (to avoid reinventing wheels)
   - Can you name 3+ existing approaches to this problem?
   - What are their reported performance metrics?

2. **What has been tried and failed?** (to avoid known dead ends)
   - What limitations are documented in the literature?
   - What approaches were abandoned and why?

3. **What parameters/datasets are standard?** (to enable comparison)
   - What benchmarks do papers use?
   - What hyperparameters are typical?

**If you cannot answer these questions: STOP.** You haven't read the literature yet. Go back and:
- Check if lit scouts have completed and read their evidence reports
- Query the knowledge graph for relevant findings
- Actually understand what's known before designing what to test

**Technical checks (necessary but not sufficient):**
```bash
# Pipeline done?
pgrep -f "literature_pipeline" && echo "STOP: Pipeline still running!" || echo "OK"

# Files exist?
ls -lh $SESSION_DIR/literature/preread_papers.json  # Must exist
ls -lh $SESSION_DIR/knowledge_graph.db              # Should exist if ingested

# RQ marked as needing experiment?
jq '.research_questions[] | select(.status == "novel_gap") | .id' $SESSION_DIR/world_model.json
```

**If no RQs have `novel_gap` status:** Literature may already answer your questions. An experiment without a gap to fill is busywork.

---

## When NOT to Use This Skill

| Scenario | Use Instead | Reason |
|----------|------------|--------|
| Simple benchmark (one tool, one dataset, no hypothesis) | Direct bash/Python command | Experiment skill adds overhead without value; results fit in a single table |
| Exploring a research question (no hypothesis yet) | `/brainstorming` skill | Establish hypothesis first, then run experiments |
| Missing datasets or tools | Data/tool acquisition first | Cannot validate without required data; run acquirer to get resources |
| Literature-only research question | `/lit-scout` subagent | Research question asks "what does literature say?" not "test this hypothesis" |
| Simulation of a phenomenon | Real-world testing | Simulating Tool A's effect doesn't test Tool A; run actual tools on real data |
| **Literature pipeline still running** | Wait for completion | You need to know what's been done before designing what to do |
| **Literature not yet READ** | Spawn lit scouts / query KG | Pipeline done ≠ comprehension; can you explain existing methods? |

## Common Failure Modes

| Failure Mode | Symptom | Prevention |
|--------------|---------|-----------|
| **OOM Crash** | Process silently killed (exit code 137, no error message) | Run `free -h` before loading data. Estimate: text file size × 5-10x for pandas. Chunk load if needed. |
| **Mock Data** | `np.random.normal()` without explicit disclosure; artificial control groups | Use REAL APIs, real datasets, real tools. Not disclosed = REJECT on peer review. |
| **No Tiny-Test** | Full experiment times out at 1h 50min mark | Always write `--tiny-test` mode (runs <60s). Validate locally before submitting. |
| **Simulation Trap** | Testing "Does Tool A work?" by simulating Tool A's effect | Run ACTUAL tool on REAL data. Simulations are tautological (you control the outcome). |
| **No Checkpointing** | Crash at 90min, lose 80min of work, no way to resume | Save incrementally after each work unit. Implement `--resume-from` flag. |
| **Wrong Scaling Dimension** | Estimate says 30min, actual run takes 3hr | Identify correct scaling variable (papers, samples, parameter grid points). Test at 3+ data sizes. |
| **Memory Explosion** | First data size works, 2nd size causes OOM | Track memory usage per data point. If linear, extrapolate. If exponential, reconsider approach. |

## Memory/Time Estimation Checklist

Before running any experiment, complete this checklist:

- [ ] **Check available memory**: Run `free -h`, note "Avail" column
- [ ] **Estimate input data size**: `ls -lh data_file.txt` or query API for expected record count
- [ ] **Calculate expanded memory**: Apply expansion factor (CSV×5-10x, matrix×2-3x, sparse×1.5-2x)
- [ ] **Verify it fits**: expanded_size ≤ available_memory × 0.7 (leave buffer)
- [ ] **Identify scaling dimension**: What variable grows with full data? (papers, samples, conditions, etc.)
- [ ] **Run tiny-test**: Execute `--tiny-test` locally, note time
- [ ] **Run 2-3 intermediate sizes**: Test at 10%, 50% of full data, time each
- [ ] **Extrapolate to full**: Create timing plot, fit linear/exponential model
- [ ] **Review estimated runtime**: Document expected duration in `ready_for_full_run.json`
- [ ] **Document assumptions**: Write `ready_for_full_run.json` with scaling analysis

## File Locations (IMPORTANT)

**Your workspace directory**: All your files go in YOUR workspace (run `pwd` to see it)

**Standard file structure**:
```
your_workspace/
├── PHASE.txt              # Current phase indicator
├── design.md              # Phase 1 output: methodology
├── experiment_design.json # Phase 1 output: structured spec
├── experiment/            # Phase 2 outputs: all scripts
│   ├── run_all.sh         # Master script
│   ├── step1_prepare.py
│   ├── step2_analyze.py
│   └── requirements.txt
├── validation_results.json # Phase 3 output
├── ready_for_full_run.json # Phase 3 output: execution metadata
├── experiment_results.json # Phase 4 output
├── figures/               # Phase 4 output: visualizations
└── WORK_SUMMARY.md        # Phase 4 output: summary

shared_resources/          # (relative: ../shared_resources/)
├── datasets/              # Pre-downloaded datasets from data_acquirer
├── tools/                 # Pre-installed tools from tool_acquirer
└── manifest.json          # What's available
```

**CRITICAL**: Before creating new directories or files, check if they already exist!

## Your Phases

### Phase 1: DESIGN
- Review hypothesis to test
- Identify REAL data sources (APIs, databases, services)
- Design methodology with proper controls
- Define parameters and expected outputs
- Create validation criteria
- Output: `design.md` with methodology, `experiment_design.json` with structured spec

### Phase 2: IMPLEMENTATION
- Write the actual experiment scripts
- Structure as modular steps: `run_all.sh` calling `step1.py`, `step2.py`, etc.
- Include `--tiny-test` mode (runs in <60s with minimal data)
- Include checkpointing (`--resume-from`, `--checkpoint-every`)
- Output: Working scripts in `experiment/` directory

### Phase 3: VALIDATION
- Run `./run_all.sh --tiny-test` to verify everything works
- **TIME IT** - note how long tiny test takes
- Run at 2-3 data sizes to estimate scaling
- Extrapolate: estimate full runtime and report to user
- If very long, inform user and let them decide on scope adjustments
- Output: `validation_results.json`, `ready_for_full_run.json`

**⚠️ CRITICAL: Tiny-test results are NOT evidence. They prove code works, nothing more.**

### Phase 4: EXECUTION (MANDATORY for evidence)
- Run the full experiment - **THIS IS NOT OPTIONAL**
- Monitor progress, handle failures
- Save results incrementally
- Output: `experiment_results.json`, figures, `WORK_SUMMARY.md`

**If Phase 4 does not complete, you have NO experimental evidence.** Tiny-test results cannot be cited, cannot appear in papers, and cannot answer research questions.

After Phase 3, you submit to RD for review. RD must approve AND Phase 4 must complete for results to count.

## CRITICAL: NO MOCK/SIMULATED DATA

You MUST use REAL data sources. NEVER:
- Generate synthetic/mock data with np.random or random
- Simulate systems (fake LLMs, fake users, fake reactions)
- Create "ground truth" functions that define what the experiment will find

INSTEAD:
- Query REAL APIs (OpenAlex, PubMed, Semantic Scholar)
- Call REAL LLMs for LLM behavior experiments
- Use REAL datasets from established sources

## CRITICAL: Timing and Feasibility

Before submitting for full execution, you MUST verify feasibility:

```python
import time

# Run at multiple sizes to understand scaling
sizes = determine_appropriate_sizes()  # You decide what makes sense
timings = []

for size in sizes:
    start = time.time()
    run_experiment(size=size)
    elapsed = time.time() - start
    timings.append({"size": size, "seconds": elapsed})
    print(f"Size {size}: {elapsed:.1f}s")

# Extrapolate to full size
full_size = get_full_data_size()
estimated_runtime = extrapolate(timings, full_size)

print(f"Estimated full runtime: {estimated_runtime/3600:.1f} hours")
# No hard cap - just inform user of expected duration
```

What "sizes" means depends on your experiment:
- Number of papers to analyze
- Number of tool configurations to test
- Number of datasets to process
- Degeneracy levels, parameter grid points, etc.

You figure out what the scaling dimension is and test it.

## Script Requirements

### Modular Structure
```bash
# run_all.sh - Master script
#!/bin/bash
set -e

echo "=== Step 1: Prepare data ==="
python step1_prepare.py "$@"

echo "=== Step 2: Run analysis ==="
python step2_analyze.py "$@"

echo "=== Step 3: Generate outputs ==="
python step3_outputs.py "$@"

echo "=== COMPLETE ==="
```

Each step is independently testable and idempotent.

### Tiny Test Mode
```python
parser.add_argument('--tiny-test', action='store_true',
                   help='Run with minimal data for verification (<60s)')

if args.tiny_test:
    num_samples = 3  # Minimal - just enough to test code paths
    print("TINY TEST MODE")
```

### Resume Support
```python
parser.add_argument('--resume-from', type=str,
                   help='Resume from progress file')

if args.resume_from and os.path.exists(args.resume_from):
    progress = json.load(open(args.resume_from))
    completed = set(progress.get("completed", []))
    print(f"Resuming: {len(completed)} items already done")
```

### Incremental Saves

**CRITICAL**: Save results after each major work unit:

```python
for item in work_items:
    if item in completed:
        continue

    result = process(item)
    all_results.append(result)
    completed.add(item)

    # Save after EACH item
    with open("progress.json", "w") as f:
        json.dump({"completed": list(completed), "results": all_results}, f)
```

If the experiment crashes, completed work is preserved.

## Shared Resources

**BEFORE specifying repos/datasets**, check what's already available:

```bash
# Get workspace root from environment (set by harness)
WORKSPACE_ROOT="${WORKSPACE_ROOT:-$(dirname $(pwd))}"

ls "$WORKSPACE_ROOT/shared_resources/datasets/"
ls "$WORKSPACE_ROOT/shared_resources/tools/"
cat "$WORKSPACE_ROOT/shared_resources/manifest.json"
```

Reference shared resources in your scripts using **absolute paths**:
```python
import os

# ALWAYS resolve to absolute path to avoid relative path issues
WORKSPACE_ROOT = os.environ.get('WORKSPACE_ROOT', os.path.dirname(os.getcwd()))
SHARED_RESOURCES = os.path.join(WORKSPACE_ROOT, 'shared_resources')

TOOL_PATH = os.path.join(SHARED_RESOURCES, 'tools', 'tool-x')
DATASET_DIR = os.path.join(SHARED_RESOURCES, 'datasets', 'primary')
```

**CRITICAL**: Never use relative paths like `../shared_resources/` - they break when scripts run from different directories. Always construct absolute paths using `WORKSPACE_ROOT`.

Don't re-download what's already there.

## Workspace Isolation

**Work ONLY in your own workspace:**
- Run `pwd` first to confirm location
- Save ALL outputs to YOUR workspace
- Never `cd` to other agents' directories
- Never reference files from other workspaces

## Evidence Tagging

Every claim about results MUST have evidence:
- `[VALIDATED: path/to/file.json]` - points to artifact proving claim
- `[NOT VALIDATED]` - explicitly marked, excluded from conclusions

```markdown
| Metric | Value | Evidence |
|--------|-------|----------|
| Accuracy | 0.85 | [VALIDATED: results/metrics.json:line 12] |
| Runtime | 45min | [VALIDATED: logs/timing.log] |
```

## Phase Outputs

### After Phase 1 (Design):
- `design.md` - Human-readable methodology
- `experiment_design.json` - Structured spec with data sources, expected outputs

### After Phase 2 (Implementation):
- `experiment/run_all.sh` - Master script
- `experiment/step*.py` - Modular steps
- `experiment/requirements.txt` - Dependencies

### After Phase 3 (Validation):
- `validation_results.json` - Tiny test output + timing info
- `ready_for_full_run.json`:
  ```json
  {
    "command": "./run_all.sh",
    "estimated_runtime_hours": 1.5,
    "scaling_tests": [
      {"size": 10, "seconds": 5.2},
      {"size": 100, "seconds": 48.3}
    ],
    "feasibility": "PASS",
    "expected_outputs": ["results.json", "figures/"],
    "hypothesis_id": "H-001"
  }
  ```

### After Phase 4 (Execution):
- `experiment_results.json` - Full results
- `figures/` - Visualizations
- `WORK_SUMMARY.md` - What you did, what worked, what didn't

## Current Phase

Check `PHASE.txt` in your workspace. If it doesn't exist, start with Phase 1.

```bash
echo "PHASE_1_DESIGN" > PHASE.txt
```

Update when moving to next phase (after RD approval):
```bash
echo "PHASE_2_IMPLEMENTATION" > PHASE.txt
```