Hermes Feature Education

Hermes Feature Education

Guide users through Hermes Agent's capabilities — from the features they already use to the ones they've never seen. This is onboarding and feature discovery, not configuration or setup (those go in hermes-agent skill).

Identity

Educator.Discoverer. Start where the user is: assess what they know, then reveal what they don't. Structured, categorized, depth-progressive. Never dump everything at once — give an overview, then dig deeper where they ask.

Core Principles

1. Start with version context — hermes --version tells you what's available
2. Categorize features — users absorb structured information faster than flat lists
3. Depth progression — overview first, then deep dive on request ("go more in depth on...")
4. Prefer show-don't-tell — show actual tool output (hermes lsp status, eikon_list, hermes sessions stats) rather than describing capabilities
5. End with actionable recommendations — "Try X first, then Y, then Z"

Feature Categories

Organize Hermes capabilities into these buckets when educating:

A. Session & Chat Control (slash commands)

• /new, /retry, /undo (basic)
• /compress, /rollback, /background, /queue, /resume (power user)
• /model, /personality, /reasoning, /voice, /yolo, /skin (config on the fly)
• /branch, /fast, /insights (utility)

B. CLI Commands (outside session)

• hermes chat -q — one-shot queries
• hermes config, hermes model — config
• hermes setup — interactive wizards
• hermes doctor, hermes status — health
• hermes sessions — list, browse, prune, stats
• hermes cron — scheduled tasks
• hermes webhook — HTTP callbacks
• hermes acp — ACP server (IDE integration)

C. Tools & Capabilities (in-session toolset)

• delegate_task — background subagents
• cronjob — schedule recurring tasks
• execute_code — sandboxed Python
• vision_analyze, image_generate, text_to_speech
• memory / mnemosyne_* — persistent memory
• skill_manage / skill_view / skills_list
• Web search, browser, file tools

D. Gateway & Messaging

• Supported platforms: Telegram, Discord, Slack, WhatsApp, Signal, Email, SMS, Matrix, Mattermost, DingTalk, Feishu, WeCom, Weixin, BlueBubbles, Home Assistant, Teams, Google Chat (20+)
• hermes gateway run/start/stop/status/setup
• /approve, /deny, /sethome, /platforms — gateway slash commands

E. Profiles

• hermes profile list/create/use/delete/rename/export/import
• Per-profile isolation: config, sessions, memory, skills, auth
• hermes auth add/list/remove — credential pools per profile

F. Advanced Features (most likely unknown)

• LSP (Language Server Protocol) — semantic diagnostics on every write
• Eikons — animated ASCII art TUI avatars
• ACP (Agent Communication Protocol) — interop with Copilot/Codex/Claude Code
• Webhooks — HTTP POST listeners on the gateway
• Session checkpoints — workspace rollback with /rollback
• Credential pools — multiple API keys per provider, auto-rotation
• MCP (Model Context Protocol) — external server integration
• NO_AGENT cron — script-only scheduled jobs, zero LLM cost
• SOUL.md — identity/personality file loaded from HERMES_HOME/SOUL.md only
• AGENTS.md — project context files with progressive subdirectory discovery
• Personalities — 15+ built-in + custom via config
• Context files — .hermes.md, AGENTS.md, CLAUDE.md, .cursorrules auto-detection
• Default profile — hermes profile use <name> sets which profile loads on bare hermes

SOUL.md Architecture (common confusion)

This is the most common conceptual gap. Clarify it explicitly:

Default / No Profile

• HERMES_HOME = ~/.hermes/
• Loads ~/.hermes/SOUL.md
• This is the "root" identity — used when no -p flag or hermes profile use default

Profile Active (e.g. hermes -p senna)

• _apply_profile_override() sets HERMES_HOME = ~/.hermes/profiles/senna/
• load_soul_md() reads from $HERMES_HOME/SOUL.md → resolves to ~/.hermes/profiles/senna/SOUL.md
• Per-profile SOUL.md IS auto-loaded — the profile directory's SOUL.md becomes the identity

Both Levels Coexist

• ~/.hermes/SOUL.md — identity when running as default profile
• ~/.hermes/profiles/<name>/SOUL.md — identity when that profile is active
• They are separate files in separate directories. Same content is coincidence, not coupling.

Impact of Missing SOUL.md

If $HERMES_HOME/SOUL.md doesn't exist, Hermes falls back to the built-in default identity ("You are Hermes Agent, an intelligent AI assistant..."). This means:

• A profile without a SOUL.md will use the fallback identity
• hermes profile create auto-seeds a template SOUL.md to prevent this

Plugin Systems (common confusion)

Hermes has TWO plugin systems; users routinely conflate them. A user saying "I have plugins installed" almost always means AGENT plugins — check ~/.hermes/desktop-plugins/ before claiming any desktop plugins exist.

Full taxonomy + ground-truth inventory workflow: references/plugin-systems-and-inventory.md

When the user asks which of THEIR plugins could become desktop surfaces (or "what can I see on desktop"), run the conversion audit: references/desktop-plugin-conversion-audit.md — the two data doors (ctx.rest vs host.request), the bundled-Kanban finding (desktop app ships one, off by default — never rebuild it from kanban-api), and the tiered fleet assessment. Lead with surfaces that SHOW things (user is visual-first).

Discovery Workflow

Step 1 — Establish baseline

hermes --version

This tells you what version they're on and what features exist.

Step 2 — Check what they already use

Ask or infer from context. In this session the user said "i honestly dont use alot of the features" — wide-open education.

Step 3 — Categorized overview

Present the categories above. List features under each, one line per feature. Use emoji prefixes for scannability.

Step 4 — Deep dive on request

When the user says "go more in depth on X", do:

1. Load relevant reference file if it exists (references/hermes-feature-catalog.md)
2. Show real tool output (hermes lsp status, hermes sessions stats, eikon_list)
3. Explain what it is, how it works, and what they gain from using it
4. Offer to set it up or walk through it right now

Step 5 — Recommend next actions

Pick 3-5 concrete things they should try now. Order by immediate value:

• Session prune if they have 500+ sessions (reclaims disk)
• SOUL.md if they haven't customized it
• LSP if they write code
• Cron if they have recurring tasks
• Eikons for fun/cosmetic

Pitfalls

• Don't dump everything at once — categorize and let the user pick depth
• Don't describe capabilities without showing real output — run the actual commands
• Don't skip version context — features that exist in latest may not be in their install
• Don't conflate "new" with "unknown" — a feature may have existed for releases but the user just never used it
• Don't assume they know CLI from slash commands — explain the difference
• Bundled skills vs installed skills — hermes-agent is bundled/protected; user-created skills are editable
• Slash commands work in both CLI and gateway — but some are CLI-only (marked in reference)

Reference Files

• references/hermes-feature-catalog.md — full feature catalog for deep-dive education
• references/plugin-systems-and-inventory.md — agent vs desktop plugin taxonomy + inventory workflow (config allow-list is ground truth)
• references/desktop-plugin-conversion-audit.md — which installed agent plugins can become desktop surfaces (data doors, bundled-Kanban finding, tiered fleet assessment)
• references/hermes-skill-ecosystem.md — skill sourcing model: builtin vs created vs installed, cross-machine profile replication

Related Skills

• hermes-agent — configuration, setup, providers, tools (loaded when the user asks to configure, not when they ask to learn)
• hermes-version-summary — what's new / release notes
• hermes-soul-authoring — writing SOUL.md
• hermes-skin-authoring — TUI skins
• hermes-image-generation — image gen setup