The Skill That Ignored Its Own Engine

🔄 What is an evolution loop?

An evolution loop is an automated improvement cycle for AI tools: run a real task, score the output against fixed rules, propose one small change, test that change on benchmarks, and keep it only if it measurably wins. Then repeat until the scores stop climbing.

Ours is called Evo-Loop, and it evolves Claude Code skills: the instruction files that tell an AI coding agent how to work. It ships alongside a dependency called godmode-evolution, and that relationship is where this story starts.

🚨 Two files described one loop

This week we audited the standalone skill, two full passes. The trigger words belong to /evo-loop, but its dependency ships its own loop protocol file, plus a runner: a small command line program that owns every number, path, and log format in the system.

So two documents described the same loop, and they disagreed on almost everything. When two maps describe one road, at most one of them is right.

🕵️ The evidence was already on disk

We did not have to guess which file was telling the truth. A real ten-iteration run had just finished, and its artifacts were still on disk.

Four clues, each one checkable. Click through them.

{"benchmark":"OS1","composite":0.9107,
 "adjusted_composite":0.8952,
 "first_loop_cap_applied":true}

Those two fields matter because they are anti-inflation caps: rules that stop a fresh variant from scoring too generously.

Only the runner computes them. Hand-written scores do not cap themselves.

⚖️ What v2.0.0 changes, side by side

The rebuild keeps the skill in the driver's seat and hands everything mechanical to the engine and runner. Here is the whole shift in one table.

The three bars v1 collapsed into one

Three different jobs, three different numbers, and they had been sitting in the runner's code all along. v1 used one 0.70 bar for all three jobs because it never asked.

Two more upgrades ride along. v2 keeps several skill variants alive and picks the one to run each round with a weighted draw that favors past winners without starving the rest.

And progress is only ever judged by re-running the same task later, never by comparing today's task with yesterday's different one. The second habit sounds obvious and is the single most common way self-improvement loops flatter themselves.

🧭 What the audit got wrong at first

Audits cut both ways, including at the auditor. Our first pass flagged the skill for saving data relative to whatever folder you run it from.

That turned out to be the engine's deliberate design, so the fix is a setup warning, not a rewrite.

And in one place the skill was right while the dependency was wrong: the engine's own docs pointed version archives at a folder the runner never uses. The real archives on disk proved it.

So the rebuild shipped with a patch to the dependency too, the same day, in the same commit.

💡 How to audit a skill against its dependency

This generalizes to any tool built on top of another one. The recipe we used:

1. List every hard claim the skill makes: paths, thresholds, file formats, commands.
2. Find the same claims in the dependency's code, not its docs.
3. Diff the two lists. Every mismatch is a bug in one of the two.
4. Pull a real run's files and check which side the disk agrees with.
5. Rebuild the weaker side as a thin layer over the stronger one.
6. Version the change, archive the old files, and write down what you got wrong too.

It is the same lesson that keeps landing every time we point the audit gun at ourselves, from the tools that vanished underneath a skill to the quality loop that failed our own best work to the first full audit of the evolution engine. The system that grades your work has to be graded hardest of all.