Hill Climb

Drive a codebase metric toward a defined target one improvement at a time, without a fixed schedule. The loop self-paces — it polls fast when progress is being made and sleeps long when blocked.

Arguments

• <area> — the scope to improve (a directory, module, or file pattern)
• <target> — the measurable condition to reach (e.g. "every file under 300 lines", "zero any types", "lint clean", "p95 under 200ms")

The target must be a number you can re-measure. "Audit the slideshow" or "make it better" are not hill-climb targets — route those to a normal task or a review skill; invoking this skill on a fuzzy goal produces one measurement and a dead loop (observed in ~a third of past runs).

Size the target to ~20–50 wakes. At one fix per wake, a 147-violation target is a multi-day run (observed). Bigger backlogs: partition the metric (src/components first, not all of src/) or set an intermediate target ("under 50 open"), then re-invoke.

Steps

1. Measure the current state — count violations, run the relevant linter/type-checker/test, or query the metric.
2. If target is already met: print "target met" and end.
3. Pick the single worst violation. Fix it — behavior-preserving, minimal change.
4. Re-run the check to confirm the fix reduced the violation count and nothing regressed.
5. Commit: refactor: hill-climb <what> <before>→<after>.
6. Log the violation-count delta for this wake.
7. Repeat.

Stop conditions

• Target is met (clean measurement).
• 3 consecutive wakes with zero delta in the violation count — report the blocker and stop. Persist per-wake deltas in a state file (see /loop-state) — the no-progress check must survive across sessions.
• User interrupts for any reason → report cumulative progress (start → now, N wakes, M fixed) before ending, so the run's value is visible even when aborted.

When the plateau fires

Don't just stop silently — past runs show the user had to type "CONTINUE UNTIL ALL ARE CLEARED" because the stop gave no next move. Report which of the three plateau causes applies, with evidence:

• Ceiling — the measured scope has no remaining violations of the easy kind; what's left needs a different approach. Say what's left and why each is hard.
• Wrong metric — the number isn't moving because the fixes don't affect what's measured. Propose the corrected metric.
• Risky remainder — remaining fixes aren't behavior-preserving. List them; they need human sign-off, not more wakes.

Then give the exact re-invocation for the recommended next step (e.g. /loop hill-climb src/features to zero any-types with the partitioned scope), so resuming is one paste, not a re-derivation.

Constraints

• One improvement per wake — don't batch several fixes in one commit.
• Never change behavior. Tests are the proof.
• Never push, deploy, or modify migrations.

Report format (each wake)

Violations before: <n> | after: <n> | delta: -<d>
Fixed: <file:line> — <what>
Status: <n remaining> | target: <target>

Loop usage

/loop hill-climb <area> to <target>.

Omit the interval — the loop self-paces.

Example

/loop hill-climb src/ to every file under 300 lines.