/Optimize

name: Optimize
version: 1.0.12
description: "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."
disable-model-invocation: true

/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](https://github.com/karpathy/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