Bug Description

The agent's tool-calling pipeline has a self-inconsistency that makes skills undiscoverable via the primary code path:

1. Model calls skills_list → sees skill name "bar" (from frontmatter name)
2. Model calls skill_view("bar") → "Skill 'bar' not found." (resolves by directory name)
3. Skill is unusable — the agent's own tool chain contradicts itself

This is not just a UX papercut for human users — it's a functional break in the model's skill discovery→loading loop. The bug is silent (no crash, no stack trace), which makes it hard to diagnose: skills_list succeeds, skill_view returns a valid JSON error, and the model either gives up on the skill or hallucinates its contents.

The root cause is a dual-namespace architecture where discovery and resolution use different identifiers:

Slash commands happen to work because scan_skill_commands stores the absolute directory path alongside the frontmatter name, and build_skill_invocation_message resolves via that path — but the opposite direction fails: skill_view called by the directory name works, while skill_view called by the frontmatter name (which is what skills_list reports) does not.

Steps to Reproduce

# 1. Create a skill with diverging names
mkdir -p ~/.hermes/skills/foo
cat > ~/.hermes/skills/foo/SKILL.md << 'EOF'
---
name: bar
description: An agent-facing skill with mismatched identifiers
version: 1.0.0
---
# Bar
This skill is in directory `foo` but declares `name: bar`.
EOF

1. skills_list returns:

   bar — An agent-facing skill with mismatched identifiers   (category: null)

2. The model, acting on this output, calls skill_view("bar"):

   {"success": false, "error": "Skill 'bar' not found."}

3. skill_view("foo") succeeds, but the model never learned the name "foo".

4. Slash commands exhibit asymmetric behavior:

   • /bar → works (command map uses absolute path internally)
   • /foo → not registered (no command key for directory name)

Expected Behavior

The name skills_list returns should be the same name that skill_view accepts. Either:

• skills_list reports the directory name ("foo"), making the file system the single source of truth, or
• skill_view accepts frontmatter names as a fallback when directory lookup fails

Actual Behavior

The agent's own tool outputs contradict each other. The model discovers "bar" but can only load "foo". No warning is emitted. The skill silently becomes a dead entry in the skill list.

Affected Component

• tools/skills_tool.py:588 — _find_all_skills uses frontmatter.get("name", skill_dir.name)
• tools/skills_tool.py:958,973 — skill_view resolves by search_dir / name and parent.name == name
• tools/skills_tool.py:446 — _get_category_from_path returns None for 2-layer paths (foo/SKILL.md), so mismatched skills also lose category attribution
• agent/skill_commands.py:245 — scan_skill_commands uses frontmatter name for command key (slash commands partially work around the bug by storing absolute paths)
• agent/skill_commands.py:280-283 — reload_skills diff uses slash-command snapshot, inherits the inconsistency

Debug Report

N/A — no crash. The bug is a logical inconsistency that propagates silently through the tool-calling loop. The model sees a valid error response from skill_view and has no way to know it should try a different name.

Proposed Fix

Option A (recommended): Make _find_all_skills:588 use skill_dir.name instead of frontmatter.get("name", ...). This makes the directory name the canonical identifier everywhere. The frontmatter name field becomes display-only metadata. One-line change, no fallback overhead, no ambiguity.

Option B: Add a frontmatter-name fallback in skill_view around line 977. When directory-name search fails, iterate SKILL.md files and match fm.get("name"). Preserves backwards compatibility but adds a file-read pass on every miss.

Option C: Validate on discovery that frontmatter name matches directory name; warn or skip mismatched skills. Prevents the problem at install time but requires migration for existing skills.

Operating System

All (cross-platform Python logic). Reproduced on macOS.

Additional Context

Related: #17914 covers the human UX angle of this same bug. This issue focuses on the agent tool-calling impact, which is the more critical failure mode: human users can work around a confusing name, but the model cannot.