/ar:run — Single Experiment Iteration
Run a single experiment iteration.
How to use it
Claude Code
- Run the line below. It pulls the whole folder into
~/.claude/skills/run-2, including the files SKILL.md points to. - 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/run#main ~/.claude/skills/run-2For one project only, change the path to .claude/skills/run-2. This skill also uses program.md, evaluate.py — copying SKILL.md alone won't be enough. See the folder on GitHub.
Claude (web or desktop app)
- On this page open ⋯ → Download .md.
- Save it as SKILL.md in a folder, zip the folder, then Customize → Skills → + → Create skill → Upload a skill.
- Pick the file and Save. Claude shows the name and description and runs a security scan.
- Check the skill is switched on.
- Start a new chat and describe your job in plain words. The AI follows the skill from there.
ChatGPT or another app
- ChatGPT: make a Project and paste it into Instructions.
- 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.
Paste into Claude, ChatGPT or Cursor.
Source of /ar:run — Single Experiment Iteration
Show the full text85 lines
| name | description | command |
|---|---|---|
| run | Run a single experiment iteration. Edit the target file, evaluate, keep or discard. Use when the user runs /ar:run or asks for one manual autoresearch iteration. | /ar:run |
/ar:run — Single Experiment Iteration
Run exactly ONE experiment iteration: review history, decide a change, edit, commit, evaluate.
Usage
/ar:run engineering/api-speed # Run one iteration
/ar:run # List experiments, let user pick
What It Does
Step 1: Resolve experiment
If no experiment specified, run python {skill_path}/scripts/setup_experiment.py --list and ask the user to pick.
Step 2: Load context
# Read experiment config
cat .autoresearch/{domain}/{name}/config.cfg
# Read strategy and constraints
cat .autoresearch/{domain}/{name}/program.md
# Read experiment history
cat .autoresearch/{domain}/{name}/results.tsv
# Checkout the experiment branch
git checkout autoresearch/{domain}/{name}
Step 3: Decide what to try
Review results.tsv:
- What changes were kept? What pattern do they share?
- What was discarded? Avoid repeating those approaches.
- What crashed? Understand why.
- How many runs so far? (Escalate strategy accordingly)
Strategy escalation:
- Runs 1-5: Low-hanging fruit (obvious improvements)
- Runs 6-15: Systematic exploration (vary one parameter)
- Runs 16-30: Structural changes (algorithm swaps)
- Runs 30+: Radical experiments (completely different approaches)
Step 4: Make ONE change
Edit only the target file specified in config.cfg. Change one thing. Keep it simple.
Step 5: Commit and evaluate
git add {target}
git commit -m "experiment: {short description of what changed}"
python {skill_path}/scripts/run_experiment.py \
--experiment {domain}/{name} --single
Step 6: Report result
Read the script output. Tell the user:
- KEEP: "Improvement! {metric}: {value} ({delta} from previous best)"
- DISCARD: "No improvement. {metric}: {value} vs best {best}. Reverted."
- CRASH: "Evaluation failed: {reason}. Reverted."
Step 7: Self-improvement check
After every 10th experiment (check results.tsv line count), update the Strategy section of program.md with patterns learned.
Rules
- ONE change per iteration. Don't change 5 things at once.
- NEVER modify the evaluator (evaluate.py). It's ground truth.
- Simplicity wins. Equal performance with simpler code is an improvement.
- No new dependencies.
| 1 | |
| 2 | name "run" |
| 3 | description "Run a single experiment iteration. Edit the target file, evaluate, keep or discard. Use when the user runs /ar:run or asks for one manual autoresearch iteration." |
| 4 | command /ar:run |
| 5 | |
| 6 | |
| 7 | # /ar:run — Single Experiment Iteration |
| 8 | |
| 9 | Run exactly ONE experiment iteration: review history, decide a change, edit, commit, evaluate. |
| 10 | |
| 11 | ## Usage |
| 12 | |
| 13 | |
| 14 | /ar:run engineering/api-speed # Run one iteration |
| 15 | /ar:run # List experiments, let user pick |
| 16 | |
| 17 | |
| 18 | ## What It Does |
| 19 | |
| 20 | ### Step 1: Resolve experiment |
| 21 | |
| 22 | If no experiment specified, run `python {skill_path}/scripts/setup_experiment.py --list` and ask the user to pick. |
| 23 | |
| 24 | ### Step 2: Load context |
| 25 | |
| 26 | |
| 27 | # Read experiment config |
| 28 | cat .autoresearch/{domain}/{name}/config.cfg |
| 29 | |
| 30 | # Read strategy and constraints |
| 31 | cat .autoresearch/{domain}/{name}/program.md |
| 32 | |
| 33 | # Read experiment history |
| 34 | cat .autoresearch/{domain}/{name}/results.tsv |
| 35 | |
| 36 | # Checkout the experiment branch |
| 37 | git checkout autoresearch/{domain}/{name} |
| 38 | |
| 39 | |
| 40 | ### Step 3: Decide what to try |
| 41 | |
| 42 | Review results.tsv: |
| 43 | What changes were kept? What pattern do they share? |
| 44 | What was discarded? Avoid repeating those approaches. |
| 45 | What crashed? Understand why. |
| 46 | How many runs so far? (Escalate strategy accordingly) |
| 47 | |
| 48 | **Strategy escalation:** |
| 49 | Runs 1-5: Low-hanging fruit (obvious improvements) |
| 50 | Runs 6-15: Systematic exploration (vary one parameter) |
| 51 | Runs 16-30: Structural changes (algorithm swaps) |
| 52 | Runs 30+: Radical experiments (completely different approaches) |
| 53 | |
| 54 | ### Step 4: Make ONE change |
| 55 | |
| 56 | Edit only the target file specified in config.cfg. Change one thing. Keep it simple. |
| 57 | |
| 58 | ### Step 5: Commit and evaluate |
| 59 | |
| 60 | |
| 61 | git add {target} |
| 62 | git commit -m "experiment: {short description of what changed}" |
| 63 | |
| 64 | python {skill_path}/scripts/run_experiment.py \ |
| 65 | --experiment {domain}/{name} --single |
| 66 | |
| 67 | |
| 68 | ### Step 6: Report result |
| 69 | |
| 70 | Read the script output. Tell the user: |
| 71 | **KEEP**: "Improvement! {metric}: {value} ({delta} from previous best)" |
| 72 | **DISCARD**: "No improvement. {metric}: {value} vs best {best}. Reverted." |
| 73 | **CRASH**: "Evaluation failed: {reason}. Reverted." |
| 74 | |
| 75 | ### Step 7: Self-improvement check |
| 76 | |
| 77 | After every 10th experiment (check results.tsv line count), update the Strategy section of program.md with patterns learned. |
| 78 | |
| 79 | ## Rules |
| 80 | |
| 81 | ONE change per iteration. Don't change 5 things at once. |
| 82 | NEVER modify the evaluator (evaluate.py). It's ground truth. |
| 83 | Simplicity wins. Equal performance with simpler code is an improvement. |
| 84 | No new dependencies. |
| 85 |
Discussion
Browse more free Claude skills.