Auto-Archiving

Auto-Archiving — synchronizing, tracing, and safely restoring skills. This is the “silent infrastructure” layer behind everything covered in Reusable Procedures, Community Catalog, Slash Commands, Custom Skills and Improvement During Use: when skills come from many sources (bundled, hub, self-made, agent-written) and change continuously, Hermes needs a mechanism to track who changed what, when, and how to restore things if needed — without silently overwriting your work.

Syncing bundled skills — never overwriting your edits

On every fresh install or hermes update run, Hermes copies the bundled skills from the repo into ~/.hermes/skills/, while recording the original hash of each skill in a .bundled_manifest file. On the next sync, it compares the current hash of your copy with the stored original hash:

• Unchanged → safe to pull the new update, and the new hash is recorded
• Changed (you edited it) → treated as user-modified and skipped forever — never overwritten automatically

This is the point worth emphasizing: this mechanism prioritizes preserving your changes over always having the latest version — a deliberate design choice.

When you want to go back to the original

One situation is easy to hit: you edit a bundled skill, then want to throw it all away and return to the original — but if you just copy-paste by hand from the repo folder, the manifest still holds the old hash, so the next sync will still treat it as “user-modified” and skip it. The solution is to use the reset command instead of copying by hand:

hermes skills reset google-workspace              # remove from the manifest, keep the current copy, re-baseline from here
hermes skills reset google-workspace --restore     # delete the edited copy, take the exact original back from the repo

Keeping provenance traces for hub-installed skills

For every skill installed from the Skills Hub, Hermes records a full trace in skills/.hub/lock.json: source URL, exact content hash, scanner version used, scan results, install time, and fresh-or-cached status. This is not just a technical log — it is audit evidence: if a skill is later found to have a problem, you can look up exactly where it came from and what checks it passed.

In parallel, .hub/audit.log and .hub/quarantine/ retain the scan history and the skills quarantined for dangerous detections — not silently deleted, but kept for review.

Tracking upstream updates over time

hermes skills check       # which skills have a newer version at the source
hermes skills update      # update (only the skills you have not modified)

This mechanism uses the stored source identifier to go compare hashes on its own — you don’t need to remember which skills you installed from where.

Notes

• Never restore a bundled skill by copy-pasting by hand from the repo folder — always use hermes skills reset --restore, otherwise the manifest will drift out of sync and cause confusion at the next sync.
• If you run Hermes for multiple profiles (e.g. one for work, one for personal use), remember that each profile has its own .bundled_manifest — resetting in one profile does not affect the others.
• When you need to prove that a production-running skill passed security checks, skills/.hub/lock.json is the first place to look — treat it as part of your periodic audit routine, not just a log file left sitting there.