/optimize

name: optimize
description: 'Use when asked to optimize code, make a path faster, make this as fast as possible, reduce allocations, repair a regression, profile a target, grill every inefficiency, or run a subsystem or repo-wide performance campaign against a measured floor; when a performance requirement, slowness report, Core Web Vitals miss, or profiling evidence identifies a bottleneck; or for an "extremely optimize" performance campaign, optimizing suspected hot paths without waiting for benchmarks, or estimating hot and complexity-neutral cold paths while refusing complexity theater. Not for remote, credential, publish, deploy, or irreversible changes.'

Optimize

Five mode names share one authority: reversible local writes to the resolved target, never push, tag, publish, deploy, or mutate a remote. Full and `extremely-optimize` intentionally select the same measured-floor campaign route, rather than separate procedures; the retired name remains an explicit compatibility mode value. That route runs an isolated five-lens search with an integrated 1.05x gate and an atomic commit. Quick mode runs a single measure-identify-fix-verify loop with a noise-aware keep/revert and a CI guard for the obvious-bottleneck case. `fastopt` mode reports suspected-hot-path hypotheses without mutating code. `fastopt-extreme` mode reports estimated hot paths and complexity-neutral cold-path simplifications while refusing complexity theater.

Contract

| Field | Bound contract | |---|---| | Trigger | The user asks to optimize code, make a path faster, make this as fast as possible, reduce allocations, fix a performance regression, profile and optimize a path, symbol, or diff, or a performance requirement, slowness report, Core Web Vitals miss, or profiling evidence identifies a bottleneck; asks for a measured-floor campaign, hypothesis-only suspected-hot-path analysis, or estimated hot/cold analysis that refuses complexity theater; or says "extremely optimize" or "grill every inefficiency". | | Authority | Full and `extremely-optimize` modes write only the exact VCS-tracked source-target set shown before mutation plus `.outline/optimize/<target>/` (destructive; rollback is version control); quick mode writes only the named target and an authorized CI performance-budget or field-monitor guard; `fastopt` and `fastopt-extreme` modes are read-only with no file, VCS, credential, paid, published, deployed, or remote mutation. Full mode may commit one winning optimization, but no mode tags, publishes, deploys, or mutates a remote. | | Side effect | Full and `extremely-optimize` modes append measurements and decisions to `.outline/optimize/<target>/log.jsonl`, benchmark isolated candidates, gate all boundary surfaces before touch, revert non-wins, apply the winner, and create one atomic commit. Quick mode applies one targeted fix and may add a CI performance budget or field monitor. `fastopt` mode emits labeled hypotheses and benchmark designs. `fastopt-extreme` mode emits hot-path hypotheses, benchmark designs, cold-path simplifications, and complexity-theater refusals. | | Done | Full and `extremely-optimize` modes rebuild hot units with a measured 1.05x-or-better win, grade cold units fixed/at-floor/left, remove residue, pass the verifier, and land the target atomically. Quick mode: the identified bottleneck is measurably improved past noise, tests remain green, no new regressions exist, and a CI budget or field monitor guards the metric. `fastopt` mode: every named path has a labeled hypothesis and benchmark design, with no mutation or speed claim. `fastopt-extreme` mode: every hot estimate has a falsifiable benchmark, every cold candidate is complexity-neutral or rejected, and every complexity-theater proposal is refused. | | Inputs | The required mode-specific inputs are listed below; the `mode` input selects exactly one route and must not combine a mutating route with a read-only route. |

Inputs

• Mode (optional, exact values when supplied): `full`, `extremely-optimize`, `quick`, `fastopt`, or `fastopt-extreme`. The mode selects exactly one route; do not combine a mutating route with a read-only route. When omitted, select from the trigger and evidence.
• Full or `extremely-optimize` mode (measured-floor campaign): a named resolvable path, symbol, diff, or active local change, or no path only for an explicit repo-wide survey; repo-wide work is opt-in and never inferred. For a bare `extremely-optimize` invocation after that opt-in, profile the repository's own workload and work the ranked list. One representative runnable workload or benchmark command and repository-native verification commands are required. The workload must be supplied or constructed before measurement and must exercise the target for at least one second of wall time. The verifier must be supplied or discovered before any target lands. A supplied profile or named hotspot is optional. Optional controls are a performance budget, maximum gate attempts, maximum wall time, and minimum marginal speedup. An observable approximation is permitted only when the user's request authorizes it and the exact changed contract is confirmed before mutation. If the target or workload cannot be resolved without guessing, stop with exit 11.
• Quick mode: a resolvable target, a performance symptom and the codebase under optimization, and repository-native verification commands. Existing measurements, profiling evidence, performance budgets, or Core Web Vitals targets are optional.
• `fastopt` mode: one or more suspected hot paths named by the user (file, function, or call site) and the workload or input shape that makes each path hot. Prior measurements, profiling traces, and environment constraints are optional; absent measurements are unmeasured, not evidence of slowness.
• `fastopt-extreme` mode: the target code region or module. Call frequencies, profiling data, or prior benchmark results are optional. If no code is supplied, request t