The Skill Curator: Automated Lifecycle Management

The Entropy Problem: Skills Accumulate Faster Than They Get Cleaned Up

The self-improvement loop is designed to create skills. It creates them after successful workflows, after discovering new procedures, after solving errors. Over time, a productive Hermes deployment accumulates dozens or hundreds of agent-created skills. Most of them get used. Some of them become outdated. A few were only relevant to one task and have not been touched since. Without active management, the skill library grows indefinitely — slowly degrading the quality of the Level 0 metadata scan as it fills with obsolete or redundant entries.

The curator is the automated solution. It runs on a configurable schedule and manages the lifecycle of agent-created skills: moving inactive ones to stale, archiving long-unused ones, and — when you choose to enable it — using an auxiliary model to identify consolidation opportunities. The curator's core principle is preservation: it never deletes anything permanently. The worst outcome of curator action is archival, and archival is always recoverable.

Default Configuration

The curator's settings live under the curator: key in config.yaml. The defaults are conservative:

These defaults mean a skill that goes unused for 30 days is flagged as stale, and a skill that goes unused for 90 days is automatically archived. Skills you actively use are never affected — the activity tracking resets on every skill load.

Lifecycle States: Active, Stale, and Archived

Agent-created skills move through three states based on usage activity. The transition triggers are time-based and deterministic — no LLM reasoning is involved in the default pruning pass.

Active: The normal state for a skill that has been used within the stale threshold. Active skills appear in skills_list(), are loaded at Level 1 when relevant, and are available for direct invocation. The vast majority of your skills should be in this state.

Stale: A skill that has not been used for at least stale_after_days (default: 30) without being pinned. Stale skills still appear in skills_list() but are annotated with their stale status. The annotation gives the agent a signal that this procedure may be outdated, without removing it from consideration entirely.

Archived: A skill that has been stale for at least the additional time required to reach archive_after_days (default: 90 days total). Archived skills are moved to ~/.hermes/skills/.archive/ and no longer appear in skills_list(). They do not consume Level 0 metadata budget. They are fully recoverable at any time.

Pinned skills bypass all auto-transitions. Pinning is the mechanism for protecting skills you know you use infrequently but do not want archived — a skill for your annual tax filing procedure, for example, or a skill for a tool you use seasonally.

Pruning vs Consolidation

The curator supports two distinct maintenance passes with very different mechanisms and cost profiles.

Pruning is the default, always-on pass. It is deterministic and LLM-free: skills that exceed the inactivity thresholds move through the lifecycle states automatically. No tokens are spent, no model is invoked, no judgment is applied. This pass runs whenever the curator is enabled, on the configured interval.

Consolidation is the optional, opt-in pass. When consolidate: true is set in config.yaml, the curator spawns an auxiliary model — using the auxiliary.curator model slot — to survey all agent-created skills and identify structural improvements. The consolidation model can read any skill with skill_view, propose merges of overlapping skills into unified procedures, patch skills that have accumulated drift from their original purpose, or archive skills it determines are redundant.

Consolidation defaults to off for good reasons: it costs auxiliary model tokens, it makes opinionated structural decisions about your skill library, and on first run of a large library it can take significant time. Most developers enable it only occasionally — as a quarterly maintenance pass, for example — rather than running it weekly alongside the pruning pass.

The Curator CLI and Slash Commands

The curator provides two interface paths: a CLI for terminal workflows and a slash command for in-chat use.

CLI commands via hermes curator <verb>:

• status — displays last run time, skill counts by state, pinned skills, and the five least-recently-used skills
• run — triggers the curator manually and blocks until completion
• pause / resume — temporarily suspends or re-enables automatic runs
• pin <skill> / unpin <skill> — protect a skill from all auto-transitions or remove that protection
• archive <skill> / restore <skill> — manually move a skill to or from the archive
• prune [--days N] [--yes] [--dry-run] — bulk-archive unpinned skills idle for at least N days
• backup / rollback — snapshot the current skill library and restore from a snapshot

In-chat slash command via /curator [verb]: the same status, run, pin, and archive verbs are available from within a Hermes chat session. This is useful when you want to check curator status or manually pin a skill without leaving the chat interface. The in-chat version has the same behavior as the CLI version — it is not a different system, just a different interface to the same underlying curator.

Safety Guarantees: The Curator Never Auto-Deletes

The most important property of the curator is what it never does: permanently delete skills. The worst outcome of any curator action — whether automatic pruning or manual archive — is that the skill moves to ~/.hermes/skills/.archive/ and disappears from the agent's active skill list.

From the archive, any skill can be restored with hermes curator restore skill-name. The skill returns to active status, its usage tracking resets, and it is immediately available for invocation. Restoration is instant and requires no re-authoring.

This safety guarantee is what makes the curator appropriate for automated operation without per-action user approval. You do not need to review each archival decision the way you review skill writes with the approval gate — the cost of a mistaken archival is trivial, and the recovery path is immediate. The curator is therefore safe to leave running on its default schedule with confidence that it will not destroy anything you need.