/optimize

name: optimize
description: Drive structured autoresearch iteration after evo:discover and the baseline commit. Use when the user invokes /evo:optimize or asks to try ideas, try variants, run experiments, use available GPUs, improve the current best/frontier, continue an evo search, or compare candidate changes in an evo workspace. The orchestrator plans and spawns optimization subagents; candidate edits/runs belong to those subagents. Width is set via subagents=N (1 for serial workloads, larger for parallel); the loop's structural value applies at any width.
argument-hint: "[subagents=N] [budget=N] [stall=N]"
evo_version: 0.8.0

Run the `evo` optimization loop. Each round, the orchestrator writes structured briefs and spawns subagents that execute within them. Each subagent is semi-autonomous: it reads the pointer traces, forms the concrete edit, runs experiments, and can iterate within its branch. Runs until interrupted or the stall limit is reached.

**This skill is the canonical loop for ALL post-discover work — including serial workloads.** If the workspace's resource profile forces width 1 (single GPU, single-process benchmark, etc.), you still invoke `/evo:optimize` -- just pass `subagents=1`. The loop's value is the STRUCTURE around each experiment (scan-subagent cross-cutting analysis between rounds, verifier pre/post hooks via the subagent skill, ideator spawning on stall, frontier reconciliation, stop-hook discipline), NOT just parallelism. Bypassing optimize because "I'm running serial work anyway" loses every piece of that structure -- you've reverted to ad-hoc experiment iteration with none of evo's loop benefits, just the bookkeeping.

**Plain-language trigger.** In an initialized evo workspace, casual user wording like "try a couple ideas", "try different variants", "use the available GPUs", "continue from the current best", or "see what improves" is an optimize request unless the user explicitly asks for a read-only report. Do not treat the lack of a slash command as permission to bypass this protocol. Loading this skill from plain-language wording is also explicit authorization to use the host's subagent mechanism for the resolved round width; the user does not have to say "spawn subagents" or "parallel agents" separately.

**Candidate-work delegation invariant.** The orchestrator does not create, edit, or run candidate experiments for the round. For `subagents=N`, write N briefs and spawn N optimization subagents; each spawned subagent allocates its own experiment with `evo new`, edits only its worktree, and runs `evo run`. Do not simulate a subagent round by running `evo new`, editing files, or launching multiple `evo run` commands from the orchestrator, even if that would be faster or easier. If the host's subagent tool is unavailable, stop and report that the host cannot run `/evo:optimize subagents=N` as requested; only fall back to orchestrator-owned experiments when the user explicitly asks for direct/manual execution or turns subagents-only off for that run. Do not infer a direct/manual fallback from casual wording, a simple-looking benchmark, or the absence of an explicit subagent phrase in the user's prompt.

**Resource-cap invariant.** `subagents=N` is live concurrency, not total ideas. Never spawn more concurrent optimization subagents or launch more concurrent benchmark jobs than the binding resource can support. If the user asks for more ideas than available GPU/Slurm/pool slots, batch them across rounds at the safe width, or stop and explain the cap if batching is impossible. Do not rely on the scheduler to absorb an accidental flood unless the user explicitly asks to queue/oversubscribe jobs.

**Bounded-run stop rule.** If the user says "one round", "stop after this round", "run them and tell me what happened", or otherwise asks for a bounded run, resolve autonomous off at startup. After the requested subagents finish, collect their evo-recorded outcomes, print the summary, and stop. Do not enter another loop turn, wait for a stop nudge, or keep the process alive just because the default autonomous behavior is normally on.

Evo surface -- loop-relevant

You're inside `/evo:optimize`. Things you'll pull/dispatch during the loop:

main thread (you)
├── Skills (Skill tool)
│   └── evo:finetuning     before writing or changing any train.py
│
└── Subagents to dispatch (Task tool, subagent_type=...)
    └── evo:ideator        stalled, or every ~5 committed experiments.
                           One subagent per brief:
                           failure_analysis, literature, frontier_extrapolation

subagent thread (each subagent spawned by step 5)
├── evo:subagent skill     loaded by the subagent on first turn -- the brief's
│                          first sentence mandates it (not auto-loaded)
└── evo:verifier subagent  MANDATORY pre AND post every evo run.
                           Pre: ~30s static analysis before the experiment runs.
                           Post: result-validity audit after it commits.

references (Read tool, on demand)
├── discover/references/sizing-the-round.md      pick subagents=N
├── references/evo-wait.md                       waiting without burning context
├── finetuning/references/glue.md                train.py I/O contract
└── finetuning/references/{rl,sft,serving}/      provider-specific recipes
                                                  (rl/art.md, sft/tinker.md,
                                                  serving/vllm.md)

Full surface tree (orchestrator entry-point view, including benchmark-reviewer, infra-setup, and the complete references catalogue) lives in `evo:discover`'s "Evo surface" section.

Host conventions

This skill runs on any host that implements the Agent Skills spec. When the body uses generic phrases, apply the host's best-fit equivalent:

• **"spawn N subagents in parallel"** -- use your host's parallel-subagent tool. See Step 5 below for the per-host spawn commands.