Optimize skill

Autonomous optimization loop — hill-climb any target.

by danielmiessler·MIT license·★ 19,269 Stars on the repo·GitHub ↗

Use now

Files of Optimize

danielmiessler/main1 file shown
SKILL.md
Show the full text181 lines

/optimize — Autonomous Optimization v2

What It Does

Runs an autonomous optimization loop against any target. The agent modifies the target, measures the result, keeps improvements, discards failures, and repeats until it stops climbing. Two modes: metric mode for code targets that produce a number (latency, bundle size), and eval mode for skills, prompts, or agents judged by LLM-as-judge binary evals.

The Problem

Tuning a thing for a measurable outcome is slow, boring, manual work. You change a file, run the measurement, eyeball whether it got better, keep or revert, then do it again — dozens of times. People give up after a few rounds and settle for "good enough" far short of the real ceiling. The targets without a clean number (a skill's quality, a prompt's effectiveness) are worse: there's no easy way to tell if a change actually helped. This skill runs that whole loop for you and only keeps changes that measurably win.

How It Works

Two modes drive the same hill-climb loop:

  • Metric mode — code targets with a shell command that produces a number (the original).
  • Eval mode — skills, prompts, agents, or any text target judged by LLM-as-judge binary evals.

Inspired by Karpathy's autoresearch and extended with LLM-as-judge evaluation.

Invocation

Metric Mode (code targets)
/optimize --metric "lighthouse_score" --higher-is-better \
  --measure "npx lighthouse http://localhost:3000 --output=json" \
  --extract "jq '.categories.performance.score * 100' lighthouse.json" \
  --files "src/**/*.tsx,src/**/*.css" \
  --budget 120

/optimize --resume        # Resume a previous optimization loop
/optimize --status        # Show results summary from last/current run
Eval Mode (skill/prompt/agent targets)
/optimize --target "~/.claude/skills/ExtractWisdom"
/optimize --target "~/.claude/skills/Research/Workflows/QuickResearch.md"
/optimize --target "prompts/my-prompt.md"
/optimize --target "~/.claude/skills/ExtractWisdom" --max-experiments 20

In eval mode, the system automatically:

  1. Detects the target type (skill, prompt, agent, code, function)
  2. Reads the target to understand its purpose and constraints
  3. Generates 3-6 binary eval criteria and 3-5 test inputs
  4. Presents criteria + inputs for your approval before starting
  5. Runs the optimization loop using LLM-as-judge scoring
  6. Presents a recommendation (apply/reject/partial) when done

What Happens

This skill drives the LifeOS Algorithm as an autonomous mutation loop:

  1. OBSERVE — Define or auto-detect the target, set eval_mode
  2. THINK — Analyze codebase/skill, generate hypothesis queue
  3. PLAN — Prioritize hypotheses by expected impact
  4. BUILD — Phase 0: TARGET ANALYSIS (see optimize-loop.md)
    • Detect target type, auto-generate eval criteria (eval mode), set up sandbox, baseline
  5. EXECUTE — The autonomous loop (optimize-loop.md):
    • Hypothesize → Modify target → Measure (metric or eval) → Keep/Revert → Repeat
    • Metric mode: ~12 experiments/hour (at 5-min budget)
    • Eval mode: ~6-8 experiments/hour (multi-run judging is slower)
  6. VERIFY — Phase 9: RECOMMEND — diff, summary, apply/reject/partial options
  7. LEARN — Phase 10: EXTRACT LEARNINGS — what worked, what didn't, structured insights

Arguments — Metric Mode

Argument Required Default Description
--metric NAME yes Human-readable metric name
--measure COMMAND yes Shell command that produces the metric
--files GLOB yes Files the agent may modify (comma-separated)
--higher-is-better (default) Higher metric values are better
--lower-is-better Lower metric values are better
--extract COMMAND Last number in stdout Extract metric from output
--budget SECONDS 300 Time budget per experiment
--target VALUE none Stop when metric reaches this value
--max-experiments N none Stop after N experiments
--locked GLOB none Files the agent must NOT modify
--constraints TEXT none Additional rules (e.g., "tests must pass")

Arguments — Eval Mode

Argument Required Default Description
--target PATH yes Path to skill directory, prompt file, or agent definition
--max-experiments N none Stop after N experiments
--runs N 3 Runs per experiment (more = more reliable, slower)
--criteria "Q1" "Q2" auto-generated Override auto-generated eval criteria
--inputs "I1" "I2" auto-generated Override auto-generated test inputs
--budget SECONDS 300 Time budget per experiment

Shared Arguments

Argument Description
--resume Resume a previous optimization run
--status Show results summary

Algorithm Integration

When /optimize is invoked, the eval_mode is set based on arguments (mode: is retired — never write it to frontmatter):

  • --measure provided → eval_mode: metric (git branch sandbox)
  • --target provided → eval_mode: eval (directory sandbox)

ISC criteria become guard rails — assertions that must hold true across ALL experiments. Guard rails must REMAIN satisfied perpetually. A violation triggers automatic revert regardless of score improvement.

Reference files:

  • ~/.claude/LIFEOS/ALGORITHM/optimize-loop.md — the full loop protocol
  • ~/.claude/LIFEOS/ALGORITHM/eval-guide.md — how to write good eval criteria
  • ~/.claude/LIFEOS/ALGORITHM/archive/target-types.md — target detection and ISC generation

Examples

Metric Mode

Optimize page load time:

/optimize --metric "lighthouse_perf" --higher-is-better \
  --measure "npx lighthouse http://localhost:3000 --output=json --output-path=lh.json" \
  --extract "jq '.categories.performance.score * 100' lh.json" \
  --files "src/**/*.tsx,src/**/*.css" \
  --target 95 --budget 120

Optimize bundle size:

/optimize --metric "bundle_bytes" --lower-is-better \
  --measure "bun run build 2>&1 && du -sb dist/ | cut -f1" \
  --files "src/**/*.ts" \
  --constraints "all tests must pass"

ML training (Karpathy-style):

/optimize --metric "val_bpb" --lower-is-better \
  --measure "uv run train.py > run.log 2>&1 && grep '^val_bpb:' run.log | cut -d' ' -f2" \
  --files "train.py" \
  --locked "prepare.py" \
  --budget 300
Eval Mode

Optimize a skill's Extract workflow:

/optimize --target "~/.claude/skills/ExtractWisdom" --max-experiments 15

Optimize a standalone prompt:

/optimize --target "prompts/summarize-article.md" --runs 5

Optimize with custom criteria:

/optimize --target "~/.claude/skills/Research/Workflows/QuickResearch.md" \
  --criteria "Does the output contain specific facts with sources?" \
            "Is the output structured with clear sections?" \
            "Does the output avoid generic filler?" \
  --inputs "research quantum computing breakthroughs 2025" \
           "quick research on supply chain security" \
           "find recent developments in AI agents"

Gotchas

  • Hill-climbing can get stuck in local optima. If score plateaus, consider resetting with different initial conditions.
  • Eval mode vs metric mode: Use metric mode for quantifiable targets (latency, size). Use eval mode for qualitative targets (skill quality, prompt effectiveness).
  • Regression tolerance prevents catastrophic changes. Don't set it to 0 — some regression in secondary metrics is acceptable if primary metric improves significantly.
1---
2name: Optimize
3version: 1.0.12
4description: "Autonomous optimization loop — hill-climb any target. Code with metrics, or skills/prompts/agents with LLM-as-judge. USE WHEN optimize, hill climb, improve metric, reduce latency, optimize skill, optimize prompt, eval mode."
5disable-model-invocation: true
6---
7 
8# /optimize — Autonomous Optimization v2
9 
10## What It Does
11 
12Runs an autonomous optimization loop against any target. The agent modifies the target, measures the result, keeps improvements, discards failures, and repeats until it stops climbing. Two modes: metric mode for code targets that produce a number (latency, bundle size), and eval mode for skills, prompts, or agents judged by LLM-as-judge binary evals.
13 
14## The Problem
15 
16Tuning a thing for a measurable outcome is slow, boring, manual work. You change a file, run the measurement, eyeball whether it got better, keep or revert, then do it again — dozens of times. People give up after a few rounds and settle for "good enough" far short of the real ceiling. The targets without a clean number (a skill's quality, a prompt's effectiveness) are worse: there's no easy way to tell if a change actually helped. This skill runs that whole loop for you and only keeps changes that measurably win.
17 
18## How It Works
19 
20Two modes drive the same hill-climb loop:
21 
22- **Metric mode** — code targets with a shell command that produces a number (the original).
23- **Eval mode** — skills, prompts, agents, or any text target judged by LLM-as-judge binary evals.
24 
25Inspired by Karpathy's [autoresearch](https://github.com/karpathy/autoresearch) and extended with LLM-as-judge evaluation.
26 
27## Invocation
28 
29### Metric Mode (code targets)
30 
31```
32/optimize --metric "lighthouse_score" --higher-is-better \
33 --measure "npx lighthouse http://localhost:3000 --output=json" \
34 --extract "jq '.categories.performance.score * 100' lighthouse.json" \
35 --files "src/**/*.tsx,src/**/*.css" \
36 --budget 120
37 
38/optimize --resume # Resume a previous optimization loop
39/optimize --status # Show results summary from last/current run
40```
41 
42### Eval Mode (skill/prompt/agent targets)
43 
44```
45/optimize --target "~/.claude/skills/ExtractWisdom"
46/optimize --target "~/.claude/skills/Research/Workflows/QuickResearch.md"
47/optimize --target "prompts/my-prompt.md"
48/optimize --target "~/.claude/skills/ExtractWisdom" --max-experiments 20
49```
50 
51In eval mode, the system automatically:
521. Detects the target type (skill, prompt, agent, code, function)
532. Reads the target to understand its purpose and constraints
543. Generates 3-6 binary eval criteria and 3-5 test inputs
554. Presents criteria + inputs for your approval before starting
565. Runs the optimization loop using LLM-as-judge scoring
576. Presents a recommendation (apply/reject/partial) when done
58 
59## What Happens
60 
61This skill drives the LifeOS Algorithm as an autonomous mutation loop:
62 
631. **OBSERVE** — Define or auto-detect the target, set eval_mode
642. **THINK** — Analyze codebase/skill, generate hypothesis queue
653. **PLAN** — Prioritize hypotheses by expected impact
664. **BUILD** — Phase 0: TARGET ANALYSIS (see `optimize-loop.md`)
67 - Detect target type, auto-generate eval criteria (eval mode), set up sandbox, baseline
685. **EXECUTE** — The autonomous loop (`optimize-loop.md`):
69 - Hypothesize → Modify target → Measure (metric or eval) → Keep/Revert → Repeat
70 - Metric mode: ~12 experiments/hour (at 5-min budget)
71 - Eval mode: ~6-8 experiments/hour (multi-run judging is slower)
726. **VERIFY** — Phase 9: RECOMMEND — diff, summary, apply/reject/partial options
737. **LEARN** — Phase 10: EXTRACT LEARNINGS — what worked, what didn't, structured insights
74 
75## Arguments — Metric Mode
76 
77| Argument | Required | Default | Description |
78|----------|----------|---------|-------------|
79| `--metric NAME` | yes | | Human-readable metric name |
80| `--measure COMMAND` | yes | | Shell command that produces the metric |
81| `--files GLOB` | yes | | Files the agent may modify (comma-separated) |
82| `--higher-is-better` | | (default) | Higher metric values are better |
83| `--lower-is-better` | | | Lower metric values are better |
84| `--extract COMMAND` | | Last number in stdout | Extract metric from output |
85| `--budget SECONDS` | | 300 | Time budget per experiment |
86| `--target VALUE` | | none | Stop when metric reaches this value |
87| `--max-experiments N` | | none | Stop after N experiments |
88| `--locked GLOB` | | none | Files the agent must NOT modify |
89| `--constraints TEXT` | | none | Additional rules (e.g., "tests must pass") |
90 
91## Arguments — Eval Mode
92 
93| Argument | Required | Default | Description |
94|----------|----------|---------|-------------|
95| `--target PATH` | yes | | Path to skill directory, prompt file, or agent definition |
96| `--max-experiments N` | | none | Stop after N experiments |
97| `--runs N` | | 3 | Runs per experiment (more = more reliable, slower) |
98| `--criteria "Q1" "Q2"` | | auto-generated | Override auto-generated eval criteria |
99| `--inputs "I1" "I2"` | | auto-generated | Override auto-generated test inputs |
100| `--budget SECONDS` | | 300 | Time budget per experiment |
101 
102## Shared Arguments
103 
104| Argument | Description |
105|----------|-------------|
106| `--resume` | Resume a previous optimization run |
107| `--status` | Show results summary |
108 
109## Algorithm Integration
110 
111When `/optimize` is invoked, the eval_mode is set based on arguments (`mode:` is retired — never write it to frontmatter):
112 
113- `--measure` provided → `eval_mode: metric` (git branch sandbox)
114- `--target` provided → `eval_mode: eval` (directory sandbox)
115 
116ISC criteria become **guard rails** — assertions that must hold true across ALL experiments. Guard rails must REMAIN satisfied perpetually. A violation triggers automatic revert regardless of score improvement.
117 
118**Reference files:**
119- `~/.claude/LIFEOS/ALGORITHM/optimize-loop.md` — the full loop protocol
120- `~/.claude/LIFEOS/ALGORITHM/eval-guide.md` — how to write good eval criteria
121- `~/.claude/LIFEOS/ALGORITHM/archive/target-types.md` — target detection and ISC generation
122 
123## Examples
124 
125### Metric Mode
126 
127**Optimize page load time:**
128```
129/optimize --metric "lighthouse_perf" --higher-is-better \
130 --measure "npx lighthouse http://localhost:3000 --output=json --output-path=lh.json" \
131 --extract "jq '.categories.performance.score * 100' lh.json" \
132 --files "src/**/*.tsx,src/**/*.css" \
133 --target 95 --budget 120
134```
135 
136**Optimize bundle size:**
137```
138/optimize --metric "bundle_bytes" --lower-is-better \
139 --measure "bun run build 2>&1 && du -sb dist/ | cut -f1" \
140 --files "src/**/*.ts" \
141 --constraints "all tests must pass"
142```
143 
144**ML training (Karpathy-style):**
145```
146/optimize --metric "val_bpb" --lower-is-better \
147 --measure "uv run train.py > run.log 2>&1 && grep '^val_bpb:' run.log | cut -d' ' -f2" \
148 --files "train.py" \
149 --locked "prepare.py" \
150 --budget 300
151```
152 
153### Eval Mode
154 
155**Optimize a skill's Extract workflow:**
156```
157/optimize --target "~/.claude/skills/ExtractWisdom" --max-experiments 15
158```
159 
160**Optimize a standalone prompt:**
161```
162/optimize --target "prompts/summarize-article.md" --runs 5
163```
164 
165**Optimize with custom criteria:**
166```
167/optimize --target "~/.claude/skills/Research/Workflows/QuickResearch.md" \
168 --criteria "Does the output contain specific facts with sources?" \
169 "Is the output structured with clear sections?" \
170 "Does the output avoid generic filler?" \
171 --inputs "research quantum computing breakthroughs 2025" \
172 "quick research on supply chain security" \
173 "find recent developments in AI agents"
174```
175 
176## Gotchas
177 
178- **Hill-climbing can get stuck in local optima.** If score plateaus, consider resetting with different initial conditions.
179- **Eval mode vs metric mode:** Use metric mode for quantifiable targets (latency, size). Use eval mode for qualitative targets (skill quality, prompt effectiveness).
180- **Regression tolerance prevents catastrophic changes.** Don't set it to 0 — some regression in secondary metrics is acceptable if primary metric improves significantly.
181 

Discussion