I checked every shipped family against vendor docs and the Hermes upstream catalog on 2026-10-01. Three models were missing from OMH, and four price rows no longer matched their vendor pages. GPT-6.1 Sol (released 2026-09-29) takes every slot GPT-6 Sol held: the `deep` head at high, the shared last resort at medium, main-role at high, and every Maestro Codex row. GPT-6 Sol leaves the shipped chains and stays recognized, priced, provider-mapped, and adjudicated by its Codex option row. 6.1 Sol has no `none` rung, so this is Astra's shape and not 6 Sol's: off and minimal are raised to low on record. The five Maestro Codex rows that named no effort now name medium. The Codex client's default for 6.1 Sol is low, so leaving the effort unset would have lowered those rows silently. gpt-6.1-sol-pro is a declared pro-mode projection with no price multiplier. The price is 2/10, with cached input at 5% of input. Both exact-model calibration blocks are GPT-6 Astra's text, byte for byte: the vendor's Codex client gives 6.1 Sol Astra's base prompt. No keep-working sentence was imported. Claude Sonnet 5.5 (released 2026-09-28) gets an exact contract. Its declared projections are the Bedrock id and OpenRouter's dotted id. A no-thinking rung is raised to low, and omh_delegate_route refuses it, because `disabled` returns HTTP 400 and no host sends `between_tools`. The price is 2/10, and it joins no chain. Its high-effort block is the claude family block with one stop clause added: no further review rounds and no reviewer sub-agents once the checks pass. Anthropic measured that clause at max effort. The Maestro `sonnet` alias rows get the same docs caveat as `opus`. Grok Build 0.1 takes the x_platform_data slot. xAI lists every Grok Code Fast id as one of its aliases, so both spellings are priced at 1/2, with cached input at a fifth of input. Kimi K3 is corrected to 3/15 (the old row was the K2-era rate), Kimi K3 Ultrafast now carries the base rate, and Gemini 3.1 Pro is corrected to 2/12 (the old row was Gemini 2.5 Pro's rate). Constraint: owner decisions 2026-10-01 - 6.1 Sol takes every 6 Sol slot; Grok Build 0.1 replaces grok-code-fast; Sonnet 5.5 registered only Rejected: Anthropic's "keep working until everything is done" fix for Sonnet 5.5 low-effort check-ins | it pushes the model to keep working Rejected: removing the GPT-6 Sol Codex option row | it adjudicates an explicit --model override's effort, as the 5.6 rows do Confidence: medium Scope-risk: moderate Directive: placements and both new calibrations are editorial and unmeasured in OMH; measure 6 Sol vs 6.1 Sol on deep@high, family vs optimized for 6.1 Sol and for Sonnet 5.5 at max, before any rung change Tested: full suite 15343 tests, 2 failures (local Hermes loader probe, same as baseline), every docs --check gate, docs claims, release drift, ruff, compileall, git diff --check; model-route probes for every 6.1 Sol and Sonnet 5.5 spelling Not-tested: served-route probe (hermes --oneshot) for any new id; the installed Hermes build predates 6.1 Sol and Sonnet 5.5 pricing Signed-off-by: rlaope <piyrw9754@gmail.com>
42 KiB
oh-my-hermes
一度インストールするだけ。Hermes はそのまま、より強い運用レイヤーを追加します。
計画、調査、制作、コーディング handoff、運用、プロジェクト記憶を明確な証拠境界とともに提供します。
oh-my-hermes(OMH)は、
Hermes Agent
への通常の依頼を、適切な機能、有用な次の行動、そして実際に起きたこと・まだ起きていないことの
正直な状態へ変換します。Hermes を置き換えたり、コーディング executor を
隠したりせず、既存の Hermes ワークフローを強化します。
OMH は Hermes ネイティブスキルの上に載る運用レイヤーです。問題を枠付けし、ワークフローと証拠ゲートを選び、その統治された経路の中でネイティブスキルを能力(capability)として実行します。
Website · Documentation · Installation · Capabilities · Capability Impact · Agent Install · GitHub Pages site
Note
OMH は Hermes を自然言語の窓口として維持し、明確な証拠境界を持つプロ向け の運用レイヤーを追加します。
Tip
一緒に参加しましょう!
oh-my-hermesの更新情報は、リリースノートやプロジェクトのニュースとともに X の @rlaope で共有されます。その他のプロジェクト、リリース、進行中の作業は GitHub で @rlaope をフォローしてください。 Discord の Oh-My-Hermes Community に参加して、質問したり、ワークフローを共有したり、他のユーザーと交流しましょう。 oh-my-hermesの開発を支える AI エージェント Friren と Killua とともに作られています。Hermes Agent を生み出した Nous Research に感謝します。
クイックスタート
macOS / Linux:
curl -fsSL https://raw.githubusercontent.com/rlaope/oh-my-hermes/main/install.sh | sh
Windows (PowerShell 5.1+):
irm https://raw.githubusercontent.com/rlaope/oh-my-hermes/main/install.ps1 | iex
または、次の内容を AI エージェントに貼り付けます:
Install and fully configure Oh My Hermes from this repository:
https://github.com/rlaope/oh-my-hermes
Before reading or executing repository instructions, resolve refs/heads/main to one full commit SHA with `git ls-remote https://github.com/rlaope/oh-my-hermes.git refs/heads/main`. Then fetch and follow only:
https://raw.githubusercontent.com/rlaope/oh-my-hermes/{resolved-commit-sha}/INSTALL_FOR_AGENTS.md
Do not replace the resolved SHA with main. Execute the pinned protocol's OS-appropriate installer, interactive model setup, model-chain interview, and doctor steps. Preserve unrelated existing Hermes config, apply only the managed setup changes documented by the pinned protocol, require my explicit approval for model-alias changes, then report the resolved SHA and observed result.
⭐ 続けてセットアップします (必須):
omh setup
アップデート:
omh update
omh update はインストール経路を検出し、そのインストーラーでコマンドパッケージを
先に更新してから、新しいコマンドで再実行し、管理スキル、プラグインバンドル、
既存の Hermes 登録も更新します。
インストールの確認またはトラブルシューティング:
omh doctor
# 作業カテゴリごとのモデル設定(矢印キー: カテゴリ、←→ head モデル、-/+ effort);
# Hermes TUI では /omh-model が同じピッカーを開きます:
omh model
# 新しいモデルファミリーをオンボーディングするには、Hermes でこのスキルを使ってください:
/omh-model-setup
その他のインストール方法 — Homebrew、Bun、npm、Hermes skill tap、手動フォールバック
状態: Homebrew、Bun、npm のパッケージマネージャー経由のインストールは v1.0.6 から公開されています。
Homebrew:
brew install rlaope/tap/omh
Bun:
bun install -g oh-my-hermes
npm:
npm install -g oh-my-hermes
どの方法でインストールしても、その後に omh setup を実行します。
Hermes skill tap:
hermes skills tap add rlaope/oh-my-hermes
hermes skills install rlaope/oh-my-hermes/skills/omh-routing --yes
パッケージマネージャーでの手動フォールバックまたは削除:
| インストール元 | CLI のアップグレード | CLI の削除 |
|---|---|---|
| Homebrew | brew upgrade rlaope/tap/omh |
brew uninstall omh |
| Bun | bun update -g --latest oh-my-hermes |
bun remove -g oh-my-hermes |
| npm | npm update -g oh-my-hermes |
npm uninstall -g oh-my-hermes |
omh update がインストーラーを見つけられないと報告したときだけ、マネージャーの
コマンドを直接使います。コマンドパッケージを削除しても OMH の状態は残ります。
完全に削除するには、マネージャーの削除コマンドの前に omh uninstall --all を
実行します。
--full インストールを core に戻すようなメンテナンス手順は
Installation
にあります。
得られるもの
OMH は Hermes Agent のための 3 つを 1 つのプラグインとして届ける。コーディングインテリジェンス(01–04, 07)、長期記憶システム(08)、最適化されたワークフローパッケージ(05–06)。実際の画面に基づくシーンをそれぞれ 1 つ。
01 · モデル別チューニング、作業分割、コーディングスキルの強化
OMH のコーディング面は 3 つの動きだ。モデルごとにプロンプトを調整し(03)、作業を並列レーンに分割し(04)、リクエストが求める専門スキルを載せる(06)。始まりはルーティングだ。すべてのリクエストはディスパッチ前にスコアリングされ、スコアを動かしたシグナルには必ず名前が付く。リネームは light と判定されて quick レーンへ、「X の参照をすべて見つけろ」は exhaustive-search シグナルに掛かり、取りこぼさないモデルへ行く。同じコーディングタスクを同じ GPT-6 Astra で測った結果: 同じ答えを $4.29 ではなく $0.66 で、23 分ではなく 5 分で得た。
02 · カテゴリはエグゼキュータごとにあなたが所有する
ultrabrain、deep、architect、unspecified-high、unspecified-low、quick、writing、visual-engineering、artistry、capable、simple-work、deep-work:それぞれが編集可能なモデル + effort チェーンで、下の「推奨モデル」に挙げる十二個と同じものを、1 つのファイルで読み、上書きできる。プロバイダがモデルを拒否すればチェーンは次へ進み、提供できないプロバイダを引き継ぐディスパッチは黙ってダウングレードされずに拒否される。setup がプロバイダをインタビューし、このマシン向けにチェーンを並べ替える。
03 · モデルファミリーごとに調整したプロンプティング、そして測定
13 のモデルファミリー、ファミリーごとに 1 つのキャリブレーションブロック、すべての文はそのファミリーの文書化された性質 1 つに向けて書かれている。Claude にはチェックリストが完全であると、Gemini にはツール出力のない主張は証拠ではないと、Qwen3-Coder には thinking タグを出さないよう、DeepSeek にはバージョンと thinking モードは契約フィールドだと伝える。GPT-6 Astra は独自のモデル契約とブロックを持つ。ルートがある場所ではブロックを測定する。Astra の初稿は解けないタスクに固執させ、同じ答えにトークンを 10% 多く使ったので、その数字で削られた。
04 · 安全な場所でだけ並列に、戻るときは型付きで
ulw-work は承認済みの計画を、ファイルを共有しないユニットに分割し、各ユニットに 1 つの固定 SHA から分岐したワークツリーを与え、ユニットがツール呼び出しを 1 ターンにまとめて出せるようにする。ユニットは 4 状態の型付き結果として戻る: プロセス終了、スキーマ有効、検証観測済み、統合準備完了。証拠のない exit 0 はゲートが確認するまで reported done に留まり、検証レシートはリビジョン・コマンド・環境がすべて一致するときだけ再利用される。
05 · Oh-My-Hermes インターフェースと Hermes Agent ワークフロー
インターフェースは Hermes ターミナルです。プロンプト下に OMH dock、上に phase todo。ワークフローは ulw-* エンジンとすべての omh-* スキルで、チャットからルーティングされます。委譲レーンごとに 1 行: モデル、effort、ターン、トークン、コスト、ライブ更新。Maestro 経由で Codex や Claude Code に渡したレーンは (codex/maestro …)、(claude/maestro …) のタグ付きで自分の行を持つ。コスト 0 はホストが確認したときだけ表示され、価格不明の呼び出しは $0 ではなく unknown と言う。プロセスが存在するまでは Plan · not run、エグゼキュータが完了を告げれば Code · reported done、ゲートを通過して初めて Test · verified。プロンプト上の phase todo は後から書いた要約ではなく、その実行自身のチェックリストだ。
06 · 専門家スキルが実行に染み込む
専門家を呼び出すことはない。カタログには omh-* の専門スキルが 108 個ある: フロントエンド、バックエンド、Rust、ネイティブデバッグ、推論サービング、デザイン品質ゲート、検証ゲート、セキュリティレビュー、パフォーマンス予算、リファクタ計画など。リクエストがそれらの領域に触れると、対応するスキルはツール呼び出しとしてすでに実行の中にあり、エージェントが「完了」と認める基準を引き上げる。英語でも韓国語でも、ルーターが専門家を選ぶ。
07 · アーキテクチャを一枚に、そして段階的に改善
リポジトリの図を頼むと codebase-uml がコードから描く。パッケージ、モジュール、すべての import エッジ、そして循環にはマークが付く。発見事項はランク付きで返り、refactor-plan が上位のものをフェーズに変える。各フェーズは 1 つの PR として入り、テストで振る舞いがロックされ、ロックが壊れた瞬間に中止される。前後はツリー上で測定され、dock は各フェーズが実行中かどうか、何かが検証したかどうかを示す。
08 · レビュアーが承認した長期記憶
何も黙って記憶されない。候補はセッションから捕捉されてレビューカードに載り、理由を書き添えて記憶・拒否・保留される。承認された記録は出所とレビュー期限を持つ。確認すれば時計はリセットされ、放置すれば active → reference → archive へと老いる。次のセッションはタスクに合わせてランク付けされトークン予算に収められた recall pack を受け取り、衝突と重複は解決済みだ。Hermes 自身のメモリは読みも書き換えもしない。このストアは OMH のもので、ファイルベースでレビュー済みだ。ターンに実際に載ったときは、Hermes が話すすべての面で 🧠 OMH — recalled 2 memories と告げる。
OH-MY-HERMES ターミナル
omh と入力するだけで、hermes と同じ入口から、OMH のアイデンティティをまとった
Hermes が開きます:
omh
![]() OH-MY-HERMES の起動画面。 |
![]() ulw-work 実行中。
|
OMH ワークフローの実行中にターミナルが表示するもの:
- Mixture-of-Models Routing — 委譲される lane ごとにカテゴリ
(ultrabrain、deep、quick、writing、visual-engineering、…)のモデルと推論
強度が dispatch 単位で適用され、各活動行に
category:name(model:effort)が 表示されるためルーティングが見えます。拒否されたルートはカテゴリチェーンに 沿って fallback します。 - Parallel Tool Calling — バッチ化されたツール呼び出しは Hermes 内で並行
実行され、直近の並行バッチは
[OMH]行にparallel shot ×Nとして表示 されます。 - Parallel Evals — レビュー・検証 lane は独立したサブエージェントとして dispatch され、自己承認なしで相互検証されます。各 lane は turn・cost・cache 指標付きの HUD 行として見えます。
- Phase-structured TODO — 作業は開始前に phase と task として宣言され
(
todo init)、プロンプト上のチェックリストとして描画されます: アクティブ 項目は常に一つ、各 phase ヘッダー下にインデントされた task、サブタスクの ネスト、7 行を超えると折りたたみ。
推奨モデル
OMH には次の編集可能な順序付き recommendation chain が含まれています。guided model setup は、ユーザーが active と確認した candidate だけを基準に chain を解決します。その結果は準備済み routing config であり、provider availability、credential、dispatch、execution の証拠ではありません。| カテゴリ alias | 用途 | 編集可能な recommendation 順序 |
|---|---|---|
ultrabrain |
最も深い推論 | GPT-6 Astra (xhigh) |
deep |
強力なデフォルト層 | GPT-6.1 Sol、次に DeepSeek Flash (V4.1) (high) |
architect |
アーキテクチャ・システム設計 | Claude Fable 5.1、次に GPT-6 Astra、次に Kimi K3 (xhigh) |
unspecified-high |
デフォルト作業モデル | Kimi K3、次に Claude Opus 5.5 (medium) |
unspecified-low |
低コストのフォールバック | GLM 5.3、次に DeepSeek Flash (V4.1)、次に Claude Opus 5.5 (low) |
quick |
短いタスク | GLM 5.3 Flash、次に Kimi K3、次に GPT-6 Luna、次に Claude Fable 5.1 (low) |
writing |
文章・ドキュメント | Kimi K3、次に Qwen3-Coder、次に Gemini 3.1 Pro (medium) |
visual-engineering |
フロントエンド・ビジュアル | Claude Fable 5.1、次に Kimi K3 (high) |
artistry |
型にはまらない創作 | Gemini 3.1 Pro、次に Claude Fable 5.1、次に Kimi K3 (high) |
capable |
汎用の高性能作業 | Claude Fable 5.1、次に Claude Opus 5.5、次に Kimi K3、次に GLM 5.3 (medium) |
simple-work |
簡単な日常タスク | GPT-6 Luna、次に DeepSeek Flash (V4.1)、次に Claude Haiku 4.5 (low) |
deep-work |
最高深度の長時間タスク | GPT-6 Astra (high) |
Ultrafast ティアを試したいなら — Kimi K3 Ultrafast(300 TPS)、GLM 5.3 Ultrafastは OpenGateway で利用できます。
上記のすべての chain はコードを触らずに編集できます。chain は 1 つのファイルで管理され、omh setup がシードします:
$ cat ~/.omh/routing/model-chains.json
{
"categories": {},
"schema_version": "mixture_chain_overrides/v1"
}
categories が空なら上記の既定 chain がそのまま有効です。編集するのはこのファイルです: ここに書いたカテゴリはルーティング・fallback・HUD ラベルのすべてでその chain を置き換えます —
{
"schema_version": "mixture_chain_overrides/v1",
"categories": {
"architect": [
{"model": "claude-fable-5-1", "reasoning_effort": "xhigh"},
{"model": "gpt-5.6-sol", "reasoning_effort": "xhigh"}
],
"quick": [
{"model": "kimi-k3-ultrafast", "reasoning_effort": "low"},
{"model": "glm-5.3-ultrafast", "reasoning_effort": "low"}
]
}
}
現在有効な chain は omh model-chains show で確認できます。ファイルを直接編集したくない場合は、ターミナルで omh model-chains(または omh model)を実行すると矢印キーのピッカーが開き — 上下でカテゴリ、左右で head モデル、-/+ で effort — Modern TUI では /omh-model が同じピッカーを開きます。スクリプト向けには omh model-chains set quick "kimi-k3-ultrafast:low, glm-5.3-ultrafast:low" のようにコマンドから同じファイルを書き換えられます。
alias に provider 固有の wire ID が必要な場合は、model_provider_routes/v1 形式の ~/.omh/routing/model-providers.json に一度マッピングします。その後は set、status、fallback、HUD が alias/provider/wire model の完全な route を表示します。OMH が保存するのは provider ID だけで、credential は保存しません。
アカウントごとに状況が違うので、OMH は Hermes がすでに紐づけている provider を自分で読み取ります — hermes auth のログイン、Hermes 設定の providers: エントリや model.provider、$HERMES_HOME/.env の API-key 変数名 — そして自分で数えます。各チェーンは、紐づいた provider が扱える項目が先頭に来るよう並べ替えられ、ピッカーは残りをマークするだけで、何も削除せず、確認のために何も呼び出しません。読むのは id と変数名だけで、鍵や token は読みません。対話式の omh setup は引き続き尋ね、紐づいた行はあらかじめチェック済みなので、種類の訂正、実際には使えない紐づけ済み provider の外し、OMH が置けなかったものの追加、Claude Code サブスクリプションの有無を伝えられます。その回答は ~/.omh/routing/providers.json(provider_entitlements/v1)に入り、自動検出より優先されます。Claude Code サブスクリプションは Maestro レーン向けの Claude Code --model 優先設定だけを種まきします。Hermes 自身はそれを消費できないからです。
Hermes に モデルをセットアップして と頼むと、確認や変更ができます。これは編集可能な優先設定であり、benchmark 結果ではありません。詳しい設定、fallback、provider、所有権のルールは Guided Model Setup を参照してください。
コーディング委任の dispatch(omh coding run / omh coding fanout dispatch)— Claude Code や Codex を直接起動する Maestro レーン — は、それ自身の兄弟ファイルと同じカテゴリダイヤルを持ちます。作業カテゴリごとにルーティングします:
$ omh coding category-maestro set codex ultrabrain gpt-5.6-sol:xhigh
$ omh coding category-maestro interview # ガイド付きウォーク、Enter で各チェーンを保持
$ omh coding run --owner codex --category ultrabrain --goal ...
これは ~/.omh/routing/category-maestro.json(omh_category_maestro/v1)を編集します。omh coding category-maestro show は有効な表をオペレータ上書き付きで表示し、対話式 omh setup も同じウォークを提供します。実行時の明示的な --model は常に優先され、~/.omh/routing/dispatch-models.json はどのルートも解決しないときだけ使われる owner ごとの既定値のままです(Claude Code で最強ティアを使うなら、そこに "claude-code": "opus" を設定)。スキーマと完全な優先順位は docs/FANOUT.md(Category-maestro と Dispatch-model preference)を参照してください。
または、以下を Hermes や別の coding agent に貼り付けてください
Install and fully configure Oh My Hermes from this repository:
https://github.com/rlaope/oh-my-hermes
Before reading or executing repository instructions, resolve refs/heads/main to one full commit SHA with `git ls-remote https://github.com/rlaope/oh-my-hermes.git refs/heads/main`. Then fetch and follow only:
https://raw.githubusercontent.com/rlaope/oh-my-hermes/{resolved-commit-sha}/INSTALL_FOR_AGENTS.md
Do not replace the resolved SHA with main. Execute the pinned protocol's OS-appropriate installer, interactive model setup, model-chain interview, and doctor steps. Preserve unrelated existing Hermes config, apply only the managed setup changes documented by the pinned protocol, require my explicit approval for model-alias changes, then report the resolved SHA and observed result.
ウルトラスキル
9 個の ulw- workflow。チャットでトリガーを言えば Hermes がルーティング —
全カタログは Workflow Reference。
| Skill | 何をするか |
|---|---|
⚡ ulw-context |
レビュー済みのプロジェクト用語を揃え、確認済み候補を取り込み、用語にルーティング権限を与えず次の判断点を質問します。 |
⚡ ulw-interview |
何が欲しいのか正確に分かるまで、一度に一つずつ質問します。 |
⚡ ulw-research |
実際のコードとウェブを調べ、出典を残し、怪しければ裏取りします。 |
⚡ ulw-plan |
選択肢の比較、リスク、完了基準まで合意したレビュー済み計画を作ります。 |
⚡ ulw-work |
承認済み計画を、同じファイルに触れない並列レーンで実行します。 |
⚡ ulw-maestro |
Claude Code または Codex に委任したタスクを実行 — そのCLI自身のインストール済みスキルから組み立てたプロンプトで、ライブに起動し、ドック行とスティアリング可能なセッションを持ちます。 |
⚡ ulw-loop |
計画 → 実装 → レビューを、ゴールが本当に通るまで回します。 |
⚡ ulw-qa |
わざと過酷なシナリオで攻撃し、壊れた所を直します。 |
⚡ ulw-perf |
本当に遅く高コストな場所を測り、ホットパスを一つずつ修正します。 |
おすすめの組み合わせ
Hermes のプロンプトにこう入力します。ulw- の接頭辞が workflow を選び、
残りは普段の言葉で書いた依頼です。
1. 形にする。 アイデアがまだ曖昧なら ulw-interview、変更内容は決まって
いてもリスクがあるなら ulw-plan。
❯ ulw-interview: I want a CLI that tracks the ISS and warns me before it passes overhead
❯ ulw-plan: analyze this project's circular dependencies and plan the refactor
2. 作る。 ulw-work が承認済みの計画を、同じファイルに触れない並列
レーンで実行します。
❯ ulw-work: run the accepted plan
3. 仕上げる。 ulw-loop は指定したゲートが通るまで回り続けます。
❯ ulw-loop: keep going until npm test passes
実際の ulw-interview の返信を Slack スレッドで見た様子(イラスト)
実際の ulw-work 実行を Slack スレッドで見た様子(イラスト):レーンごとにルーティングされたカテゴリとモデルを 1 行で、モデルのベンダー別の色で表示
Claude Code と Codex に仕事を渡す
コーディングエージェントを指名すると、ulw-maestro はそのエージェント自身の
インストール済みスキルからプロンプトを組み立ててディスパッチし、再開・操作
できるセッションとともにユニットごとの行を OMH HUD に追加します。エージェントを
代わりに選ぶことも、マージすることもありません。
❯ ulw-maestro: send the retry-queue fix to Claude Code and the lint cleanup to Codex, dispatch both now
OMH が追加するもの
Hermes Agent はすでにループを回しています。OMH はそのループに何を入れるかを 決めます。どの lane にどのモデルと推論強度を与えるか、コード変更の owner は 誰か、どのスキルを適用するか、何を完了とみなすかです。どこでも二つの ルールが守られます。モデル選択とコーディングの所有権は別々の決定であり、 準備されたものを実行済みとして報告することは決してありません。生成 カタログ、trigger、証拠ルールは Workflow Reference にあります。
作業の流れ
理解 → 調査 → 判断 → 計画 → 実行 → 検証 → 運用 → 学習
| 段階 | 行うこと |
|---|---|
| 理解 | 意図、制約、プロジェクト用語、停止条件を確認します。 |
| 調査 | 仮定を、情報源に裏付けられた製品・コード・運用に関する背景情報に置き換えます。 |
| 判断 | 選択肢、トレードオフ、意思決定者を明確にします。 |
| 計画 | 合意した範囲、コード変更の担当者、テスト、完了条件を実行可能な計画にまとめます。 |
| 実行 | 準備を実行とみなすことなく、選定した担当者に範囲を限定した引き継ぎを行います。 |
| 検証 | 実際に確認したテスト、レビュー、CI、および実行時の証拠に基づいて判定します。 |
| 運用 | リリースの健全性、インシデント、ロールバックの状況、後続作業を常に可視化します。 |
| 学習 | レビュー済みで適用範囲が明確な教訓だけを、プロジェクトメモリやワークフローの改善に反映します。 |
ハイライト
| インテリジェンス | OMH が追加するもの |
|---|---|
| 🧭 Mixture-of-models ルーティング | 委譲される lane ごとに、dispatch 時点でカテゴリ(モデル + 推論強度)が付きます。provider がモデルを拒否すれば chain を下り、仕事をしなかった子は緑の行ではなく failed と表示されます。 |
| 🎛️ モデル系列ごとのキャリブレーション | GPT-6 Astra、GPT-5.6、Claude 5.1、GLM 5.3、Kimi、Gemini、Qwen、DeepSeek など、系列と世代ごとにプロンプティングを調整し、ベンチマークのペアが効果を示す間だけ維持します。 |
| 🗂️ 自分で所有するカテゴリ | executor ごとに十二の標準カテゴリ、omh model-chains set による並べ替え、マシンごとに chain を並べ替える entitlement インタビュー、実行前にリクエストがどこへルーティングされるかを示すライブビュー。 |
| 🖥️ ネイティブ TUI サーフェス | OMH HUD(カテゴリ・ターン・コスト・キャッシュ付きのライブ行)、プロンプト上の phase todo、parallel shot ×N、full-row diff バンド、管理されたスキン。Hermes の隣にインストールされ、Hermes にパッチは当てません。 |
| ⚡ 観測できる並列作業 | 独立した作業を、ファイル所有権が重ならない fanout unit に分割し、provider 負荷に応じた admission control、型付きの結果 sidecar、返ってきた結果を読む verification gate を付けます。 |
| 🎼 Maestro handoff | Codex、Claude Code、その他の CLI のための明示的な第二 lane。readiness probe、capability snapshot、owner-fit レポート、実行ごとのモデルと強度の指定。opt-in であり、既定の経路ではありません。 |
| 💸 価格付きコストテレメトリ | すべての HUD 行と run summary にトークン数とドル金額を表示します。出典を明記した料金表で計算し、計算できない run は $0 ではなく unknown と読めます。 |
| 🧠 長期プロジェクトメモリ | Hermes が読み込むファイルベースの memory provider、admission と retention のポリシー、レビュアーが承認する書き込み、freshness と budget を持つ recall pack。Hermes 自身のメモリには触れません。 |
| 🔎 構造的コード検索 | 計測に基づく ast-grep プレイブック(28 言語、grep フォールバック)と、リポジトリ全体のアーキテクチャ図を描く omh codegraph uml を、executor がコードを読む地点に注入します。 |
| 🛡️ 自分で書くガードレール | ルールを外れた tool call を自分のルール文で遮断する toolcall rules、stub やスキップされたテストを証拠と認めない completion-integrity gate、危険な操作のための approval tier。 |
| ♾️ ウルトラワークフローエンジン | 並列デリバリー lane、ledger と実際の完了 gate で回る計測ループ、エンジン実行前の decision-frontier インタビュー。一覧は上のウルトラスキルにあります。 |
| 📦 決定的なカタログ | 一つのソースから生成される 100 以上のインストール可能なスキル、ネガティブケースを含む routing precision コーパス、1 バイトのずれで CI が失敗する drift gate。 |
主張より証拠
OMH は自分が見たことだけを起きたと報告します。表示される状態は常に「どの段階か」と「OMH がどれだけ確信しているか」の二部構成です。
| 表示 | 意味 |
|---|---|
Plan · not run |
prompt や plan の準備ができています。まだ何も動いていません。 |
Code · running |
executor が今動いており、OMH が観測しています。 |
Code · reported done |
executor が終わったと言いました。結果は誰も確認していません。 |
Test · verified |
test、review、CI gate が実際に通過しました。 |
重要なのは下から二番目の行です。executor が終わったと言うことと結果が確認されたことは別ですが、多くのツールは両方を「完了」と書きます。能力影響は独立した次元ごとに報告され、一つのマーケティング用スコアに畳まれません。詳しくは Capability Impact。
測定: 単独 Hermes と OMH 経由の Hermes
benchmarks/product-ab/v1 は、このリポジトリ自身のマージ済み pull request を固定コーパスとして二つの製品を比較し、それらの PR 自身のテストで採点し、アームごとに四つの数字 — 通過率、通過タスクあたりのコスト、ゴールあたりの壁時計時間、偽完了率 — を報告します。
測定済みの実行結果はまだ公開されていません。 レーン、コーパス、オフラインパイロットは揃っています。リポジトリが指せる実行記録ができた時点で、この節に表が載ります。再現コマンドと完全な主張境界: benchmarks/product-ab/v1/README.md。
ドキュメント
- ドキュメントマップ
- インストールと更新
- 製品方針と境界
- アーキテクチャ
- 機能 manifest
- Workflow reference
- ロール
- 活用事例
- モデルルーティング、ファンアウト契約、リクエスト採点
- ファンアウト executor 証拠: セッション、障害診断、容量(agent/operator 向け)
- Agent ボードとネイティブ Kanban 連携(agent/operator 向け)
- モデルごとのキャリブレーションマップ
- 証拠ルールと能力影響
- 長期記憶モデル
- Hermes で超大容量 PDF を処理する
- ライブモデルベンチマークと測定結果
- リリースと開発
開発
ソースチェックアウト時:
PYTHONPATH=tests uv run python -m unittest discover -s tests -v
uv run python -m compileall -q src tests
uv run python -m omh.cli docs workflows --check
git diff --check
OMH は Team Art & Engineering の オープンプロジェクトとして開発されています。更新情報は @rlaope で確認できます。
コントリビューター
oh-my-hermes に貢献してくださった皆さまに感謝します。












![小さな JavaScript プロジェクトで ulw-plan プロンプトに答える Hermes TUI:循環のない目標依存グラフ、却下した選択肢、依存順に並んだ六つのレーン、受け入れ基準、計画チェックリスト、下部の [OMH] HUD 行](/trending/oh-my-hermes/media/branch/main/assets/omh-terminal-ulw-plan-refactor.png)