개요
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의 업데이터가 junction 대상으로 상대 경로를 전달했는데, PowerShell 7은 이를 거부하고(5.1은 허용했음) 그 결과 새 generation은 빌드되지만 활성화되지 않습니다.
**영구적인 해결 방법:** PR #2218이 포함된 버전(merge commit d0df9331a8156b611e3a6bee94465a5b18db45f8)으로 업그레이드하세요. 이 PR은 junction 생성 시 절대 대상 경로를 사용하도록 하여 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 폴백이나 정책 우회는 필요하지 않습니다.문제 해결Slack/Telegram/Discord DM 대화에서 OMH 메모리 레코드가 주입되지 않는 이유는 무엇인가요?
원인: OmhMemoryProvider.initialize()가 self._shared_surface = bool(kwargs.get("shared_surface", bool(platform and platform != "cli")))를 통해 모든 비CLI 플랫폼을 공유 표면으로 처리합니다. principal_context가 없는 공유 표면에서는 개인 및 레거시 레코드가 제외되므로(#1485에 따른 fail-closed), 저장소에 승인된 레코드가 있더라도 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"),
))그룹 채널과 알 수 없는 채팅 유형은 공유 상태로 유지되며 fail closed됩니다. 관리되는 번들을 패치하는 경우, 매번
omh update 전에 업스트림 텍스트를 복원하고 omh doctor가 통과한 후 패치를 다시 적용하세요.문제 해결왜 OMH의 Hermes delegate_task 자식 시스템 프롬프트에서 model-family calibration block이 누락되어 있나요?
이것은 OMH 4.0.0의 버그입니다: PR #2178에서 native 자식을 위한 omh.delegation-protocol 섹션을 추가했지만 calibration 테이블은 포함하지 않았으며, 이를 렌더링하는 모듈(coding/unit_prompt_assembly.py)은 native delegate_task가 아닌 coding fanout 경로에서만 사용됩니다. PR #2215(커밋 8981d6967cec156b2e675fc663a4580f972b98e6)에서 수정되었습니다 — 해당 머지가 포함된 빌드로 OMH를 업그레이드하세요. 수정 후에는 모든 native delegate_task 자식이 별도의 omh.child-calibration 시스템 프롬프트 섹션을 받으며, calibration은 자식 자신의 모델을 기준으로 다음 순서로 결정됩니다: 정확한 오버라이드 → 모델 패밀리 → generic. 동작 참고 사항: native 자식은 모든 effort 수준에서 calibration을 받습니다(Hermes 섹션 메타데이터는 reasoning_effort를 안정적으로 노출할 수 없음). 반면 omh coding fanout 경로는 calibration_entry_for_route를 통해 기존의 high/xhigh/max effort 게이트를 유지합니다. omh.delegation-protocol 섹션 텍스트는 변경되지 않았습니다.
문제 해결왜 Hermes delegate_task 자식은 OMH 위임 프로토콜을 받지 못하며, 어떻게 해결해야 하나요?
이는 OMH 4.0.0의 버그입니다: 플러그인의 pre_tool_call 훅(hooks/tool_hooks.py:128)은 delegate_task에 대해 알 수 없는 역할 경고만 추가하고 None을 반환할 뿐, coding-handling 하니스가 모든 위임 프롬프트에 요구하는 위임 프로토콜(goal echo-back, numbered done criteria, verification pass)을 절대 주입하지 않습니다. 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 상태를 프로필별로 네임스페이싱하는 방식)이 진행 중입니다.