hermes-plugin-authoring

Create a directory ~/.hermes/plugins/<name>/ containing plugin.yaml and __init__.py with a register(ctx) function that calls ctx.register_hook. Flat .py files are never loaded, and you must run hermes plugins enable <name> since user plugins are opt-in.

Hooks load only at session start, so enabling mid-session changes nothing in the current session. Run a fresh hermes chat session and check side effects, using HERMES_PLUGINS_DEBUG=1 to see discovery logs in ~/.hermes/logs/agent.log.

Plugin post_tool_call callbacks receive function_name, function_args, result, session_id, task_id, duration_ms, status, and error fields, but never cwd. The shell-hook spelling tool_name/args is a different surface, so adapters must normalize both.

Return {"context": "..."} from a pre_llm_call callback; it is injected into the user message, never the system prompt. Since post_tool_call has no return channel, stash data keyed by project path and pop it in pre_llm_call.

Yes, the Hermes venv ships the official MCP SDK, so a provider can act as an MCP client over stdio or Streamable HTTP. Implement the MemoryProvider ABC, inject required fields like projectId, and select it via the memory.provider config key.

Only one external memory provider can be active at a time; MemoryManager rejects a second with a warning. Selection happens through the memory.provider config key, and built-in MEMORY.md/USER.md memory always stays active alongside it.