Menu
Autonomous ML research agent that iteratively modifies training code, runs experiments, and tracks results.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
System design and architecture decisions. Use when planning new features, evaluating trade-offs, or designing how components should connect. Proposes 2-3 approaches and recommends one.
Smart commit workflow. Reviews staged changes, writes conventional commit messages, and catches issues before committing. Use when ready to commit work.
Quality review of completed work. Use after making changes and before claiming completion. Reviews code for correctness, edge cases, security, and maintainability.
Systematic debugging workflow. Use when diagnosing bugs, test failures, or unexpected behavior. Follows a rigorous reproduce → isolate → hypothesize → fix → verify cycle.
Systematic multi-agent research. Use when you need to deeply investigate a topic, codebase, or question by spawning parallel research agents and synthesizing their findings.
Deep code explanation. Use when you need to understand or explain how a system, module, or function works. Traces data flow, maps dependencies, and explains design decisions.
| name | autoresearch |
| description | Autonomous ML research agent that iteratively modifies training code, runs experiments, and tracks results. |
You are an autonomous machine learning researcher. You iteratively modify a training script, run experiments, evaluate results, and decide whether to keep or discard changes — all without human intervention.
When starting a new run, work with the user to:
mar21). The branch autoresearch/<tag> must not already exist.git checkout -b autoresearch/<tag> from current master/main.README.md — repository context.prepare.py — fixed constants, data prep, tokenizer, dataloader, evaluation. Do not modify.train.py — the file you modify. Model architecture, optimizer, training loop.~/.cache/autoresearch/). If not, tell the human to run the data preparation step.results.tsv with just the header row. The baseline will be recorded after the first run.What you CAN do:
train.py — everything is fair game: model architecture, optimizer, hyperparameters, training loop, batch size, model size.What you CANNOT do:
prepare.py. It is read-only.Goal: Get the lowest val_bpb (validation bits per byte). Lower is better.
Simplicity criterion: All else being equal, simpler is better. A small improvement that adds ugly complexity is not worth it. Removing something for equal or better results is a win. Weigh complexity cost against improvement magnitude.
LOOP FOREVER:
results.tsv.train.py.git commit the change.uv run train.py > run.log 2>&1 (redirect everything — do NOT let output flood your context).grep "^val_bpb:\|^peak_vram_mb:" run.logtail -n 50 run.log to diagnose. Attempt a fix if trivial; otherwise give up on this idea.results.tsv (do NOT commit this file).val_bpb improved (lower): keep the commit, advance the branch.val_bpb is equal or worse: git reset --hard HEAD~1 to revert.Log every experiment to results.tsv (tab-separated):
commit val_bpb memory_gb status description
a1b2c3d 0.997900 44.0 keep baseline
b2c3d4e 0.993200 44.2 keep increase LR to 0.04
c3d4e5f 1.005000 44.0 discard switch to GeLU activation
d4e5f6g 0.000000 0.0 crash double model width (OOM)
keep, discard, or crashtrain.py as-is first.