Skip to content
Get packs

Guide · Agent skill

How to use the HillClimb agent skill in LifeOS

Updated · written with AI from the project's own documentation and checked against our catalogue data

HillClimb is an agent skill for LifeOS that improves one named thing, such as a skill, workflow, eval, ISA, prompt, rule or code metric, by running a structured experiment loop rather than guessing at edits. This guide explains what the skill does, how to install it, how to ask for it in plain language, and what it needs before it will give reliable results. By the end you will know whether it fits your setup and how to start a first climb.

HillClimb Improverdanielmiessler/LifeOS · MIT

Quick start

  1. 1Check your LifeOS setup. Confirm that LifeOS has Errata, Assay, ISA and Upgrades installed, and that Bun and model access are available.
  2. 2Download the ZIP. Download the HillClimb ZIP from this skill's page in the directory.
  3. 3Unzip into a skills folder. Unzip into ~/.claude/skills/ for personal use, or into a project's .claude/skills/ folder for one project.
  4. 4Or upload it in the Claude apps. In the Claude apps, open Settings, go to Capabilities, then Skills, and upload the ZIP.
  5. 5Ask for a survey. Ask what hurts most or what should be improved, so the skill ranks real hills from your LifeOS data.
  6. 6Pick one target and climb. Name one skill, workflow, eval, ISA, prompt, rule or code metric and ask the agent to hill climb it.
  7. 7Review the before-and-after result. Read the baseline, best result, delta and diff in the closing report before accepting the change.

What is an agent skill, and what does HillClimb make the agent do?

An agent skill is a folder of instructions and tools that an AI agent loads when a request matches it. HillClimb is one such skill for LifeOS. When it applies, the agent takes one target and improves it through experiments: it gathers complaints and failing cases from the LifeOS instruments (Errata, Assay and the ISA), proposes varied changes, measures each one against held-out test cases, and keeps only the changes the measurements support.

Each attempt is recorded in a ledger. Every win is turned into a standing check so the same failure does not come back, and a final check confirms that complaints actually fell. With no target named, the skill surveys LifeOS for the real hills and ranks them, so you can choose what to improve.

  • Works on a skill, workflow, eval, ISA, prompt, rule or code metric
  • Keeps or reverts each change based on measurement, not opinion
  • Reports baseline, best result and the delta, plus the diff that produced them

How do you install the HillClimb skill?

Download the HillClimb ZIP from the skill's page in this directory. Unzip it into your personal skills folder, ~/.claude/skills/, so the HillClimb folder sits there. To make the skill available only inside one project, unzip it into that project's .claude/skills/ folder instead.

If you use the Claude apps, you can upload the ZIP instead. Open Settings, go to Capabilities, then Skills, and upload the file there.

  • Personal install: ~/.claude/skills/
  • Project-only install: the project's .claude/skills/ folder
  • Claude apps: Settings → Capabilities → Skills, then upload the ZIP

What does HillClimb need before it runs?

HillClimb is not a standalone tool. It depends on a working LifeOS installation with its Errata, Assay, ISA and Upgrades instruments in place. It also needs the Bun runtime, which executes the bundled HillClimb.ts tool, and local evaluation run files stored under MEMORY/STATE/Evals-Results.

The skill needs a model or API access for the agent and for any judge or proposer steps. The skill files do not name a specific key or provider, so check your own setup for that.

  • LifeOS with Errata, Assay, ISA and Upgrades
  • Bun runtime for HillClimb.ts
  • Local run files under MEMORY/STATE/Evals-Results
  • Model or API access for the agent, judges and proposers

How do you trigger HillClimb with natural requests?

You do not need a command to use the skill. Describe what you want in plain language and include the thing you want improved. Phrases such as 'hill climb this', 'improve X', 'make X better', 'this keeps failing, fix it for good' or 'did that fix work' are the kinds of requests it is built to match.

To see what the skill would work on before you pick a target, ask what should be improved or what hurts most. The skill can then run its survey, which is also available as a direct command.

  • 'Hill climb the expense-report skill, it keeps getting totals wrong.'
  • 'What hurts most in our LifeOS setup?'
  • 'Turn this miss into a check so it does not come back.'
  • 'Did that fix work? Show before and after.'
bun skills/HillClimb/Tools/HillClimb.ts survey --json

How does a climb run and when does it stop?

A climb starts with a baseline measured by an existing instrument and recorded with how it was measured. Proposed changes are drawn from varied proposers and checked against train cases. Only the held-out test score can keep a change, and the keep rule is enforced in code. A judge's opinion can decide which proposals get measured, but never which are kept.

A climb can stop for several reasons: it reaches its target, it uses up a budget you set when opening it, it reaches a plateau, or it hits a safety gate or an abort. Closing the climb records the reason. When a climb keeps failing the same way, the skill categorises the stall as an artifact, grader, harness, structural or variance problem before changing content again.

  • Stop reasons: plateau, target, budget, abort, or reviewed for a Loop
  • Budget is optional; it can be set with a count of experiments
  • The climb is verified only when Errata shows the complaint rate fell

What about safety, scripts and network access?

HillClimb runs scripts and uses the network. Its bundled tool runs under Bun, and proposer and judge steps call a model or API. Review the skill's files and the commands it proposes before you let it run in a directory with sensitive data, and confirm which API access your agent is using.

Some internal commands are not part of the public release. The skill notes that the Bunker CLI is maintainer-private, so public users should expect code checks to run with bun test and suite checks with bun skills/Assay/Tools/EvalRunner.ts.

  • Runs scripts (HillClimb.ts) and makes network calls to models or APIs
  • Bunker CLI is maintainer-private and not in the public release
  • Proposers never see test, screen or holdout cases or their scores
bun test ./<path>

What people use it for

  • Improving a LifeOS skill that keeps producing the wrong output, with each fix tested against held-out cases.
  • Reducing latency or another measured metric in a code path, with before-and-after numbers.
  • Turning a recurring failure into a standing check so the same miss does not return.
  • Sharpening an eval suite or judge so its scores agree better with your own labels.
  • Surveying LifeOS to find which skill or workflow hurts most before deciding where to spend effort.

Frequently asked questions

Is the HillClimb agent skill free?

HillClimb is released under the MIT licence, as stated on this page. The licence governs use of the skill's code and files, but running it still requires model or API access and a LifeOS installation with its supporting instruments.

What do I need to run HillClimb?

You need a LifeOS installation with Errata, Assay, ISA and Upgrades, the Bun runtime to run HillClimb.ts, local evaluation run files under MEMORY/STATE/Evals-Results, and model or API access. Without these instruments, the skill's results would be unreliable or unavailable.

How do I install an agent skill from a ZIP file?

Download the ZIP, then unzip it into ~/.claude/skills/ for personal use or into a project's .claude/skills/ folder for one project. In the Claude apps, you can instead upload the ZIP under Settings, Capabilities, Skills.

When should I use Errata instead of HillClimb?

Use Errata when you only need to file a single complaint or bug report. HillClimb is for improving a named thing through repeated experiments, and it is not needed for simple logging or one-off complaints.

How is HillClimb different from one-pass brainstorming?

HillClimb runs a measured loop: each change is tested against held-out cases and kept only if the measurement supports it. One-pass brainstorming produces ideas without that measurement, so it is cheaper but gives no evidence that an idea helped.

Why did my HillClimb run stop or refuse to continue?

A run can stop at a plateau, a set budget, a target, a safety gate or an abort, and closing records the reason. If you see a refusal, check that the local run files exist under MEMORY/STATE/Evals-Results and that the required LifeOS instruments are installed.

New agent skills, repos and AI tools — every week

The best new skills and open-source projects, the fastest-growing repos, and one free prompt. Five minutes to read. Unsubscribe anytime.

Our verdict

HillClimb suits developers and power users who maintain LifeOS skills, evals or prompts and want changes proven by held-out measurement, with before-and-after results. It is the wrong choice for a single bug report, for quick brainstorming, or for anyone who does not have the LifeOS instruments, Bun and model access in place.

Download the skill