Oh My Hermes

OMH documentation

Start from the decision, not the command.

OMH is the deterministic operating layer between a normal Hermes request and a trustworthy next step. Use this map to install it, choose a capability family, prepare work for the selected runtime, and verify what was actually observed.

Who runs what

People ask. Agents orchestrate.

Normal work starts as a natural-language request to Hermes. People only need the OMH shell for setup, updates, and health checks.

Human default

omh setup, omh update, and omh doctor.

Agent and operator control plane

omh coding, omh runtime, omh chat, omh memory, and related commands are primarily called by Hermes Agent, wrappers, coding agents, automation, and maintainers.

Six capability families

One front door for 82 skills.

Capability families are the public navigation layer. Skill names remain available for precise routing, compatibility, and wrapper rendering.

Install

Two paths, one Hermes-visible result.

Use the local installer for the command and managed setup, or use the Hermes skill tap when that surface is available.

curl -fsSL https://raw.githubusercontent.com/rlaope/oh-my-hermes/main/install.sh | sh omh setup omh doctor hermes skills tap add rlaope/oh-my-hermes hermes skills install rlaope/oh-my-hermes/skills/oh-my-hermes --yes

Coding owner

Prepare the executor, not just the prompt.

OMH keeps coding ownership explicit and executor-neutral. A handoff can include workspace isolation, local skill discovery, acceptance criteria, review expectations, and verification gates.

scopeplan accepted
contextskills and constraints
ownerselected executor
proofruntime observation

Prepared handoff is not execution evidence.

Open executor handoff guide

Hermes Agent Integration Runbook

Render contracts instead of scraping prose.

Hermes owns chat intake and narration. OMH returns deterministic interaction, capability, handoff, progress, and evidence shapes for Discord, Slack, hosted chat, and plugin-native surfaces. These identifiers are for adapters, not commands a chat user must run.

plugin tool: omh_interact chat_response/v1 coding_runtime_handoff/v1 harness_progress/v1 runtime_observation/v1

Memory and external providers

Connect systems without making OMH depend on one vendor.

Project memory remains reviewed and local under .omh/memory/. Wiki, metric, browser, image, video, and connector services sit behind explicit provider boundaries.

Provider-neutral contracts

external_metric_provider accepts provider-shaped operational data for validation and analysis.

External knowledge providers can support wiki workflows while review, provenance, and recall claims stay explicit.

Registered or configured access is not proof that a provider was called.

Capability impact

Use the smallest check that proves the claim.

OMH reports six dimensions independently so a strong local router cannot hide a missing host, provider, artifact check, or comparative evaluator.

01Route selection

Fixed, common-request, and representative local corpora.

02Guidance depth

Inspectable skill quality bars and handoff policy.

03Host availability

Requires observed plugin or runtime load.

04Provider availability

Requires observed external provider evidence.

05Artifact verification

Requires a recorded served-surface result.

06Outcome quality

Requires blinded paired tasks and an external evaluator.

Agent / maintainer reference. Hermes integrations and maintainers use these commands to inspect the contract; normal users ask Hermes about capability or setup health.

omh capabilities summary --json omh capabilities impact omh capabilities impact --json

Focused guides

Open detail only when the lane needs it.

Repository references

Detailed contracts remain the source of truth.