Autoresearch for Skills

Most skills work about 70% of the time. The other 30% you get garbage. The fix isn't to rewrite the skill from scratch. It's to let an agent run it dozens of times, score every output, and tighten the prompt until that 30% disappears.

This skill adapts Andrej Karpathy's autoresearch methodology (autonomous experimentation loops) to Claude Code skills. Instead of optimizing ML training code, we optimize skill prompts.

the core job

Take any existing skill, define what "good output" looks like as binary yes/no checks, then run an autonomous loop that:

1. Generates outputs from the skill using test inputs
2. Scores every output against the eval criteria
3. Mutates the skill prompt to fix failures
4. Keeps mutations that improve the score, discards the rest
5. Repeats until the score ceiling is hit or the user stops it

Output: An improved SKILL.md + results.tsv log + changelog.md of every mutation attempted + a live HTML dashboard you can watch in your browser.

before starting: gather context

STOP. Do not run any experiments until all fields below are confirmed with the user. Ask for any missing fields before proceeding.

1. Target skill — Which skill do you want to optimize? (need the exact path to SKILL.md)
2. Test inputs — What 3-5 different prompts/scenarios should we test the skill with? (variety matters — pick inputs that cover different use cases so we don't overfit to one scenario)
3. Eval criteria — What 3-6 binary yes/no checks define a good output? (these are your "test questions" — see references/eval-guide.md for how to write good evals)
4. Runs per experiment — How many times should we run the skill per mutation? Default: 5. (more runs = more reliable scores, but slower and more expensive. 5 is the sweet spot for most skills.)
5. Run interval — How often should experiments cycle? Default: every 2 minutes. (shorter = faster iteration, but costs more)
6. Budget cap — Optional. Max number of experiment cycles before stopping. Default: no cap (runs until you stop it).

step 1: read the skill

Before changing anything, read and understand the target skill completely.

1. Read the full SKILL.md file
2. Read any files in references/ that the skill links to
3. Identify the skill's core job, process steps, and output format
4. Note any existing quality checks or anti-patterns already in the skill

Do NOT skip this. You need to understand what the skill does before you can improve it.

step 2: build the eval suite

Convert the user's eval criteria into a structured test. Every check must be binary — pass or fail, no scales.

Format each eval as:

EVAL [number]: [Short name]
Question: [Yes/no question about the output]
Pass condition: [What "yes" looks like — be specific]
Fail condition: [What triggers a "no"]

Rules for good evals:

• Binary only. Yes or no. No "rate 1-7" scales. Scales compound variability and give unreliable results.
• Specific enough to be consistent. "Is the text readable?" is too vague. "Are all words spelled correctly with no truncated sentences?" is testable.
• Not so narrow that the skill games the eval. "Contains fewer than 200 words" will make the skill optimize for brevity at the expense of everything else.
• 3-6 evals is the sweet spot. More than that and the skill starts parroting eval criteria back instead of actually improving.

See references/eval-guide.md for detailed examples of good vs bad evals.

Max score calculation:

max_score = [number of evals] × [runs per experiment]

Example: 4 evals × 5 runs = max score of 20.

step 3: generate the live dashboard

Before running any experiments, create a live HTML dashboard at autoresearch-[skill-name]/dashboard.html and open it in the browser.

The dashboard must:

• Auto-refresh every 10 seconds (reads from results.tsv)
• Show a score progression line chart (experiment number on X axis, pass rate % on Y axis)
• Show a colored bar for each experiment: green = keep, red = discard, blue = baseline
• Show a table of all experiments with: experiment #, score, pass rate, status, description
• Show per-eval breakdown: which evals pass most/least across all runs
• Show current status: "Running experiment [N]..." or "Idle"
• Use clean styling with soft colors (white background, pastel accents, clean sans-serif font)

Generate the dashboard as a single self-contained HTML file with inline CSS and JavaScript. Use Chart.js loaded from CDN for the line chart. The JS should fetch results.json (which you update after each experiment alongside results.tsv) and re-render.

Open it immediately after creating it: open dashboard.html (macOS) so the user can see it in their browser.

Update results.json after every experiment so the dashboard stays current. The JSON format:

{
  "skill_name": "[name]",
  "status": "running",
  "current_experiment": 3,
  "baseline_score": 70.0,
  "best_score": 90.0,
  "experiments": [
    {
      "id": 0,
      "score": 14,
      "max_score": 20,
      "pass_rate": 70.0,
      "status": "baseline",
      "description": "original skill — no changes"
    }
  ],
  "eval_breakdown": [
    {"name": "Text legibility", "pass_count": 8, "total": 10},
    {"name": "Pastel colors", "pass_count": 9, "total": 10}
  ]
}

When the run finishes (user stops it or ceiling hit), update status to "complete" so the dashboard shows a "Done" state with final summary.

step 4: establish baseline

Run the skill AS-IS before changing anything. This is experiment #0.

1. Ask the user what to name the new version. Example: "What should I call the optimized version? (e.g., anti-slop-v2, anti-slop-optimized)" The user picks the name.
2. Create a working directory: autoresearch-[skill-name]/ inside the skill's folder
3. Copy the original SKILL.md into the working directory as [user-chosen-name].md — this is the copy you will mutate. NEVER edit the original SKILL.md. All mutations happen on this copy only.
4. Also save SKILL.md.baseline in the working directory (identical to the original — this is your revert target)
5. Create results.tsv with the header row
6. Create results.json and dashboard.html, then open the dashboard in the browser
7. Run the skill [N] times using the test inputs (use [user-chosen-name].md for all runs)
8. Score every output against every eval
9. Record the baseline score and update both results.tsv and results.json

results.tsv format (tab-separated):

experiment	score	max_score	pass_rate	status	description
0	14	20	70.0%	baseline	original skill — no changes

IMPORTANT: After establishing baseline, confirm the score with the user before proceeding. If baseline is already 90%+, the skill may not need optimization — ask the user if they want to continue.

step 5: run the experiment loop

This is the core autoresearch loop. Once started, run autonomously until stopped.

LOOP:

1. Analyze failures. Look at which evals are failing most. Read the actual outputs that failed. Identify the pattern — is it a formatting issue? A missing instruction? An ambiguous directive?

2. Form a hypothesis. Pick ONE thing to change. Don't change 5 things at once — you won't know what helped.

   Good mutations:

   • Add a specific instruction that addresses the most common failure
   • Reword an ambiguous instruction to be more explicit
   • Add an anti-pattern ("Do NOT do X") for a recurring mistake
   • Move a buried instruction higher in the skill (priority = position)
   • Add or improve an example that shows the correct behavior
   • Remove an instruction that's causing the skill to over-optimize for one thing at the expense of others

   Bad mutations:

   • Rewriting the entire skill from scratch
   • Adding 10 new rules at once
   • Making the skill longer without a specific reason
   • Adding vag