---
name: mountaineering
description: Autonomous hill-climbing loops for continuous improvement. Use when optimizing something measurable — prompts, configs, code, predictions — through iterative propose/test/keep-or-revert cycles.
---

# Mountaineering

The mountaineering skill teaches agents how to climb hills. For any hill that can be identified, set up guardrails and climb it.

This is autoresearch applied as a discipline: assess the mountain, choose the route, pack the right gear, know when to turn back.

## The Five Laws

Every successful climb requires five conditions to hold. See `laws.md` for the full treatment with examples and failure modes.

1. **Orderable Outcomes** — The optimizer must be able to say "this is better than that"
2. **Measurement Consistency** — The metric must score the same way twice
3. **Safe Exploration** — Failed experiments must be fully reversible
4. **Scope Separation** — The optimizer must not control the evaluation
5. **Informed Search** — The optimizer needs domain knowledge to generate targeted hypotheses

If any law is violated, the loop will fail — often expensively.

## Three-Layer Architecture

### Layer 1: Pre-Flight

Run the pre-flight protocol (`preflight.md`) before starting any climb. Pre-flight is a collaboration between the agent and the operator — the agent runs mechanical checks, the operator provides judgment. A failed pre-flight saves tokens.

### Layer 2: Harness Setup

The harness is the structural scaffolding that enforces the five laws during a climb. See `harness.md` for directory structure templates, config schemas, program.md templates, and evaluation script patterns.

### Layer 3: Climbing (The Loop)

The iteration loop: propose change → test → score → keep or revert → repeat. One change at a time for interpretability. The climber reads failing cases and hypothesizes fixes — Law 5 in action.

## The Climber Subagent

The climber is a fundamentally different kind of subagent from identity agents:

| | Identity Agent | Climber |
|---|---|---|
| **Loop** | Event-driven | Infinite loop |
| **Memory** | Blocks + files + journal | Files only (sliding window) |
| **Identity** | Rich persona | None (goal + constraints) |
| **S5** | Scaffolding (blocks, prompts) | Code + program.md (frozen) |
| **Context per turn** | Variable | Fixed budget |
| **Lifespan** | Persistent | Scoped to a climb |

### Climber Memory (Three Layers)

1. **program.md** — Frozen S5. Goal, constraints, scope. The climber cannot edit this.
2. **Workspace + evaluation** — The harness. Evaluation logic is held in supervisor memory (not on disk). The climber operates within the workspace scope.
3. **Results log** — Sliding window of recent results (last N entries via ring buffer). This prevents context growth while maintaining enough history for informed search (Law 5).

### Skill Inheritance

The climber inherits whatever skills and tools the parent agent has configured. If the operator has set up a coding agent (e.g., acpx), the climber gets it automatically — no separate configuration needed. If not, the climber still works with built-in file tools.

This means the first test climb from an agent without a coding agent gets lightweight tools (file read/write/edit). A code-optimization climb launched from an agent WITH a coding agent gets the full toolset. Zero config, correct by default.

### Fixed Context Constraint

**This is load-bearing.** Every iteration must wake up with roughly the same sized context. No accumulated conversational history. Each iteration is a fresh agent invocation that reads: program.md + current workspace files + last N log entries. That's it.

The results log is the climber's only memory between iterations. After each iteration, the climber should read the last N entries to understand what has been tried and what worked. The log is not a record for the operator — it is the climber's operational memory.

### Supervision Protocol

The climber has minimal autonomy by design. It cannot flag that it's stuck or incorporate new ideas on its own. The supervising agent must monitor actively.

**Intervention decisions:**
- **Keep running** — trend positive, still improving
- **Investigate** — plateau detected, consider scope expansion or metric pivot
- **Inject information** — make git commits that change the workspace; the climber picks up changes next iteration
- **Kill** — stuck, budget exceeded, or hill no longer relevant

**Peak detection → ridgeline traversal:** When the hill is peaked, the supervising agent declares the peak, selects the next hill, and either reconfigures the current climb or starts a new one. See `philosophy.md` for the full framework.

## Background Reading

For the theoretical framework behind mountaineering — VSM mapping, anti-gaming philosophy, recursive nesting, metric over-adherence — see `philosophy.md`. Understanding this background helps the supervising agent make better judgment calls, but it is not required for basic operation.
