OMH adds 103 skill files above Hermes Agent
oh-my-hermes is built for people who already use Hermes Agent and want more structure around it. commit afc334a contains 103 top-level SKILL.md files covering planning, research, coding handoffs, operations, memory, visual work, and 9 ulw- workflows. OMH also adds a terminal activity display, model-category routing, specialist roles, capability toggles, and local records intended to separate a prepared instruction from an observed execution.
This is much larger than the phrase "skill pack" suggests. Our scan found 1,480 files, about 461,267 source lines, and a 65.4 MB checkout. The README says 120-plus installable workflow skills, while the capability-toggle document says 102 and the checked tree has 103 top-level skill definitions. Some counts may include generated or packaged surfaces, but the documentation does not reconcile them. Audit the installed catalog rather than choosing by the headline number.
Setup writes skills, plugin registration, TUI and routing state
Users can install the omh command through Homebrew, Bun, npm, a shell installer, or PowerShell, then run omh setup. Python 3.11 or newer is required by the package. Setup installs managed skills, registers and enables an OMH plugin in Hermes, installs a terminal widget, and seeds routing data under ~/.omh. The default profile is full; --core keeps the health floor and a smaller set of chat, plan, status, and handoff skills.
That process is reversible, but it is still a meaningful configuration change. omh doctor checks registration, and the documentation tells users to restart or reload Hermes afterward. The capability policy can disable 6 families without uninstalling the plugin, while omh uninstall --all is the full removal path. Model setup separates preview from apply and asks for approval before alias changes. Provider credentials stay with Hermes or the chosen executor rather than in OMH's routing files.
What happened when we ran it
Our sandbox installed 36 packages in 42 seconds and used 37 MB on disk. The build completed in 12 seconds. Pip-audit found 0 known vulnerabilities in the installed Python dependencies. The repository had 4 CI workflow files and a tests directory, though no Dockerfile. Those results show that packaging works in a fresh Python 3.12 Debian container without secrets.
The test suite did not finish. It hit our 900-second cap after displaying 34% progress. The log showed several failure markers around 23% and 24%, then many passing markers as execution continued through 34%. There was no final summary, so we cannot give a test count or identify a cause from the supplied tail. A timed-out suite with visible failures is a failed evaluation, not a nearly passing one.
Four evidence labels are the best reason to try it
OMH's clearest idea is its status ladder. The README distinguishes Plan · not run, Code · running, Code · reported done, and Test · verified. That vocabulary addresses a common agent problem: a generated plan, a child agent's success claim, and a checked result often collapse into the same word. OMH's contracts preserve the actor and evidence class so a wrapper can show what was prepared, observed, reported, or independently verified.
Coding ownership follows the same boundary. Hermes keeps chat, clarification, research, planning, and status continuity. OMH prepares contracts and local evidence records. Claude Code, Codex, or another selected runtime owns implementation and verification. The separation makes sense for consequential repository work, provided the wrapper really observes the runtime. A polished handoff remains Plan · not run until dispatch happens, and a child saying done does not become Test · verified without a gate.
Installed skills are not yet proven loaded by Hermes
Open issue 1118 names an important blind spot. Byte-exact generated files can prove that setup wrote the intended skill content, but they cannot prove Hermes loaded every file or honored it. The issue says scheduled execution can skip an empty, invalid, or failed skill while continuing with a warning. Its proposed probe is still open, so operators need an end-to-end check for each workflow they intend to rely on.
Model routing has a similar boundary. The shipped chains are editorial recommendations filtered through models the user confirms as active; they do not prove entitlement, credentials, quota, or dispatch. Issue 1056 says 4 newer model-family calibrations still need a paid-live benchmark. OMH is unusually direct about those limits in its docs. Buyers should preserve that honesty in their own UI and avoid turning a configured alias into a claim that a provider accepted or ran it.
Version 2.0.0 shipped without a matching changelog entry
GitHub recorded 1,271 stars, 123 forks, and 3 open issues when fetched. The last push was August 29, 2026, the same date as release v2.0.0. Current issue activity covers paid-live calibration, skill-load observation, and terminal metrics. That is healthy attention for a project created on June 3, but it is also a very fast expansion into a large control layer.
The v2.0.0 release note only points to the release pull request, while the checked CHANGELOG.md stops at v1.0.6. A user cannot learn the v2 migration or behavioral changes from the release page and changelog alone. Combined with our 900-second incomplete suite, that gap argues for a disposable Hermes profile and the core install first. OMH has thoughtful evidence semantics, but the proof needed for unattended use is not complete at commit afc334a.