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.
omh setup, omh update, and omh doctor.
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 --yesCoding 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.
Prepared handoff is not execution evidence.
Open executor handoff guideHermes 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/v1Memory 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.
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.
Fixed, common-request, and representative local corpora.
Inspectable skill quality bars and handoff policy.
Requires observed plugin or runtime load.
Requires observed external provider evidence.
Requires a recorded served-surface result.
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 --jsonFocused guides
Open detail only when the lane needs it.
Durable goal cycles
Research, plan, handoff, feedback, wait, resume, and completion evidence.
Intent to planClarify before action
Interview, planning, acceptance criteria, and reviewed next steps.
Image generationSource-aware visual contracts
Prompt cards, provider boundaries, and observed artifact evidence.
Product operationsOperate as a system
Roadmap, quality, delivery, reliability, and service-level review.
Executor handoffSelected coding owner
Executor-ready scope without unobserved execution claims.
Architecture at a glanceHermes and OMH boundaries
Memory, skills, tools, gateway surfaces, and evidence.
Repository references