| name | omh-running-work-board |
| description | ["omh"] |
| Hermes adaptation for showing which coding units are running right now, on which runtime and model, with observed tokens and elapsed time. Use when the user says | running-work-board, running work board, which units are running, what models are running, ์ง๊ธ ๋ญ ๋๊ณ ์์ด, ๋ญ๊ฐ ๋๊ณ ์์ด, ์ด๋ค ๋ชจ๋ธ๋ก ๋๊ณ ์์ด, ์คํ ์ค์ธ ์์
๋ณด์ฌ์ค. |
| metadata | {"hermes":{"tags":["workflow","oh-my-hermes","operator"],"category":"operator","phase":"observability","role":"tracker","quality_tier":"evidence-gated"}} |
Running Work Board
This is a Hermes-native running-work-board workflow skill.
Why This Exists
running-work-board exists because multi-session coding work was invisible: the runtime was tracked but the model was dropped, token counts had no write site at all, and a blocking dispatch could not report that it was still running. The board answers which model on which runtime, or says unknown.
Do Not Use When
- The user wants to start, plan, or dispatch coding work rather than observe it.
- The user wants review, CI, or merge evidence, which a status board never provides.
- The user is asking about their own application's runtime status rather than OMH coding units.
Examples
Good example:
- Prompt: what is running right now
- Expected behavior: One line per unit: label, runtime, model, status, elapsed, tokens, with unknown printed where nothing was observed.
- Why: The request is about observed local coding activity, not about starting work.
Bad example:
- Prompt: is the deploy done and did CI pass
- Expected behavior: Route to verification or CI evidence instead of the activity board.
- Why: Observed activity is not result, review, CI, or merge evidence.
Completion Checklist
- Runtime and model are named per unit, or explicitly reported as unknown.
- Token counts and session references are observed values or the literal unknown, never estimates.
- Elapsed time for an unfinished unit comes from its start marker, which cannot prove the unit is still alive.
- The board is labelled observed activity, not result, verification, review, CI, or merge evidence.
Recovery Notes
- If no units are found, say so plainly rather than implying nothing ever ran.
- If a marker is stale because a process died, report it as observed-start-without-end instead of claiming the unit is running.
- If tokens are unknown for a runtime with no structured output, say the runtime does not report them.
Workflow Lane
- Current lane: Automation and status (
achievements, workspace-audit, production-audit, automation-blueprint, github-event-ops, buzz, agent-board, gateway-intent-card, +34 more) - schedules, status, health, and ops review.
- If intent belongs to another lane, hand back to
oh-my-hermes or name the adjacent workflow.
- Shared product, routing, compatibility, and evidence rules:
omh-routing/references/skill-common-rail.md.
Use When
Use when the user asks what coding work is running right now -- which unit, which runtime, which model, how long, how many tokens -- rather than asking to start, plan, or review work.
Strong routing signals: `running-work-board`, `running work board`, `which units are running`, `what models are running`, `์ง๊ธ ๋ญ ๋๊ณ ์์ด`, `๋ญ๊ฐ ๋๊ณ ์์ด`, `์ด๋ค ๋ชจ๋ธ๋ก ๋๊ณ ์์ด`, `์คํ ์ค์ธ ์์
๋ณด์ฌ์ค`
Catalog Metadata
Category: operator
Phase: observability
Hermes role: tracker
Quality tier: evidence-gated
Reasoning demand: light
Quality bar:
- Name the workflow target, constraints, validation evidence, and stop condition.
- Separate Hermes guidance from executor or wrapper behavior unless evidence proves the step happened.
Handoff policy:
Read local dispatch and progress artifacts directly and render the board; never dispatch or modify a unit from this workflow.
Required inputs:
Expected outputs:
- per-unit runtime and model
- observed tokens and elapsed
- explicit unknowns
Artifact expectations:
- metadata-only status board projection from local artifacts
Safety rules:
- Do not imply hidden Hermes runtime behavior.
- Use the smallest verification that can prove the claim.
Runtime Evidence
Preferred harness for this skill: coding-handling.
omh runtime record --skill running-work-board --harness coding-handling --status started
Record observed delegation results; otherwise return not_available or not_observed.
Prepared OMH routing is not execution, review, CI, merge-readiness, or merge evidence.
- Treat wrapper memory/context summaries as advisory local context, not proof of opaque Hermes memory reads or changes.
Preserve workflow intent and stop conditions; verify before claiming completion.
Use Hermes-native subagent/delegation features when available: native subagents -> Hermes delegation when available, otherwise sequential lanes.
Shared product, compatibility, topology, memory, harness, and execution rules: omh-routing/references/skill-common-rail.md. Load it when applicable; otherwise name an unavailable capability.