Autoresearch agent

Autonomous experiment loop that optimizes any file by a measurable metric.

How to use it

Claude Code
  1. Run the line below. It pulls the whole folder into ~/.claude/skills/autoresearch-agent, including the files SKILL.md points to.
  2. Describe your job in plain words. Claude Code follows the skill from there.
Claude Code — installs the whole folder, not just SKILL.md
npx degit alirezarezvani/claude-skills/engineering/autoresearch-agent/skills/autoresearch-agent#main ~/.claude/skills/autoresearch-agent

For one project only, change the path to .claude/skills/autoresearch-agent. This skill also uses bench.py, evaluate.py, config.yaml, program.md, results.md, dashboard.md — copying SKILL.md alone won't be enough. See the folder on GitHub.

Claude (web or desktop app)
  1. On this page open ⋯ → Download .md.
  2. Save it as SKILL.md in a folder, zip the folder, then Customize → Skills → + → Create skill → Upload a skill.
  3. Pick the file and Save. Claude shows the name and description and runs a security scan.
  4. Check the skill is switched on.
  5. Start a new chat and describe your job in plain words. The AI follows the skill from there.
ChatGPT or another app
  1. ChatGPT: make a Project and paste it into Instructions.
  2. Neither? Paste it at the top of a new chat — it works for that chat.
Not working?
  • Check which app you pasted it into — the steps above name the right one.
  • Some skills need the paid tier of Claude or ChatGPT.
Step-by-step guide with screenshots · Ask in the forum

Paste into Claude, ChatGPT or Cursor.

Source of Autoresearch agent

Show the full text309 lines
namedescriptionlicensemetadata
autoresearch-agentAutonomous experiment loop that optimizes any file by a measurable metric. Inspired by Karpathy's autoresearch. The agent edits a target file, runs a fixed evaluation, keeps improvements (git commit), discards failures (git reset), and loops indefinitely. Use when: user wants to optimize code speed, reduce bundle/image size, improve test pass rate, optimize prompts, improve content quality (headlines, copy, CTR), or run any measurable improvement loop. Requires: a target file, an evaluation command that outputs a metric, and a git repo.MIT version: 2.0.0 author: Alireza Rezvani category: engineering updated: 2026-03-13

Autoresearch Agent

You sleep. The agent experiments. You wake up to results.

Autonomous experiment loop inspired by Karpathy's autoresearch. The agent edits one file, runs a fixed evaluation, keeps improvements, discards failures, and loops indefinitely.

Not one guess — fifty measured attempts, compounding.


Slash Commands

Command What it does
/ar:setup Set up a new experiment interactively
/ar:run Run a single experiment iteration
/ar:loop Start autonomous loop with configurable interval (10m, 1h, daily, weekly, monthly)
/ar:ar-status Show dashboard and results
/ar:ar-resume Resume a paused experiment

When This Skill Activates

Recognize these patterns from the user:

  • "Make this faster / smaller / better"
  • "Optimize [file] for [metric]"
  • "Improve my [headlines / copy / prompts]"
  • "Run experiments overnight"
  • "I want to get [metric] from X to Y"
  • Any request involving: optimize, benchmark, improve, experiment loop, autoresearch

If the user describes a target file + a way to measure success → this skill applies.


Setup

First Time — Create the Experiment

Run the setup script. The user decides where experiments live:

Project-level (inside repo, git-tracked, shareable with team):

python scripts/setup_experiment.py \
  --domain engineering \
  --name api-speed \
  --target src/api/search.py \
  --eval "pytest bench.py --tb=no -q" \
  --metric p50_ms \
  --direction lower \
  --scope project

User-level (personal, in ~/.autoresearch/):

python scripts/setup_experiment.py \
  --domain marketing \
  --name medium-ctr \
  --target content/titles.md \
  --eval "python evaluate.py" \
  --metric ctr_score \
  --direction higher \
  --evaluator llm_judge_content \
  --scope user

The --scope flag determines where .autoresearch/ lives:

  • project (default) → .autoresearch/ in the repo root. Experiment definitions are git-tracked. Results are gitignored.
  • user → ~/.autoresearch/ in the home directory. Everything is personal.
What Setup Creates
.autoresearch/
├── config.yaml                        ← Global settings
├── .gitignore                         ← Ignores results.tsv, *.log
└── {domain}/{experiment-name}/
    ├── program.md                     ← Objectives, constraints, strategy
    ├── config.cfg                     ← Target, eval cmd, metric, direction
    ├── results.tsv                    ← Experiment log (gitignored)
    └── evaluate.py                    ← Evaluation script (if --evaluator used)

results.tsv columns: commit | metric | status | description

  • commit — short git hash
  • metric — float value or "N/A" for crashes
  • status — keep | discard | crash
  • description — what changed or why it crashed
Domains
Domain Use Cases
engineering Code speed, memory, bundle size, test pass rate, build time
marketing Headlines, social copy, email subjects, ad copy, engagement
content Article structure, SEO descriptions, readability, CTR
prompts System prompts, chatbot tone, agent instructions
custom Anything else with a measurable metric
If program.md Already Exists

The user may have written their own program.md. If found in the experiment directory, read it. It overrides the template. Only ask for what's missing.


Agent Protocol

You are the loop. The scripts handle setup and evaluation — you handle the creative work.

Before Starting
  1. Read .autoresearch/{domain}/{name}/config.cfg to get:
    • target — the file you edit
    • evaluate_cmd — the command that measures your changes
    • metric — the metric name to look for in eval output
    • metric_direction — "lower" or "higher" is better
    • time_budget_minutes — max time per evaluation
  2. Read program.md for strategy, constraints, and what you can/cannot change
  3. Read results.tsv for experiment history (columns: commit, metric, status, description)
  4. Checkout the experiment branch: git checkout autoresearch/{domain}/{name}
Each Iteration
  1. Review results.tsv — what worked? What failed? What hasn't been tried?
  2. Decide ONE change to the target file. One variable per experiment.
  3. Edit the target file
  4. Commit: git add {target} && git commit -m "experiment: {description}"
  5. Evaluate: python scripts/run_experiment.py --experiment {domain}/{name} --single
  6. Read the output — it prints KEEP, DISCARD, or CRASH with the metric value
  7. Go to step 1
What the Script Handles (you don't)
  • Running the eval command with timeout
  • Parsing the metric from eval output
  • Comparing to previous best
  • Reverting the commit on failure (git reset --hard HEAD~1)
  • Logging the result to results.tsv
Starting an Experiment
# Single iteration (the agent calls this repeatedly)
python scripts/run_experiment.py --experiment engineering/api-speed --single

# Dry run (test setup before starting)
python scripts/run_experiment.py --experiment engineering/api-speed --dry-run
Strategy Escalation
  • Runs 1-5: Low-hanging fruit (obvious improvements, simple optimizations)
  • Runs 6-15: Systematic exploration (vary one parameter at a time)
  • Runs 16-30: Structural changes (algorithm swaps, architecture shifts)
  • Runs 30+: Radical experiments (completely different approaches)
  • If no improvement in 20+ runs: update program.md Strategy section
Self-Improvement

After every 10 experiments, review results.tsv for patterns. Update the Strategy section of program.md with what you learned (e.g., "caching changes consistently improve by 5-10%", "refactoring attempts never improve the metric"). Future iterations benefit from this accumulated knowledge.

Stopping
  • Run until interrupted by the user, context limit reached, or goal in program.md is met
  • Before stopping: ensure results.tsv is up to date
  • On context limit: the next session can resume — results.tsv and git log persist
Rules
  • One change per experiment. Don't change 5 things at once. You won't know what worked.
  • Simplicity criterion. A small improvement that adds ugly complexity is not worth it. Equal performance with simpler code is a win. Removing code that gets same results is the best outcome.
  • Never modify the evaluator. evaluate.py is the ground truth. Modifying it invalidates all comparisons. Hard stop if you catch yourself doing this.
  • Timeout. If a run exceeds 2.5× the time budget, kill it and treat as crash.
  • Crash handling. If it's a typo or missing import, fix and re-run. If the idea is fundamentally broken, revert, log "crash", move on. 5 consecutive crashes → pause and alert.
  • No new dependencies. Only use what's already available in the project.

Evaluators

Ready-to-use evaluation scripts. Copied into the experiment directory during setup with --evaluator.

Free Evaluators (no API cost)
Evaluator Metric Use Case
benchmark_speed p50_ms (lower) Function/API execution time
benchmark_size size_bytes (lower) File, bundle, Docker image size
test_pass_rate pass_rate (higher) Test suite pass percentage
build_speed build_seconds (lower) Build/compile/Docker build time
memory_usage peak_mb (lower) Peak memory during execution
LLM Judge Evaluators (uses your subscription)
Evaluator Metric Use Case
llm_judge_content ctr_score 0-10 (higher) Headlines, titles, descriptions
llm_judge_prompt quality_score 0-100 (higher) System prompts, agent instructions
llm_judge_copy engagement_score 0-10 (higher) Social posts, ad copy, emails

LLM judges call the CLI tool the user is already running (Claude, Codex, Gemini). The evaluation prompt is locked inside evaluate.py — the agent cannot modify it. This prevents the agent from gaming its own evaluator.

The user's existing subscription covers the cost:

  • Claude Code Max → unlimited Claude calls for evaluation
  • Codex CLI (ChatGPT Pro) → unlimited Codex calls
  • Gemini CLI (free tier) → free evaluation calls
Custom Evaluators

If no built-in evaluator fits, the user writes their own evaluate.py. Only requirement: it must print metric_name: value to stdout.

#!/usr/bin/env python3
# My custom evaluator — DO NOT MODIFY after experiment starts
import subprocess
result = subprocess.run(["my-benchmark", "--json"], capture_output=True, text=True)
# Parse and output
print(f"my_metric: {parse_score(result.stdout)}")

Viewing Results

# Single experiment
python scripts/log_results.py --experiment engineering/api-speed

# All experiments in a domain
python scripts/log_results.py --domain engineering

# Cross-experiment dashboard
python scripts/log_results.py --dashboard

# Export formats
python scripts/log_results.py --experiment engineering/api-speed --format csv --output results.csv
python scripts/log_results.py --experiment engineering/api-speed --format markdown --output results.md
python scripts/log_results.py --dashboard --format markdown --output dashboard.md
Dashboard Output
DOMAIN          EXPERIMENT          RUNS  KEPT  BEST         Δ FROM START  STATUS
engineering     api-speed            47    14   185ms        -76.9%        active
engineering     bundle-size          23     8   412KB        -58.3%        paused
marketing       medium-ctr           31    11   8.4/10       +68.0%        active
prompts         support-tone         15     6   82/100       +46.4%        done
Export Formats
  • TSV — default, tab-separated (compatible with spreadsheets)
  • CSV — comma-separated, with proper quoting
  • Markdown — formatted table, readable in GitHub/docs

Proactive Triggers

Flag these without being asked:

  • No evaluation command works → Test it before starting the loop. Run once, verify output.
  • Target file not in git → git init && git add . && git commit -m 'initial' first.
  • Metric direction unclear → Ask: is lower or higher better? Must know before starting.
  • Time budget too short → If eval takes longer than budget, every run crashes.
  • Agent modifying evaluate.py → Hard stop. This invalidates all comparisons.
  • 5 consecutive crashes → Pause the loop. Alert the user. Don't keep burning cycles.
  • No improvement in 20+ runs → Suggest changing strategy in program.md or trying a different approach.

Installation

One-liner (any tool)
git clone https://github.com/alirezarezvani/claude-skills.git
cp -r claude-skills/engineering/autoresearch-agent ~/.claude/skills/
Multi-tool install
./scripts/convert.sh --skill autoresearch-agent --tool codex|gemini|cursor|windsurf|openclaw
OpenClaw
clawhub install cs-autoresearch-agent

  • self-improving-agent — improves an agent's own memory/rules over time. NOT for structured experiment loops.
  • senior-ml-engineer — ML architecture decisions. Complementary — use for initial design, then autoresearch for optimization.
  • tdd-guide — test-driven development. Complementary — tests can be the evaluation function.
  • skill-security-auditor — audit skills before publishing. NOT for optimization loops.
1---
2name: "autoresearch-agent"
3description: "Autonomous experiment loop that optimizes any file by a measurable metric. Inspired by Karpathy's autoresearch. The agent edits a target file, runs a fixed evaluation, keeps improvements (git commit), discards failures (git reset), and loops indefinitely. Use when: user wants to optimize code speed, reduce bundle/image size, improve test pass rate, optimize prompts, improve content quality (headlines, copy, CTR), or run any measurable improvement loop. Requires: a target file, an evaluation command that outputs a metric, and a git repo."
4license: MIT
5metadata:
6 version: 2.0.0
7 author: Alireza Rezvani
8 category: engineering
9 updated: 2026-03-13
10---
11 
12# Autoresearch Agent
13 
14> You sleep. The agent experiments. You wake up to results.
15 
16Autonomous experiment loop inspired by [Karpathy's autoresearch](https://github.com/karpathy/autoresearch). The agent edits one file, runs a fixed evaluation, keeps improvements, discards failures, and loops indefinitely.
17 
18Not one guess — fifty measured attempts, compounding.
19 
20---
21 
22## Slash Commands
23 
24| Command | What it does |
25|---------|-------------|
26| `/ar:setup` | Set up a new experiment interactively |
27| `/ar:run` | Run a single experiment iteration |
28| `/ar:loop` | Start autonomous loop with configurable interval (10m, 1h, daily, weekly, monthly) |
29| `/ar:ar-status` | Show dashboard and results |
30| `/ar:ar-resume` | Resume a paused experiment |
31 
32---
33 
34## When This Skill Activates
35 
36Recognize these patterns from the user:
37 
38- "Make this faster / smaller / better"
39- "Optimize [file] for [metric]"
40- "Improve my [headlines / copy / prompts]"
41- "Run experiments overnight"
42- "I want to get [metric] from X to Y"
43- Any request involving: optimize, benchmark, improve, experiment loop, autoresearch
44 
45If the user describes a target file + a way to measure success → this skill applies.
46 
47---
48 
49## Setup
50 
51### First Time — Create the Experiment
52 
53Run the setup script. The user decides where experiments live:
54 
55**Project-level** (inside repo, git-tracked, shareable with team):
56```bash
57python scripts/setup_experiment.py \
58 --domain engineering \
59 --name api-speed \
60 --target src/api/search.py \
61 --eval "pytest bench.py --tb=no -q" \
62 --metric p50_ms \
63 --direction lower \
64 --scope project
65```
66 
67**User-level** (personal, in `~/.autoresearch/`):
68```bash
69python scripts/setup_experiment.py \
70 --domain marketing \
71 --name medium-ctr \
72 --target content/titles.md \
73 --eval "python evaluate.py" \
74 --metric ctr_score \
75 --direction higher \
76 --evaluator llm_judge_content \
77 --scope user
78```
79 
80The `--scope` flag determines where `.autoresearch/` lives:
81- `project` (default) → `.autoresearch/` in the repo root. Experiment definitions are git-tracked. Results are gitignored.
82- `user` → `~/.autoresearch/` in the home directory. Everything is personal.
83 
84### What Setup Creates
85 
86```
87.autoresearch/
88├── config.yaml ← Global settings
89├── .gitignore ← Ignores results.tsv, *.log
90└── {domain}/{experiment-name}/
91 ├── program.md ← Objectives, constraints, strategy
92 ├── config.cfg ← Target, eval cmd, metric, direction
93 ├── results.tsv ← Experiment log (gitignored)
94 └── evaluate.py ← Evaluation script (if --evaluator used)
95```
96 
97**results.tsv columns:** `commit | metric | status | description`
98- `commit` — short git hash
99- `metric` — float value or "N/A" for crashes
100- `status` — keep | discard | crash
101- `description` — what changed or why it crashed
102 
103### Domains
104 
105| Domain | Use Cases |
106|--------|-----------|
107| `engineering` | Code speed, memory, bundle size, test pass rate, build time |
108| `marketing` | Headlines, social copy, email subjects, ad copy, engagement |
109| `content` | Article structure, SEO descriptions, readability, CTR |
110| `prompts` | System prompts, chatbot tone, agent instructions |
111| `custom` | Anything else with a measurable metric |
112 
113### If `program.md` Already Exists
114 
115The user may have written their own `program.md`. If found in the experiment directory, read it. It overrides the template. Only ask for what's missing.
116 
117---
118 
119## Agent Protocol
120 
121You are the loop. The scripts handle setup and evaluation — you handle the creative work.
122 
123### Before Starting
1241. Read `.autoresearch/{domain}/{name}/config.cfg` to get:
125 - `target` — the file you edit
126 - `evaluate_cmd` — the command that measures your changes
127 - `metric` — the metric name to look for in eval output
128 - `metric_direction` — "lower" or "higher" is better
129 - `time_budget_minutes` — max time per evaluation
1302. Read `program.md` for strategy, constraints, and what you can/cannot change
1313. Read `results.tsv` for experiment history (columns: commit, metric, status, description)
1324. Checkout the experiment branch: `git checkout autoresearch/{domain}/{name}`
133 
134### Each Iteration
1351. Review results.tsv — what worked? What failed? What hasn't been tried?
1362. Decide ONE change to the target file. One variable per experiment.
1373. Edit the target file
1384. Commit: `git add {target} && git commit -m "experiment: {description}"`
1395. Evaluate: `python scripts/run_experiment.py --experiment {domain}/{name} --single`
1406. Read the output — it prints KEEP, DISCARD, or CRASH with the metric value
1417. Go to step 1
142 
143### What the Script Handles (you don't)
144- Running the eval command with timeout
145- Parsing the metric from eval output
146- Comparing to previous best
147- Reverting the commit on failure (`git reset --hard HEAD~1`)
148- Logging the result to results.tsv
149 
150### Starting an Experiment
151 
152```bash
153# Single iteration (the agent calls this repeatedly)
154python scripts/run_experiment.py --experiment engineering/api-speed --single
155 
156# Dry run (test setup before starting)
157python scripts/run_experiment.py --experiment engineering/api-speed --dry-run
158```
159 
160### Strategy Escalation
161- Runs 1-5: Low-hanging fruit (obvious improvements, simple optimizations)
162- Runs 6-15: Systematic exploration (vary one parameter at a time)
163- Runs 16-30: Structural changes (algorithm swaps, architecture shifts)
164- Runs 30+: Radical experiments (completely different approaches)
165- If no improvement in 20+ runs: update program.md Strategy section
166 
167### Self-Improvement
168After every 10 experiments, review results.tsv for patterns. Update the
169Strategy section of program.md with what you learned (e.g., "caching changes
170consistently improve by 5-10%", "refactoring attempts never improve the metric").
171Future iterations benefit from this accumulated knowledge.
172 
173### Stopping
174- Run until interrupted by the user, context limit reached, or goal in program.md is met
175- Before stopping: ensure results.tsv is up to date
176- On context limit: the next session can resume — results.tsv and git log persist
177 
178### Rules
179 
180- **One change per experiment.** Don't change 5 things at once. You won't know what worked.
181- **Simplicity criterion.** A small improvement that adds ugly complexity is not worth it. Equal performance with simpler code is a win. Removing code that gets same results is the best outcome.
182- **Never modify the evaluator.** `evaluate.py` is the ground truth. Modifying it invalidates all comparisons. Hard stop if you catch yourself doing this.
183- **Timeout.** If a run exceeds 2.5× the time budget, kill it and treat as crash.
184- **Crash handling.** If it's a typo or missing import, fix and re-run. If the idea is fundamentally broken, revert, log "crash", move on. 5 consecutive crashes → pause and alert.
185- **No new dependencies.** Only use what's already available in the project.
186 
187---
188 
189## Evaluators
190 
191Ready-to-use evaluation scripts. Copied into the experiment directory during setup with `--evaluator`.
192 
193### Free Evaluators (no API cost)
194 
195| Evaluator | Metric | Use Case |
196|-----------|--------|----------|
197| `benchmark_speed` | `p50_ms` (lower) | Function/API execution time |
198| `benchmark_size` | `size_bytes` (lower) | File, bundle, Docker image size |
199| `test_pass_rate` | `pass_rate` (higher) | Test suite pass percentage |
200| `build_speed` | `build_seconds` (lower) | Build/compile/Docker build time |
201| `memory_usage` | `peak_mb` (lower) | Peak memory during execution |
202 
203### LLM Judge Evaluators (uses your subscription)
204 
205| Evaluator | Metric | Use Case |
206|-----------|--------|----------|
207| `llm_judge_content` | `ctr_score` 0-10 (higher) | Headlines, titles, descriptions |
208| `llm_judge_prompt` | `quality_score` 0-100 (higher) | System prompts, agent instructions |
209| `llm_judge_copy` | `engagement_score` 0-10 (higher) | Social posts, ad copy, emails |
210 
211LLM judges call the CLI tool the user is already running (Claude, Codex, Gemini). The evaluation prompt is locked inside `evaluate.py` — the agent cannot modify it. This prevents the agent from gaming its own evaluator.
212 
213The user's existing subscription covers the cost:
214- Claude Code Max → unlimited Claude calls for evaluation
215- Codex CLI (ChatGPT Pro) → unlimited Codex calls
216- Gemini CLI (free tier) → free evaluation calls
217 
218### Custom Evaluators
219 
220If no built-in evaluator fits, the user writes their own `evaluate.py`. Only requirement: it must print `metric_name: value` to stdout.
221 
222```python
223#!/usr/bin/env python3
224# My custom evaluator — DO NOT MODIFY after experiment starts
225import subprocess
226result = subprocess.run(["my-benchmark", "--json"], capture_output=True, text=True)
227# Parse and output
228print(f"my_metric: {parse_score(result.stdout)}")
229```
230 
231---
232 
233## Viewing Results
234 
235```bash
236# Single experiment
237python scripts/log_results.py --experiment engineering/api-speed
238 
239# All experiments in a domain
240python scripts/log_results.py --domain engineering
241 
242# Cross-experiment dashboard
243python scripts/log_results.py --dashboard
244 
245# Export formats
246python scripts/log_results.py --experiment engineering/api-speed --format csv --output results.csv
247python scripts/log_results.py --experiment engineering/api-speed --format markdown --output results.md
248python scripts/log_results.py --dashboard --format markdown --output dashboard.md
249```
250 
251### Dashboard Output
252 
253```
254DOMAIN EXPERIMENT RUNS KEPT BEST Δ FROM START STATUS
255engineering api-speed 47 14 185ms -76.9% active
256engineering bundle-size 23 8 412KB -58.3% paused
257marketing medium-ctr 31 11 8.4/10 +68.0% active
258prompts support-tone 15 6 82/100 +46.4% done
259```
260 
261### Export Formats
262 
263- **TSV** — default, tab-separated (compatible with spreadsheets)
264- **CSV** — comma-separated, with proper quoting
265- **Markdown** — formatted table, readable in GitHub/docs
266 
267---
268 
269## Proactive Triggers
270 
271Flag these without being asked:
272 
273- **No evaluation command works** → Test it before starting the loop. Run once, verify output.
274- **Target file not in git** → `git init && git add . && git commit -m 'initial'` first.
275- **Metric direction unclear** → Ask: is lower or higher better? Must know before starting.
276- **Time budget too short** → If eval takes longer than budget, every run crashes.
277- **Agent modifying evaluate.py** → Hard stop. This invalidates all comparisons.
278- **5 consecutive crashes** → Pause the loop. Alert the user. Don't keep burning cycles.
279- **No improvement in 20+ runs** → Suggest changing strategy in program.md or trying a different approach.
280 
281---
282 
283## Installation
284 
285### One-liner (any tool)
286```bash
287git clone https://github.com/alirezarezvani/claude-skills.git
288cp -r claude-skills/engineering/autoresearch-agent ~/.claude/skills/
289```
290 
291### Multi-tool install
292```bash
293./scripts/convert.sh --skill autoresearch-agent --tool codex|gemini|cursor|windsurf|openclaw
294```
295 
296### OpenClaw
297```bash
298clawhub install cs-autoresearch-agent
299```
300 
301---
302 
303## Related Skills
304 
305- **self-improving-agent** — improves an agent's own memory/rules over time. NOT for structured experiment loops.
306- **senior-ml-engineer** — ML architecture decisions. Complementary — use for initial design, then autoresearch for optimization.
307- **tdd-guide** — test-driven development. Complementary — tests can be the evaluation function.
308- **skill-security-auditor** — audit skills before publishing. NOT for optimization loops.
309 

Discussion

Alternatives

Also in CI/CD & releasesSee all 533 in Development →