optimize
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.
npx skills add evo-hq/evo --skill optimize --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
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. Loading this skill from plain-language wording is explicit authorization to use the host's subagent mechanism for the resolved round width.
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.
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.
How it works
Run the evo optimization loop: the orchestrator writes briefs and spawns subagents; each subagent runs its own evo new and evo run within its branch. A verifier subagent runs pre- and post-experiment checks. There are references to sizing the round, waiting, and provider-specific I/O contracts. The loop can operate in two modes: a prose loop (default) or a Workflow-driven loop (optional,Claude Code only) controlled by config. The width, budget, and stall parameters shape the run, delivered via subagents=N, budget=N, and stall=N.
When to use it
Use when the user invokes /evo:optimize or asks to try ideas, variants, or run experiments, with available GPUs, to improve the frontier, continue an evo search, or compare candidate changes in an evo workspace. If the user explicitly sets a single-width resource profile, pass subagents=1. Use the workflow driver only if default-orchestrator is explicitly set to workflow and the Workflow tool is available; otherwise fall back to the prose loop.
What it can touch
Tooling involved includes the subagent mechanism and evo commands: evo new, evo run, and the subagent/verifier interactions. The workflow path references a scriptPath: ${CLAUDE_PLUGIN_ROOT}/skills/optimize/workflows/evo-optimize.js and arguments including subagents, budget, stall. Commands and file names must be quoted exactly as shown in the description.
Caveats
License: Apache-2.0. Declared tools: claude-code, codex. The orchestrator respects resource caps and does not spawn more subagents than the binding resource allows. If subagents are unavailable, it stops and reports the limitation rather than proceeding with partial or manual fallback without explicit user instruction.
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", "
- Evo surface -- loop-relevant
- Host conventions
- Mid-run user directives (evo direct)
- Configuration
- Prerequisites
- Architecture
- The Loop
- 1. Read current state
- 2. Analyze state and do structural aggregation
- 3. Spawn scan sub-agents for cross-cutting free-text analysis
- 4. Write subagent briefs
- 5. Spawn parallel optimization subagents
- 6. Collect results and update state
- 6a. Pattern recognition across history (objective, not narrative)
evo config get default-autonomous --json # workspace → true | false | null
evo defaults get autonomous --json # user-level → true | false | null (used only if workspace is null)
evo config get default-subagents-only --json
evo defaults get subagents-only --json
evo scratchpad # bounded state summary (tree, frontier, awaiting decision, gates, annotations, what-not-to-try, notes)
evo status # one-line summary
evo frontier # explorable nodes ranked by the configured strategy (JSON envelope: {strategy, nodes[{id,score,rank,...}], generated_at})
evo show <id> # full state of one node (attempts, diffs, annotations, notes, effective gates) -- the cleanest one-node getter
evo awaiting # evaluated nodes awaiting commit/discard decision
evo discards [--like <text>] # discarded nodes; useful for "have we tried this before"What does the optimize skill do?
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.
How do I install it?
Run `npx skills add evo-hq/evo --skill optimize --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From evo-hq/evo, a repository with 1,359 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.