/omh-routing

name: "omh-routing"
description: "[omh] Choosing among OMH skills for a request: router guidance for using oh-my-hermes workflow skills inside Hermes Agent."
metadata:
  hermes:
    tags: [workflow, oh-my-hermes, router]
    category: router
    phase: routing
    role: guide
    quality_tier: routing-gated

Oh My Hermes Router

Reasoning demand: `light`

Use this skill when the user mentions oh-my-hermes or a workflow keyword such as `deep-interview`, `ultraperf`, `ralplan`, `loop`, `product-docs`, `research`, `research-department`, `source-finder`, `paper-learning`, `long-document-reading`, `data-analysis`, `command-operator`, `connector-operator`, `live-info-operator`, `external-connector-readiness`, `physical-device-readiness`, `content-operator`, `media-input-operator`, `feedback-triage`, `finance-analysis`, `people-ops`, `legal-compliance-review`, `support-operations`, `curriculum-design`, `localization-review`, `sales-development`, `product-brief`, `materials-package`, `img-summary`, `design-quality-gate`, `frontend`, `accessibility-audit`, `visual-qa`, `browser-operator`, `workspace-file-operator`, `automation-blueprint`, `harness-session-inventory`, `agent-debug`, `failure-signal-audit`, `instinct-ledger`, `skill-scout`, `skill-health`, `workflow-learning`, `codebase-onboarding`, `codegraph-refresh`, `codebase-uml`, `context-budget-review`, `run-efficiency`, `provider-profile-posture`, `decision-recall`, `security-safety-review`, `application-threat-model`, `live-incident-response`, `code-review`, `build-failure-triage`, `ultrawork`, `ultraqa`, `doctor`.

Routing Contract

This is best-effort Hermes prompt guidance. It does not override Hermes core routing and it does not claim exact runtime parity with another agent framework.

Normal users should talk to Hermes Agent or invoke installed Hermes skills. Do not ask chat users to run `omh`; it is bootstrap and backend infrastructure.

Why This Exists

`oh-my-hermes` exists to keep Hermes chat routing conservative: it maps plain requests to the right workflow, explains evidence boundaries, and avoids making every keyword look like hidden implementation.

Do Not Use When

• The user already invoked a more specific installed skill and its routing signals are unambiguous.
• The message is ordinary chat, status acknowledgement, or a question that does not need workflow routing.
• The wrapper wants to claim execution, review, CI, or merge evidence that no observed artifact provides.

Examples

Good example:

• Prompt: Use OMH request-to-handoff for: safely add a feature to this repo.
• Expected behavior: Classify the request, name the retained Hermes lane or prepared coding handoff, and expose the observed/prepared evidence boundary.
• Why: The user asks for OMH-shaped routing without naming a narrow workflow, so the router should choose the safest next surface.

Bad example:

• Prompt: omh
• Expected behavior: Show the workflow picker or ask what the user wants to do next; do not infer a coding workflow.
• Why: A bare product name is a picker or clarification signal, not implementation evidence.

Completion Checklist

• The selected workflow, confidence reason, evidence boundary, and user-facing next action are named.
• Low-confidence or conflicting signals return a picker or clarification instead of forced routing.
• Catalog answers are rendered without shell approval when wrapper metadata is sufficient.

Recovery Notes

• If routing signals conflict, show the compact picker or ask one clarifying question.
• If wrapper metadata is unavailable, keep the recommendation advisory and avoid runtime claims.

OMH Awareness Primer (Compact)

OMH is Hermes-native workflow guidance, not a hidden executor or core patch. Hermes should retain routing, web/source research, deep interview, planning, status, and evidence narration. Coding-heavy work becomes an explicit `prepared_not_observed` handoff to the selected executor/runtime profile until observed.

Compact lane map:

• Intent -> plan: `deep-interview`, `ralplan`, `plan`, `loop`.
• Research and company ops: `research`, `source-finder`, `research-department`, `paper-learning`, `feedback-triage`, `strategy-brief`, `meeting-brief`.
• Retained knowledge: `wiki`.
• Materials and visual summaries: `design-quality-gate`, `frontend`, `accessibility-audit`, `visual-qa`, `materials-package`, `img-summary`, `report-package`, `deliverable-package`.
• Operations and evidence gates: `workspace-audit`, `production-audit`, `verification-gate`, `agent-evaluation`, `rules-distill`, `agent-ops-review`, `harness-session-inventory`, `ops-observability-card`, `instinct-ledger`, `workflow-learning`.
• Coding handoff and review: `idea-to-deploy`, `code-review`, `ultrawork`, `ultraqa`.

OMH Orchestration Posture

Treat OMH as the operating layer above individual Hermes-native skills. For a workflow-shaped request, first frame the problem, success criteria, constraints, risks, and evidence needed; then select the smallest OMH workflow and harness that can coordinate the work. Hermes-native skills, tools, and subagents are capabilities used inside that OMH-selected workflow, not competing top-level owners.

• On an unfamiliar or first-use pattern, briefly recommend the OMH-led route: explain that OMH can structure the problem, select the needed skills, and keep evidence boundaries clear.
• After repeated accepted local patterns for the same user and workflow, continue OMH-led exploration, problem framing, skill composition, and prepared planning automatically. Keep the current workflow, next action, and prepared-versus-observed boundary visible.
• Never let that autonomy bypass existing confirmation gates for destructive changes, credentials, external writes, deployment, executor dispatch, or starting a follow-on workflow engine (`ultrawork` — including its coordinated-scope, single-owner-persistence, delivery-boundary, and durable-checkpoint capabilities — `loop`, `ultraqa`) from anot