oh-my-hermes
CLI Toolrlaope/oh-my-hermes
All-in-one plugin adding memory, skills and governed workflows to Hermes Agent.
Overview
Oh My Hermes is an operating layer for the Hermes Agent coding assistant, bundling long-term project memory, model-optimized workflow packages and native skills. It frames requests into clear capabilities with explicit evidence boundaries, and ships an omh command for setup, updates, model selection and diagnostics.
README Preview
\n \n\n\n# oh-my-hermes\n\n\n English |\n 한국어 |\n 日本語 |\n 中文\n\n\n\n \n \n \n \n\n\n\n \n\n\n\n Install once. Keep Hermes. Add a stronger operating layer.\n \n Planning, research, creation, coding handoffs, operations, and project memory with explicit evidence boundaries.\n\n\n\n \n\n\n\n oh-my-hermes (OMH) turns a normal\n Hermes Agent\n request into a clear capability, a useful next step, and an honest record\n of what actually happened — strengthening the workflow you already use,\n never replacing Hermes or hiding a coding executor behind it.\n \n OMH is the operating layer above Hermes-native skills: it frames the\n problem, picks the workflow and evidence gates, and runs native skills\n as capabilities inside that governed path.\n\n\n[Website](https://rlaope.github.io/oh-my-hermes/) ·\n[Documentation](docs/README.md) ·\n[Installation](docs/INSTALLATION.md) ·\n[Capabilities](docs/CAPABILITIES.md) ·\n[Capability Impact](docs/CAPABILITY_IMPACT.md) ·\n[Agent Install](INSTALL_FOR_AGENTS.md) ·\n[GitHub Pages site](site/index.html)\n\n> [!NOTE]\n> OMH keeps Hermes as the natural-language surface and adds a professional\n> operating layer with explicit evidence boundaries.\n>\n> \n> \n> \n\n> [!TIP]\n> Be with us!\n>\n> \n> \n> \n> Updates for oh-my-hermes are shared on @rlaope on X, alongside release notes and project news.\n> \n> \n> \n> Follow @rlaope on GitHub for more projects, releases, and ongoing work.\n> \n> \n> \n> Join the Oh-My-Hermes Community on Discord to ask questions, share workflows, and talk with other users.\n> \n> \n> \n> Built with AI agents Friren and Killua, collaborators helping ship oh-my-hermes.\n> \n> \n> \n> Thank you to Nous Research for creating Hermes Agent.\n> \n> \n\n\n\n## Quick Start\n\n**macOS / Linux:**\n\n```sh\ncurl -fsSL https://raw.githubusercontent.com/rlaope/oh-my-hermes/main/install.sh | sh\n```\n\n**Windows (PowerShell 5.1+):**\n\n```power
FAQ (5)
TroubleshootingHow to fix 'Creating a junction requires an absolute path for the target' error when running omh update on Windows?
This happens when powershell.exe on PATH resolves to PowerShell 7 instead of Windows PowerShell 5.1. OMH's updater passed a relative path as the junction target, which PowerShell 7 rejects (5.1 tolerated it), so the new generation builds but never activates.
**Permanent fix:** Upgrade to a version containing PR #2218 (merge commit d0df9331a8156b611e3a6bee94465a5b18db45f8), which makes junction creation use an absolute target path, working with both PowerShell 7 and 5.1.
**Workaround for older versions (e.g., 4.0.0):** Temporarily put Windows PowerShell 5.1 first on PATH only for the update:
set PATH=C:\Windows\System32\WindowsPowerShell\v1.0;%PATH%
omh updateThen verify with
omh doctor. No cmd fallback or policy bypass is needed.TroubleshootingWhy are OMH memory records not injected in Slack/Telegram/Discord DM conversations?
Cause: OmhMemoryProvider.initialize() treats every non-CLI platform as a shared surface via self._shared_surface = bool(kwargs.get("shared_surface", bool(platform and platform != "cli"))). On shared surfaces without principal_context, personal and legacy records are excluded (fail-closed per #1485), so 1:1 DM turns never receive reviewed records even when the store holds approved ones. Fix/workaround: patch the provider to treat chat_type == "dm" as non-shared when no explicit shared_surface kwarg is passed:
self._shared_surface = bool(kwargs.get(
"shared_surface",
bool(platform and platform != "cli" and kwargs.get("chat_type") != "dm"),
))Group channels and unknown chat types remain shared and fail closed. If patching a managed bundle, restore the upstream text before each
omh update and re-apply the patch after omh doctor passes.TroubleshootingWhy is the model-family calibration block missing from Hermes delegate_task child system prompts in OMH?
This is a bug in OMH 4.0.0: PR #2178 added the omh.delegation-protocol section for native children but never included the calibration table, and the module that renders it (coding/unit_prompt_assembly.py) is only used by the coding fanout path, not by native delegate_task. Fixed by PR #2215 (commit 8981d6967cec156b2e675fc663a4580f972b98e6) — upgrade OMH to a build containing that merge. After the fix, every native delegate_task child gets a separate omh.child-calibration system-prompt section, with calibration resolved from the child's own model in the order: exact override → model family → generic. Behavior notes: native children receive calibration at all effort levels (Hermes section metadata cannot reliably expose reasoning_effort), while the omh coding fanout path keeps its existing high/xhigh/max effort gate via calibration_entry_for_route. The omh.delegation-protocol section text is unchanged.
TroubleshootingWhy don't Hermes delegate_task children receive the OMH delegation protocol, and how to fix it?
This is a bug in OMH 4.0.0: the plugin's pre_tool_call hook (hooks/tool_hooks.py:128) only adds an unknown-role warning for delegate_task and returns None — it never injects the delegation protocol (goal echo-back, numbered done criteria, verification pass) that the coding-handling harness requires in every delegated prompt. OMH only embeds the protocol in unit prompts it assembles itself (omh/coding/unit_prompt_assembly.py), so Hermes-native delegate_task spawns get it only if the parent model pastes it manually. Workaround (confirmed working): create a local Hermes plugin that registers a system-prompt section whose text is built from the output of omh coding composition-guide --json. The Hermes host carries plugin system-prompt sections into delegate_task child sessions, so every spawned child receives the protocol automatically. Verify by checking the child session's stored system prompt — it should contain the protocol lines, and the child's first user message should be byte-identical to the dispatched goal.
TroubleshootingHow to stop OMH memory consolidation (dreaming) brief from appearing on every turn when using multiplexed profiles sharing ~/.omh?
This is a known bug in OMH 3.0.2: the plugin is a singleton that binds all profiles to the shared ~/.omh store, so memory/dreaming.json and memory/consolidation.json are global. One profile hitting headroom_below_floor writes a brief that render_pack() then injects into every turn of all profiles, and turn-interval/compaction counters are also counted host-wide. There is no supported setting to disable dreaming yet (DREAMING_MODES exists but consolidation_reasons() is always called with the default). Workaround: edit memory_dreaming.py to set DEFAULT_DREAMING_MODE = "off" and force due = False in read_latest_consolidation(). Because this modifies a managed file, you must restore the upstream text before running omh update, run omh doctor to pass plugin_manifest/plugin_bundle_current checks, then re-apply the patch. A proper fix (namespacing dreaming state per profile via profile_slot(hermes_home) hashing, as memory_session_lens.py and todo_store.py already do) is being worked on.