Hillclimb

You own the metric and the experiment's integrity. Supervise and review. Delegate the attempts. For sustained, iterative improvement of one measurable thing against a target. For a one-off fix, use bug-fix or perf-issue. This is the loop.

Core discipline: one change, one measurement, keep or revert. Never stack untested changes, and never claim a win from code inspection under prove-it-works.

Honor the caller's scope. For diagnosis-only work, stop with the available measurements and proposed experiments before changing the implementation. Read-only work also excludes instrumentation.

1. Ground the workload and architecture before choosing the metric. Run how over the target, name the realistic workload dimensions that can move the result, such as data size, history, state, and concurrency, and select a case that reproduces the user's complaint. If no case reproduces it, fix the repro instead of hillclimbing. Then fix one metric, its direction, the target, and the experiment budget. Honor a requested minimum number of attempts, such as "at least 50% better and at least 10 iterations." Otherwise use repeated confirmation to guard against a lucky early win. Use the user's limits when given. State bounded defaults for unspecified limits before experimenting. Reuse the caller's workload, baseline evidence, and authorization when they meet these requirements.
2. Build the measurement harness, prove its sensitivity, then freeze it under build-the-lever. Run contrasting realistic workloads and confirm the target case reproduces the symptom while easier cases separate as expected. If the harness cannot distinguish them, revise the workload or metric. Once frozen, one repeatable command emits the metric, sampled enough to clear the noise, with a named trial count and summary statistic. Use perf-issue's measurement requirements for configuration, variation, and comparable measurements, without restarting its workflow. Record the baseline metric and a green run of the correctness checks before changing the implementation. Preserve the measurement command and its version. If the workload or measurement method must change later, start a new baseline and keep the earlier evidence separate.
3. Open or reuse the decision trail through show-me-your-work. Read it before each attempt and append one row per iteration using its existing format. Link an experiment record with the hypothesis, revision, change, raw measurements, delta, correctness results, and keep or revert verdict. The parent owns shared log writes.
4. Ground each hypothesis in the architecture model from step 1, so it names a specific mechanism ("defer X off the boot path because it blocks first paint"), not "try memoizing something".
5. Loop, one hypothesis per iteration:
   • Hand the change to an available subagent with a tight scope, accepted revision, hypothesis, measurement command, and correctness checks. Supervise and review the diff. If delegation is unavailable, implement directly and make the separate review pass explicit. Independent hypotheses may use separate worktrees under separate-before-serializing-shared-state.
   • Measure before and after with the frozen command, and run the correctness checks. Serialize benchmarks on shared resources. Before accepting a parallel candidate, reapply and verify it against the latest accepted revision.
   • Accept a performance gain only when it exceeds the noise and correctness stays green. Otherwise revert only that attempt's changes, preserving unrelated work. Record an inconclusive result as inconclusive. The simplification exception in step 6 must be recorded as such, not counted as a metric gain.
   • When commits are in scope, make one commit per accepted fix, staging only its files. Otherwise record the accepted diff and base SHA. Log the row for kept and reverted attempts alike. Each iteration ends in a check before the next begins under sequence-verifiable-units. Continue while the session is active and budget remains. Automatic wake or restart requires an actually configured scheduler. A saved checkpoint alone does not resume execution.
6. Push past the first plateau. On a stall, several rejects in a row, pivot category, combine near-misses, re-read the source, or try something more radical before concluding the hill is climbed. Correctness and simplicity outrank the number. Revert a win that breaks behavior, and keep a simplification that holds the number under Laziness Protocol. It must pass the same correctness checks and show no regression beyond noise.
7. Stop when repeated measurements confirm the target and any requested minimum attempts are complete, the budget is exhausted, or the remaining ideas are not worth their cost. Do not relax the target to declare success. While budget remains, try cheap untested hypotheses before concluding that improvement has stalled. If you are stuck, surface it instead of spinning.
8. Recheck the final accepted state with the frozen measurement command and correctness checks. Use open-pr within the task's delivery scope, preserving accepted commit order. When that scope stops short of a PR, such as local-only work, run review-pr in fix-and-review mode instead. Merging is separate.

For a multi-phase unit, reuse the shared execution store. At a session boundary, follow handoff. Save the accepted revision or diff, frozen command and workload, baseline and latest results, remaining budget, rejected hypotheses, next experiment, active workers, and temporary instrumentation. On pickup, reconcile the actual working state and workers with that record before continuing. Retain supporting evidence and remove only disposable probes you introduced.

Reply: the metric and target, baseline to final with the percent delta, iterations run (kept vs reverted), each accepted fix on one line, the decision-trail path, why the run stopped, whether the target was met, and the best idea you would try next if pushed further. Include the trail audit and Attention findings required by show-me-your-work.