Problem or Use Case
Hermes has a strong self-improvement loop for skills (create / edit / patch), but it does not have an equivalent forgetting / retirement loop.
Today, skills mostly grow monotonically. Over time this creates several problems:
Issue #429 already raises the question of whether Hermes should track skill usage timestamps / counters. This issue proposes turning that into a concrete lifecycle system.
Related: #6051, #429, #1780, #2045, #416
Proposed Solution
Introduce a lightweight lifecycle layer for skills, separate from the SKILL.md content itself.
1. Add sidecar lifecycle metadata
Track operational metadata outside the skill file (for example in a small JSON/SQLite sidecar index keyed by skill path/name), such as:
last_viewed_at (weak signal)last_used_at or last_successful_apply_at (stronger signal)use_countpatch_countlast_patched_atpinnedarchived_at- optional:
negative_claim_confidence / negative_claim_ttl
I would strongly prefer sidecar metadata over rewriting frontmatter on every use:
2. Add lifecycle states
Introduce simple states such as:
active — normal behavior, visible for prompt/catalog usestale — not recently used; hidden from default prompt injection or deprioritizedarchived — excluded by default but recoverable
Important: I would not auto-delete by default. Archival is much safer than deletion.
3. Filter or deprioritize stale skills in prompt construction
When Hermes builds the skills prompt/catalog, stale or archived skills should not be treated the same as active ones.
This helps with:
- reducing prompt clutter from long-tail skills
- lowering the chance that stale guidance keeps influencing the agent
- preserving recovery paths for rarely needed but still useful skills
A pinned skill should remain active regardless of recency.
4. Revalidate negative / environment-dependent claims
A special case is skills that encode negative operational claims such as:
- “browser tools do not work”
- “X command is unavailable”
- “Y setup never succeeds”
These claims are often environment-dependent and may become false later.
For these, Hermes should support a TTL / revalidation mechanism instead of treating them as permanent truths. This directly addresses the failure mode in #6051.
5. Recovery path
Archived or stale skills should be easy to revive:
- explicit user request
- successful reuse
- manual unarchive command
- optional background review that suggests reactivation
6. Configurability
Possible config surface:
skills:
lifecycle:
enabled: true
stale_after_days: 30
archive_after_days: 90
revalidate_negative_claims: true
negative_claim_ttl_days: 14
hide_stale_from_prompt: trueAlternatives Considered
Pure recency/frequency scoring only
Cheap and easy, but too blunt. Some skills are low-frequency but high-value. A pinned mechanism is needed.
Automatic hard deletion
Too risky. Skills should probably move through active -> stale -> archived first, with deletion as an explicit/manual action.
Store counters directly in frontmatter
Simple, but noisy and conflict-prone. It also mixes operational telemetry with human-authored skill content.
Manual cleanup only
This is effectively the current behavior, and it does not scale well as the number of learned skills grows.
Why this matters
Hermes’ self-improvement loop is one of its strongest differentiators. But a learning system that only accumulates and never forgets will eventually collect stale heuristics, prompt clutter, and brittle generalizations.
Memory already has concepts like decay / forgetting. Skills likely need an equivalent lifecycle layer.
Feature Type
Performance / reliability
Scope
Large (new module or significant refactor)
Contribution
Problem or Use Case
Hermes has a strong self-improvement loop for skills (
create/edit/patch), but it does not have an equivalent forgetting / retirement loop.Today, skills mostly grow monotonically. Over time this creates several problems:
Issue #429 already raises the question of whether Hermes should track skill usage timestamps / counters. This issue proposes turning that into a concrete lifecycle system.
Related: #6051, #429, #1780, #2045, #416
Proposed Solution
Introduce a lightweight lifecycle layer for skills, separate from the SKILL.md content itself.
1. Add sidecar lifecycle metadata
Track operational metadata outside the skill file (for example in a small JSON/SQLite sidecar index keyed by skill path/name), such as:
last_viewed_at(weak signal)last_used_atorlast_successful_apply_at(stronger signal)use_countpatch_countlast_patched_atpinnedarchived_atnegative_claim_confidence/negative_claim_ttlI would strongly prefer sidecar metadata over rewriting frontmatter on every use:
2. Add lifecycle states
Introduce simple states such as:
active— normal behavior, visible for prompt/catalog usestale— not recently used; hidden from default prompt injection or deprioritizedarchived— excluded by default but recoverableImportant: I would not auto-delete by default. Archival is much safer than deletion.
3. Filter or deprioritize stale skills in prompt construction
When Hermes builds the skills prompt/catalog, stale or archived skills should not be treated the same as active ones.
This helps with:
A pinned skill should remain active regardless of recency.
4. Revalidate negative / environment-dependent claims
A special case is skills that encode negative operational claims such as:
These claims are often environment-dependent and may become false later.
For these, Hermes should support a TTL / revalidation mechanism instead of treating them as permanent truths. This directly addresses the failure mode in #6051.
5. Recovery path
Archived or stale skills should be easy to revive:
6. Configurability
Possible config surface:
Alternatives Considered
Pure recency/frequency scoring only
Cheap and easy, but too blunt. Some skills are low-frequency but high-value. A
pinnedmechanism is needed.Automatic hard deletion
Too risky. Skills should probably move through
active -> stale -> archivedfirst, with deletion as an explicit/manual action.Store counters directly in frontmatter
Simple, but noisy and conflict-prone. It also mixes operational telemetry with human-authored skill content.
Manual cleanup only
This is effectively the current behavior, and it does not scale well as the number of learned skills grows.
Why this matters
Hermes’ self-improvement loop is one of its strongest differentiators. But a learning system that only accumulates and never forgets will eventually collect stale heuristics, prompt clutter, and brittle generalizations.
Memory already has concepts like decay / forgetting. Skills likely need an equivalent lifecycle layer.
Feature Type
Performance / reliability
Scope
Large (new module or significant refactor)
Contribution