feat(agents): add NousResearch Hermes adapter

[rolldav]

Context

gortex install / gortex init auto-configure 15 coding agents, but NousResearch Hermes (https://github.com/NousResearch/hermes-agent) is not among them. Hermes is a CLI agent-orchestrator that consumes MCP servers and is increasingly used as a front-end to Gortex's daemon. Today Hermes users must wire the gortex mcp server by hand and hand-author any usage guidance — there is no adapter, and the binary carries no hermes references.

Hermes specifics (for the adapter)

• Config: ~/.hermes/config.yaml, top-level mcp_servers: (global). Profiles live at ~/.hermes/profiles/<name>/config.yaml and merge the global mcp_servers (verified: a profile's resolved server set includes the global entries). → a single global stanza reaches every profile.
• User-level skills surface: ~/.hermes/skills/**/SKILL.md with YAML frontmatter (name, description, metadata.hermes.tags, category). Hermes therefore has a user-level instructions surface, like Claude Code and Antigravity.
• CLI: hermes (pip console-script).

Proposal

Add internal/agents/hermes/, user mode (same shape as openclaw / antigravity):

• Detect(env) — ~/.hermes/config.yaml present, or hermes on PATH.
• Apply(env, opts) via gortex install — idempotently upsert a global gortex: server into mcp_servers: (command: <gortex>, args: [mcp]). No per-profile writes are needed because profiles merge the global block.
• Tool-usage teaching — because Hermes exposes a user-level skills surface, install one user-level Hermes skill (tool surface + multi-repo scoping via set_active_project/repo/project), mirroring the Claude Code / Antigravity treatment, rather than relying solely on MCP tool descriptions.

Implementation notes

• A MergeYAML helper is required (only MergeJSON / MergeTOML exist today). Hermes config is comment-rich, so a comment-preserving merge is preferable; otherwise a minimal-footprint stanza insert with a .bak sibling on malformed input, consistent with the existing write helpers.
• User mode only — Hermes is not repo-scoped the way IDE adapters are; the daemon's multi-repo workspace + per-query scoping covers multiple repos from one global server.
• Honour the Adapter contract (Name/DocsURL/Detect/Plan/Apply) and the atomic write/backup helpers.

Acceptance

• gortex install detects Hermes and writes the global gortex: MCP entry; gortex init doctor reports it.
• All Hermes profiles resolve the gortex tools without per-profile edits.
• (Optional) a user-level Hermes gortex skill is installed.

Happy to help test against a real ~/.hermes setup.

[zzet]

Hey @rolldav

Happy to help test against a real ~/.hermes setup.

It definitely will be useful. I can implement it in the coming days, and I'd need help with QA.

[rolldav]

Great, count me in for QA. Real setup on my side: gortex v0.35.2+547451f, ~/.hermes/ with ~10 profiles and 2 tracked repos.

A few structural notes to save you time — including one caveat I want to be upfront about.

Detection

• ~/.hermes/config.yaml present, or hermes on PATH (pip console-script).

Config — where to write

• Top-level mcp_servers: map. stdio form (this is verbatim what my config uses for the gortex server):

mcp_servers:
  gortex:
    command: /opt/homebrew/bin/gortex
    args: [mcp]
    connect_timeout: 60
    timeout: 120

• Remote servers use a different shape in this config (url: + headers: with ${ENV} interpolation); gortex is stdio, so the block above is the relevant one.

Per-profile caveat (matters for the adapter design)

• Besides the top-level mcp_servers:, each profile at ~/.hermes/profiles/<name>/config.yaml carries its own mcp_servers: block — in my setup a profile re-declares its servers locally rather than transparently inheriting the global map. There's also an inherit_mcp_toolsets flag, but it governs subagent delegation, not config inheritance.
• So I can't yet confirm that a single global stanza propagates to every profile — that's exactly what I'll pin down during QA. The adapter may need to handle per-profile mcp_servers too. I'll map the precise global↔profile resolution and report back.

Skills surface (optional teaching)

• User-level skills tree: ~/.hermes/skills/<category>/<name>/SKILL.md, YAML frontmatter (name, description, version, metadata.hermes.tags, related_skills). A .skills_prompt_snapshot.json sits alongside and looks like a derived cache, so dropping the SKILL.md should suffice. Since Hermes exposes a user-level instructions surface (like Claude Code / Antigravity), a user-level skill is a good fit.

QA I can run once it lands

• gortex install --agents=hermes --dry-run --json + a real apply, idempotency on re-run.
• The key open question — global entry vs. per-profile writes — verified across my ~10 profiles, with the exact resolution rules reported back.
• Comment/structure preservation (the YAML is comment-rich) + the malformed-input .bak path.

Happy to share a fully sanitized config.yaml + profile skeleton as a fixture. Ping me when there's a branch.