Letting AI Curate Agent Skills: Why Zero Changes Can Be the Right Result

The purpose of automated skill maintenance is not to delete files on every run. It is to support each keep, merge, or archive decision with evidence and make a bad decision recoverable.

On August 8, 2026, the curator on my Hermes server completed its forty-third run. Before the run, the library contained 73 active skills and 65 archived skills. The curator considered 19 agent-created candidates, skipped five protected by a pinned rule, and read the remaining fourteen in full.

The result was zero merges, zero archives, and zero state changes.

That is a failure if the goal is “remove at least ten every week.” It may be the right answer if the goal is a useful, auditable, recoverable skill library. The fourteen candidates were already coherent umbrella skills. Merging them to satisfy a quota would entangle distinct triggers, scripts, and reference material again.

File count is not the curator's objective

A skill library grows naturally. Work produces candidates. Repeated patterns may become maintained skills. Material that is unused or covered by a better module may move to an archive.

The mistake is to equate growth with bloat. More files do not prove duplication, and fewer files do not prove clear boundaries. A curator needs to answer at least four questions:

1. Do two skills serve the same user intent, rather than merely share keywords?
2. Is one candidate already a stable entry point for several small capabilities?
3. Can its scripts, templates, and examples remain intact through a merge?
4. Would archiving break a historical task or another skill that still depends on the path?

I therefore do not reward the curator for deleting a minimum number. It may propose a merge or archive, but zero changes is a valid outcome. The conditions worth rejecting are unread candidates, missing evidence, broken package integrity, or an irreversible write.

Make every maintenance run recoverable

Before each curator run, the system creates a pre-run backup. The latest August 8 manifest recorded 73 skill files and 44 cron jobs in an archive of about 4.13 MB, explicitly labeled pre-curator-run.

The order matters: freeze a recoverable state before allowing a model to propose changes. The flow is:

inventory active and archived material
  → create a pre-run backup and manifest
  → exclude pinned skills
  → read candidate packages in full
  → decide keep / merge / archive
  → validate references and package integrity
  → write the report and state
  → retain a restore path

Archive is not deletion. Archived material stays in a separate location and can return through a restore command or a controlled move. The curator can perform reversible maintenance instead of letting one judgment permanently erase knowledge.

The backup also needs a boundary. Saving only SKILL.md is insufficient when a skill depends on scripts, references, templates, or cron. Backing up an entire server indiscriminately creates the opposite problem: secrets, logs, and unrelated user content enter the recovery artifact. The current manifest records governed files and job definitions. This public account retains aggregate counts but omits server paths, job identifiers, and configuration content.

Pinned is a hard boundary, not a bonus score

Five of the nineteen candidates in this run were pinned. They did not enter a ranking where the model could decide whether they remained important. The rule excluded them before judgment.

That is a deliberate control-plane decision:

• pinned represents an explicit operational or architectural retention choice;
• the curator may report a concern, but it cannot bypass the protection and archive the skill;
• removing a pin is a separate change requiring a person or higher-level policy.

If a pin is only a large score, a model can still sacrifice it while optimizing the whole library. A hard boundary keeps authority outside the model and makes the report easier to audit. Five skips are rule outcomes; fourteen keeps are judgments after reading. They are different evidence classes.

Why this run chose zero changes

The latest report fully read all fourteen unpinned candidates and recorded seventeen tool calls: fourteen skill views, one inventory operation, and two read-only terminal checks. It found no duplicate that could be merged without losing a useful boundary, and no candidate with enough evidence to archive.

The important fact is not that “the model liked everything.” The report left a reviewable reason: the candidates were already umbrella skills for stable task families, and further consolidation would combine different triggers and supporting resources behind larger entry points. The system therefore retained all nineteen agent-created skills and did not present inactivity as an optimization win.

The result also demonstrates the need for a stopping rule. When a full read finds no candidate above the merge or archive threshold, the run should end. Prompt language suggesting that a small archive count may indicate early stopping can trigger another check. It must not become a deletion quota.

Generation is not automatic promotion

Hermes also produces drafts from several agents' trajectories. Recent repeated draft families include Pi, Bridge, and task-profile material. A generated draft does not enter the active library merely because a generator produced it.

This boundary prevents a second form of bloat: packaging one-off behavior as a maintained capability. A draft must demonstrate cross-task reuse, a clear trigger, non-duplication with an umbrella skill, and portable dependencies. Only validation and curation can promote it.

For the upstream candidate-generation path, see the trajectory-mining practice and the SkillOpt–Hermes integration boundary. This article focuses only on lifecycle governance after a candidate exists.

What this practice does not prove

This is one server snapshot from August 8, 2026, not a general benchmark. The 73 active skills, 65 archives, and 43 runs describe the inventory and history at that moment. They do not prove better downstream task quality or that a model will always recognize duplication.

The server implementation is also ahead of its public material. The old hermes-skill-evolution repository is archived, and the controller-harness submodule named by its README is not currently present in the public tree. I therefore do not claim that the complete curator is open source. The public Agent Workspace Reference Architecture is useful for Git-native rules, handover, and recovery boundaries, but it is not a release of this server curator.

The next measurements should not be “how many more files were deleted.” Better signals include recovery time after a mistaken archive, trigger conflicts between duplicate skills, package-integrity failures, real task outcomes after promotion, and the rate at which a person overturns curator decisions.

A trustworthy skill curator must be allowed to inspect everything and do nothing. The value of automation is not a constant stream of diffs. It is a stable contract for authority, evidence, and recovery.