
Harness Evolve
FreeEvolve your harness configurations without retraining.
Free · Opens the source repo
What Harness Evolve does
Harness Evolve is a skill designed to optimize the configurations of your harness in a controlled manner. By utilizing the @metaharness/darwin evolve CLI, this skill allows you to mutate seven distinct policy surfaces of your harness, including planner, contextBuilder, reviewer, retryPolicy, toolPolicy, memoryPolicy, and scorePolicy. Each mutation is evaluated in a sandbox environment, enabling you to identify which changes yield the best performance improvements without the need to retrain the underlying model. This is particularly useful when you encounter stagnation in your harness's readiness scores and need to pinpoint the specific policy surface causing the issue.
The skill is intended for developers and data scientists who are looking to empirically discover effective configurations for their harnesses. Instead of relying on manual tuning, you can seed your harness with various configurations and let the system determine the most effective setup. This approach is especially beneficial when venturing into new verticals where established configurations may not apply. Additionally, if you have a hand-tuned harness, you can compare its performance against an evolved baseline to assess the effectiveness of your manual adjustments.
It’s important to note that Harness Evolve is not designed for continuous optimization. The evolution process is initiated by the user, making it suitable for one-off explorations rather than ongoing self-modification. Furthermore, it should not be used for continuous integration (CI) processes, as the system is built to ensure graceful degradation rather than automatic evolution. This design choice helps maintain stability and reliability in your CI workflows while still allowing for powerful configuration experiments when needed.
When to use it
Use this skill when your harness's readiness scores are stagnant, or when exploring configurations for a new vertical.
When not to use it
Avoid using it for continuous optimization or integrating it into CI workflows where automatic evolution is not permitted.
What you can build with it
Identifying Policy Issues
When a harness's readiness scores are flat, use this skill to determine which policy surface needs adjustment.
Exploring New Configurations
Seed a harness for a new vertical by using this skill to empirically find effective starting configurations.
Comparing Configurations
Evaluate the performance of a hand-tuned harness against an evolved baseline to assess the effectiveness of manual tuning.
How to install Harness Evolve
View source1. Install with the skills CLI
npx skills add ruvnet/ruflo/harness-evolve --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by ruvnetSurfaces the upstream metaharness-darwin evolve CLI as a ruflo skill. The
write layer that pairs with ADR-150's read layer (score / genome /
mcp-scan / threat-model / oia-audit). Use when you have a harness whose
readiness scores are flat and you want to discover which surface mutation
moves them — without retraining the foundation model.
When to use
- A
harness-scoreresult is below target and you don't know which policy surface is responsible. - You're seeding a harness for a new vertical and want to find a good starting configuration empirically rather than hand-tuning.
- You're comparing your hand-tuned harness against an evolved baseline (treat darwin's champion as the strawman).
When NOT to use
- For continuous background optimization. Darwin Mode is human-initiated. Wire it into CI for one-shot exploration, not for autonomous self-modification.
- For ruflo itself in CI. ADR-153 §5 explicitly rejects auto-evolving ruflo — the CI gate verifies graceful degradation, not convergence.
Algorithm
Implementation: scripts/evolve.mjs.
- Validate args (
--repoexists, caps on--generations≤ 50,--children≤ 20,--concurrency≤ 8, sandbox/selection/mutator are known values). - Without
--confirm: print plan + exit 0 (mirrorsharness-mintsafety convention; defense in depth over the upstreamsafety.tschecks). - With
--confirm: shell tonpx -y @metaharness/darwin@~0.8.0 metaharness-darwin evolve <repo> ...via the shared_darwin.mjsasync helper. Per-generation progress is forwarded to stderr; final champion JSON is captured from stdout. - Compute timeout from
generations × children × per-variant(per-variant ≈ 60s real, ≈ 2s mock). Caller may override with--timeout-ms. - Honor upstream exit code 99 — propagate as "safety-disqualified", do not
remap. This is a designed-in tripwire (a variant tripped
inspectVariantfor secrets / shell-out / network / dynamic-eval). See ADR-153 §"Safety model". - Optional
--alert-on-no-improvement: exit 1 when champion ≤ parent.
The seven mutation surfaces
| Surface | What it owns |
|---|---|
planner | task decomposition / step ordering |
contextBuilder | what gets fed into the prompt |
reviewer | self-critique / output verification |
retryPolicy | when + how to retry on failure |
toolPolicy | which tools the agent may use, under which conditions |
memoryPolicy | what to persist, recall, forget |
scorePolicy | how the agent grades its own output |
One mutation per variant. Multi-surface mutations are not allowed (causal attribution stays clean).
Output
Reports land under <repo>/.metaharness/:
.metaharness/
archive.json # full lineage tree (sampling next gen draws from this)
lineage.json # parent→child edges only
variants/<id>/ # per-variant code (kept for audit)
runs/<id>/ # per-variant sandbox test output
reports/winner.json # final champion + score delta vs parent
Skill stdout = JSON {success, data: {champion, plan, durationMs, improved}}
(plus data.diagnosis when --diagnose is passed — see below).
Failure diagnosis (--diagnose)
GEPA's key trick is natural-language failure diagnosis from execution traces
feeding the next mutation — not just scalar fitness. --diagnose adds a
modest slice of that: after the evolution completes, the losing / failed
variants' transcripts are run through darwin's GEPA library ops
(analyzeTranscript + classifyFailure, via the shared importGepa
resolver in scripts/_darwin.mjs) and a diagnosis section is appended to
the emitted JSON:
"diagnosis": {
"available": true,
"scope": "losing-variants",
"variants": [
{ "id": "g1_v0", "transcripts": 2,
"failureClasses": { "exploration-loop": 1, "edit-mechanics": 1 },
"dominantClass": "exploration-loop" }
],
"totals": { "exploration-loop": 1, "edit-mechanics": 1 }
}
Upstream shape caveats (verified against @metaharness/darwin@0.8.0):
metaharness-darwin evolve --jsonprints a TEXT leaderboard — the stdout carries no JSON and no transcripts. Per-variant run records live at<repo>/.metaharness/runs/<id>.json.- Those run records hold sandbox exec traces (
{taskId, exitCode, stdout, stderr}), which are NOT GEPA{actionRaw, obs}transcripts. Diagnosis therefore uses GEPA-shaped transcripts when a run record embeds them (agent sandbox / future upstream), falls back to the champion's transcript, and otherwise emitsdiagnosis: {available: false, reason, traceSummary}wheretraceSummaryis a mechanical per-variant tally (tasks / failed / timedOut / blockedActions). --diagnoseNEVER fails the run — any internal error degrades to{available: false, reason: "diagnosis-failed: ..."}.
Exit codes
| Code | Meaning |
|---|---|
| 0 | Evolved OK, or dry-run, or degraded (Darwin absent) |
| 1 | --alert-on-no-improvement and champion did not beat parent |
| 2 | Config error or evolution infrastructure failure |
| 99 | Upstream "safety-disqualified" (PROPAGATED, not remapped) |
Graceful degradation (ADR-150 constraint 3 + ADR-153)
When @metaharness/darwin is not installed, the script emits
{degraded: true, reason: 'metaharness-darwin-not-available', hint: ...}
and exits 0. ruflo continues to function. CI's
no-metaharness-smoke.yml-style job asserts this path.
Frequently asked questions about Harness Evolve
Similar skills
Build MCP Server
Streamline your MCP server development with guided discovery.
MCP Server Development Guide
Build high-quality MCP servers for LLM integration.
NemoClaw Documentation Access
Streamline your access to NemoClaw documentation with AI agents.
Azure AI Gateway
Manage AI models and tools with Azure API Management.
Agent Connect
Seamlessly connect agents to external APIs and services.
OpenAPI to MCP
Transform OpenAPI specs into MCP servers effortlessly.
