hermes - 💡(How to fix) Fix Feature: Skill Lifecycle Transparency — hermes skills status + diff

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Root Cause

ScenarioCurrent UXWith this FR
After hermes update"3 user-modified" — but what changed?hermes skills status → see exactly which + diff to inspect
Before updating skillsNo way to preview impacthermes skills status shows outdated count
Multi-profile setupSilent crash on name collision (#28126)Conflict state shown proactively
Cleanup old skillsManual filesystem inspectionOrphaned state visible at a glance

Code Example

$ hermes skills status

SKILL                        STATE           LOCAL    UPSTREAM   BUNDLED
hermes-agent                 user-modified   a1b2c3   d4e5f6     d4e5f6
debugging-hermes-tui         up-to-date      g7h8i9   g7h8i9     g7h8i9
system-health                outdated        j0k1l2   m3n4o5     m3n4o5
old-experimental-skill       orphaned        p6q7r8   —          —

4 skills: 1 user-modified, 1 outdated, 1 up-to-date, 1 orphaned

---

$ hermes skills diff hermes-agent

--- local (user-modified, a1b2c3)
+++ upstream/bundled (d4e5f6)
@@ -12,6 +12,8 @@
 ## Pitfalls
+- Always check gateway status before restarting
+- Windows paths need special handling
RAW_BUFFERClick to expand / collapse

Feature Request: hermes skills status — Skill Lifecycle Transparency

Problem

After hermes update syncs bundled skills, users cannot answer basic questions about their local skill state:

  1. Which skills did I modify? The sync summary (after #28121) now shows names, but there is no way to inspect differences between local and upstream versions.
  2. Which skills are outdated? No command compares the local copy against the current bundled version.
  3. Will a sync conflict? Multi-profile setups with external_dirs can experience name collisions (#28126) with no pre-flight warning.
  4. Which skills are deprecated/removed upstream? Skills removed from the bundle silently linger locally.

Proposed Solution

Add a hermes skills status CLI command that reports the lifecycle state of every installed skill, plus a hermes skills diff <name> command for inspection.

hermes skills status

$ hermes skills status

SKILL                        STATE           LOCAL    UPSTREAM   BUNDLED
hermes-agent                 user-modified   a1b2c3   d4e5f6     d4e5f6
debugging-hermes-tui         up-to-date      g7h8i9   g7h8i9     g7h8i9
system-health                outdated        j0k1l2   m3n4o5     m3n4o5
old-experimental-skill       orphaned        p6q7r8   —          —

4 skills: 1 user-modified, 1 outdated, 1 up-to-date, 1 orphaned

States:

  • up-to-date: local matches current bundled version
  • user-modified: local differs from origin hash (user edited it)
  • outdated: local matches origin but bundled has a newer version
  • orphaned: skill exists locally but is no longer in the bundle
  • external: skill loaded from external_dirs (not managed by sync)
  • conflict: skill name exists in both local dir and external_dirs (#28126)

Flags:

  • --json for machine-readable output
  • --show-hash to include full SHA256 hashes

hermes skills diff <name>

$ hermes skills diff hermes-agent

--- local (user-modified, a1b2c3)
+++ upstream/bundled (d4e5f6)
@@ -12,6 +12,8 @@
 ## Pitfalls
+- Always check gateway status before restarting
+- Windows paths need special handling

Diff targets:

  • --against origin: diff against the version that was originally synced
  • --against bundled: diff against the current bundled version (default)
  • --stat: summary only (lines added/removed)

Pre-flight conflict check

When external_dirs is configured, hermes skills status also checks for name collisions between the profile's skill directory and the external dirs. This prevents the crash scenario from #28126 by surfacing conflicts before they hit sync_skills().

Why This Matters

ScenarioCurrent UXWith this FR
After hermes update"3 user-modified" — but what changed?hermes skills status → see exactly which + diff to inspect
Before updating skillsNo way to preview impacthermes skills status shows outdated count
Multi-profile setupSilent crash on name collision (#28126)Conflict state shown proactively
Cleanup old skillsManual filesystem inspectionOrphaned state visible at a glance

Implementation Notes

  • Hash computation already exists in tools/skills_sync.py (_sha256_file())
  • Origin hashes are stored alongside each skill (.origin_hash file)
  • Bundled skill manifest already tracks all bundled skills
  • external_dirs config is available via profile config
  • This is a CLI-only change — no gateway/agent/core modifications needed

Related Issues

  • #28121 — show names of user-modified skills in sync summary (merged via #28206)
  • #28126 — sync_skills crash on external_dirs name collision (fixed via #28187)
  • #18402 — broader "show what changed / offer to reset" (this FR is a concrete CLI tool for that)

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - 💡(How to fix) Fix Feature: Skill Lifecycle Transparency — hermes skills status + diff