[omh] Hermes ops observability workflow: prepare an operations command-board for wrapper-safe token, cost, latency, run history, queue, failure-mode, external metric-provider, and service-quality evidence boundaries.
SkillScore95Maintained
Automatic
◆DevOps & SRE pack
Last verified 8/19/2026
What it changes
Passed 21 of 22 test cases with the skill, and 8 of 22 without it.
Without skill36%
With skill95%
Checks it passed that the model alone missed
Provider truth is marked as not_observed
Datadog or AWS metrics are marked as not_observed
The output contains the ops_service_quality_board/v1 layout
and 19 more in the full report
14 fixed7 passed either way0 still failing1 broke
Pass-rate lift
+59 pp
Tokens
+26%
Agent turns
0%
Response time
-27%
Model gemini-3.6-flashMeasured 8/19/2026v221 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 14 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 14
Prompt
Can you build an ops service quality board for our worker gateway execution? I'd like an observability card report that displays run history, failure modes, and token/cost telemetry, separating verified metric provider data from unverified local estimates.
What was checked, without and with the skill
Checked
Without skill
With skill
Local telemetry estimates are explicitly designated as unverified local state
Missed
Passed
Provider billing or live quota data without direct evidence is marked as not_observed
Missed
Passed
The response includes an external_metric_provider/v1 contract section
Missed
Passed
case-02 · gemini-3.6-flash · 8/19/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md114 linessingle file
Ops Observability Card
This is a Hermes-native ops-observability-card workflow skill.
Why This Exists
ops-observability-card exists so Hermes users can ask for this workflow in chat and receive a structured, evidence-bounded OMH operating surface instead of ad hoc narration.
Do Not Use When
The request is already handled by a narrower explicit skill with stronger evidence.
The user asks OMH to secretly run external platforms, connectors, schedulers, file exports, or runtime agents.
The only safe answer is to ask for missing authority, credentials, target, or observed evidence first.
Examples
Good example:
Prompt: ops-observability-card show token, cost, latency, supplied Prometheus/Grafana metrics, and missing service-quality evidence for this loop.
Expected behavior: Produce prepare_ops_observability_card with required context, wrapper actions, and not-evidence boundaries.
Why: The prompt names a real workflow surface that Hermes can orchestrate without hiding execution.
Bad example:
Prompt: ops-observability-card claim exact provider billing, healthy SLO, incident closure, or remediation completion from local estimates.
Expected behavior: Report the missing observed evidence or authority instead of claiming the external step happened.
Why: Prepared OMH guidance is not platform, runtime, connector, file, memory, or delivery evidence.
Completion Checklist
The run or workflow scope, metric window, failure modes, and cost/latency boundary are named.
Local telemetry, provider truth, billing truth, and completion evidence are separate states.
Warnings name the next measurement or operator review action.
Recovery Notes
If provider metrics are unavailable, report only local metadata and mark provider truth not_observed.
If cost or latency looks risky, surface a warning plus the next measurement rather than a completion claim.