概要
Oh My Hermes は、Hermes Agent プログラミングアシスタント向けのオールインワン強化レイヤーであり、長期プロジェクトメモリ、モデル最適化ワークフローパッケージ、オリジナルスキルを統合しています。リクエストを明確な機能と検証可能なエビデンスの境界に変換し、omh コマンドでインストール設定、更新、モデル選択、診断を完了し、既存のワークフローを置き換えるのではなく強化します。
README プレビュー
\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)
トラブル対応Windowsでomh updateを実行した際に発生する「Creating a junction requires an absolute path for the target」エラーの修正方法
これは、PATH 上の powershell.exe が Windows PowerShell 5.1 ではなく PowerShell 7 に解決される場合に発生します。OMH のアップデーターはジャンクションのターゲットとして相対パスを渡していましたが、PowerShell 7 はこれを拒否します（5.1 では許容されていました）。そのため、新しい世代はビルドされるものの、アクティブ化されません。
**恒久的な修正:** PR #2218（マージコミット d0df9331a8156b611e3a6bee94465a5b18db45f8）を含むバージョンにアップグレードしてください。これにより、ジャンクションの作成で絶対ターゲットパスが使用されるようになり、PowerShell 7 と 5.1 の両方で動作します。
**旧バージョン（例: 4.0.0）での回避策:** 更新の実行時のみ、Windows PowerShell 5.1 を一時的に PATH の先頭に配置します:
set PATH=C:\Windows\System32\WindowsPowerShell\v1.0;%PATH%
omh updateその後、
omh doctor で確認してください。cmd へのフォールバックやポリシーのバイパスは必要ありません。トラブル対応なぜOMHメモリレコードはSlack/Telegram/DiscordのDM会話に注入されないのですか？
原因: OmhMemoryProvider.initialize() は、self._shared_surface = bool(kwargs.get("shared_surface", bool(platform and platform != "cli"))) によって、CLI 以外のすべてのプラットフォームを共有サーフェスとして扱います。principal_context のない共有サーフェスでは、パーソナルレコードとレガシーレコードが除外されるため(#1485 に基づくフェイルクローズ)、ストアに承認済みレコードが保持されている場合でも、1:1 の DM ターンはレビュー済みレコードを一切受け取りません。修正/回避策: 明示的な shared_surface kwarg が渡されない場合に、chat_type == "dm" を非共有として扱うようにプロバイダーにパッチを適用します:
self._shared_surface = bool(kwargs.get(
"shared_surface",
bool(platform and platform != "cli" and kwargs.get("chat_type") != "dm"),
))グループチャンネルおよび不明なチャットタイプは、引き続き共有のままとなり、フェイルクローズします。管理対象バンドルにパッチを適用する場合は、各
omh update の前にアップストリームのテキストを復元し、omh doctor がパスした後にパッチを再適用してください。トラブル対応なぜ OMH の Hermes delegate_task 子システムプロンプトにはモデルファミリーキャリブレーションブロックが含まれていないのですか？
これは OMH 4.0.0 のバグです: PR #2178 でネイティブの子タスク向けに omh.delegation-protocol セクションが追加されましたが、キャリブレーションテーブルが含まれておらず、それをレンダリングするモジュール (coding/unit_prompt_assembly.py) は coding fanout パスでのみ使用され、ネイティブの delegate_task では使用されていませんでした。PR #2215 (コミット 8981d6967cec156b2e675fc663a4580f972b98e6) で修正されました — そのマージを含むビルドに OMH をアップグレードしてください。修正後、すべてのネイティブ delegate_task 子タスクに個別の omh.child-calibration システムプロンプトセクションが付与され、キャリブレーションは子タスク自身のモデルから次の順序で解決されます: 完全一致のオーバーライド → モデルファミリー → 汎用。動作に関する注意: ネイティブの子タスクはすべてのエフォートレベルでキャリブレーションを受け取ります (Hermes のセクションメタデータは reasoning_effort を確実に公開できないため)、一方 omh coding fanout パスは calibration_entry_for_route による既存の high/xhigh/max エフォートゲートを維持します。omh.delegation-protocol セクションのテキストは変更されていません。
トラブル対応なぜ Hermes の delegate_task の子タスクは OMH 委譲プロトコルを受け取らないのですか？また、それを修正するにはどうすればよいですか？
これは OMH 4.0.0 のバグです。プラグインの pre_tool_call フック（hooks/tool_hooks.py:128）は delegate_task に対して unknown-role の警告を追加して None を返すだけで、coding-handling ハーネスが委譲されるすべてのプロンプトに要求する委譲プロトコル（goal のエコーバック、番号付きの完了条件、検証パス）を一切注入しません。OMH は自ら組み立てるユニットプロンプト（omh/coding/unit_prompt_assembly.py）にのみこのプロトコルを埋め込むため、Hermes ネイティブの delegate_task によるスポーンでは、親モデルが手動で貼り付けない限りプロトコルが渡されません。回避策（動作確認済み）: omh coding composition-guide --json の出力からテキストを構築したシステムプロンプトセクションを登録するローカルの Hermes プラグインを作成します。Hermes ホストはプラグインのシステムプロンプトセクションを delegate_task の子セッションに引き継ぐため、スポーンされるすべての子が自動的にプロトコルを受け取ります。検証は、子セッションに保存されたシステムプロンプトを確認して行います。そこにプロトコルの行が含まれていること、また子の最初のユーザーメッセージがディスパッチされた goal とバイト単位で同一であることを確認してください。
トラブル対応~/.omh を共有するマルチプレクス化されたプロファイルを使用している場合に、OMH メモリコンソリデーション (dreaming) ブリーフが毎ターン表示されないようにするには？
これは OMH 3.0.2 の既知のバグです。このプラグインはシングルトンであり、すべてのプロファイルを共有の ~/.omh ストアにバインドするため、memory/dreaming.json と memory/consolidation.json はグローバルになっています。あるプロファイルが headroom_below_floor を検出するとブリーフが書き込まれ、render_pack() がそれを全プロファイルのすべてのターンに注入し、ターン間隔/コンパクションのカウンターもホスト全体でカウントされます。現時点では dreaming を無効にするサポートされた設定はありません(DREAMING_MODES は存在しますが、consolidation_reasons() は常にデフォルトで呼び出されます)。回避策: memory_dreaming.py を編集して DEFAULT_DREAMING_MODE = "off" に設定し、read_latest_consolidation() 内で due = False を強制します。これは管理対象ファイルを変更するため、omh update を実行する前に上流の内容を復元し、omh doctor を実行して plugin_manifest/plugin_bundle_current のチェックを通過させてから、パッチを再適用する必要があります。適切な修正(memory_session_lens.py や todo_store.py がすでに行っているように、profile_slot(hermes_home) のハッシュによってプロファイルごとに dreaming の状態を名前空間化するもの)が現在進められています。