Problem

hermes skills inspect <local-skill-name> returns "No skill named X found in any source" for skills that are correctly installed locally, listed in hermes skills list as enabled, and parseable by Hermes's runtime resolver. The CLI command appears to query only hub/registry sources, ignoring local on-disk skills entirely — but the error message gives no hint of this distinction and reads as if the skill simply does not exist.

This bites every user who follows instructions to "verify your skill installation with hermes skills inspect <name>" — they get told their skill isn't there even when it's working.

Repro

On any Hermes install with a local skill (built-in or user-installed at ~/.hermes/skills/<name>/SKILL.md):

$ hermes skills list | grep dogfood
│ dogfood                 │                      │ builtin │ builtin │ enabled │

$ hermes skills inspect dogfood
Resolving 'dogfood'...
No exact match for 'dogfood'. Did you mean one of these?
  adversarial-ux-test — official/dogfood/adversarial-ux-test
  browse — garrytan/gstack/browse

Affected on a fresh install:

• dogfood (built-in local) → fails
• gifs (built-in local) → fails
• findmy (canonical-format local skill) → "Error: No skill named 'findmy' found in any source."
• Any user-installed local skill (e.g. one created at ~/.hermes/skills/<name>/SKILL.md with canonical frontmatter) → same failure

Also confusingly: the error message differs slightly between cases. For some skills it offers fuzzy "did you mean" suggestions; for others it returns a flat "not found." Same underlying failure, different copy.

Expected behavior

Either:

A. Extend inspect to handle local skills. Look up the skill from local ~/.hermes/skills/ first, then fall back to hub registries. Print the same details (frontmatter, body, source, status) regardless of source.

B. Keep inspect hub-only but make the error explicit. Replace the current confusing "not found" message with something like:

'gbrain-operations' is installed locally but `inspect` only queries hub registries.
For local skill details, use `hermes skills view <name>` (or the agent-internal `skill_view` tool).

Better still, surface a hint in hermes skills inspect --help: "Searches hub registries only. For installed local skills, use [whatever]."

Why it matters

The current behavior actively misleads users and agent-driven setup flows. When an LLM agent is told to "verify your skill with hermes skills inspect <name>" (a reasonable inference from the existing hermes skills CLI surface), it gets back "not found" — and then either reports the install as failed when it actually succeeded, or hallucinates a new explanation for why "not found" is fine. We hit exactly this failure mode today.

Diagnostic detail

The CLI lists inspect alongside browse, search, install, audit, uninstall, update, check, publish, etc. — clearly a hub-management family. But list is also in that family and does show local skills. The inconsistency between list (local-aware) and inspect (hub-only) is what makes this surprising.

Affected versions

Hermes 0.13.0 confirmed. Likely older.

Severity

UX bug. Doesn't break functionality (local skills load and trigger correctly via the runtime resolver), but actively misleads anyone trying to verify a skill installation through the documented CLI surface. High-impact for agent-driven setup flows where verification output is taken at face value.