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, github-issue-intake, buzz, agent-board, +35 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.
1---2name: omh-running-work-board3description: [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, 지금 뭐 돌고 있어, 뭐가 돌고 있어, 어떤 모델로 돌고 있어, 실행 중인 작업 보여줘.4---5
6# Running Work Board
7
8This is a Hermes-native `running-work-board` workflow skill.
9
10## Why This Exists
11
12`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.
13
14## Do Not Use When
15
16- The user wants to start, plan, or dispatch coding work rather than observe it.
17- The user wants review, CI, or merge evidence, which a status board never provides.
18- The user is asking about their own application's runtime status rather than OMH coding units.
19
20## Examples
21
22Good example:
23
24- Prompt: what is running right now
25- Expected behavior: One line per unit: label, runtime, model, status, elapsed, tokens, with unknown printed where nothing was observed.
26- Why: The request is about observed local coding activity, not about starting work.
27
28Bad example:
29
30- Prompt: is the deploy done and did CI pass
31- Expected behavior: Route to verification or CI evidence instead of the activity board.
32- Why: Observed activity is not result, review, CI, or merge evidence.
33
34## Completion Checklist
35
36- Runtime and model are named per unit, or explicitly reported as unknown.
37- Token counts and session references are observed values or the literal unknown, never estimates.
38- Elapsed time for an unfinished unit comes from its start marker, which cannot prove the unit is still alive.
39- The board is labelled observed activity, not result, verification, review, CI, or merge evidence.
40
41## Recovery Notes
42
43- If no units are found, say so plainly rather than implying nothing ever ran.
44- If a marker is stale because a process died, report it as observed-start-without-end instead of claiming the unit is running.
45- If tokens are unknown for a runtime with no structured output, say the runtime does not report them.
46
47## Workflow Lane
48
49- Current lane: **Automation and status** (`achievements`, `workspace-audit`, `production-audit`, `automation-blueprint`, `github-event-ops`, `github-issue-intake`, `buzz`, `agent-board`, `+35 more`) - schedules, status, health, and ops review.
50- If intent belongs to another lane, hand back to `oh-my-hermes` or name the adjacent workflow.
51- Shared product, routing, compatibility, and evidence rules: `omh-routing/references/skill-common-rail.md`.
52
53## Use When
54
55Use 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.
56
57 Strong routing signals: `running-work-board`, `running work board`, `which units are running`, `what models are running`, `지금 뭐 돌고 있어`, `뭐가 돌고 있어`, `어떤 모델로 돌고 있어`, `실행 중인 작업 보여줘`
58
59## Catalog Metadata
60
61Category: `operator`
62Phase: `observability`
63Hermes role: `tracker`
64Quality tier: `evidence-gated`
65Reasoning demand: `light`
66
67Quality bar:
68
69- Name the workflow target, constraints, validation evidence, and stop condition.
70- Separate Hermes guidance from executor or wrapper behavior unless evidence proves the step happened.
71
72Handoff policy:
73
74Read local dispatch and progress artifacts directly and render the board; never dispatch or modify a unit from this workflow.
75
76Required inputs:
77
78- local coding artifacts
79
80Expected outputs:
81
82- per-unit runtime and model
83- observed tokens and elapsed
84- explicit unknowns
85
86Artifact expectations:
87
88- metadata-only status board projection from local artifacts
89
90Safety rules:
91
92- Do not imply hidden Hermes runtime behavior.
93- Use the smallest verification that can prove the claim.
94
95## Runtime Evidence
96
97Preferred harness for this skill: `coding-handling`.
98
99```sh
100omh runtime record --skill running-work-board --harness coding-handling --status started
101```
102
103Record observed delegation results; otherwise return `not_available` or `not_observed`.
104Prepared OMH routing is not execution, review, CI, merge-readiness, or merge evidence.
105- Treat wrapper memory/context summaries as advisory local context, not proof of opaque Hermes memory reads or changes.
106Preserve workflow intent and stop conditions; verify before claiming completion.
107
108Use Hermes-native subagent/delegation features when available: native subagents -> Hermes delegation when available, otherwise sequential lanes.
109
110Shared product, compatibility, topology, memory, harness, and execution rules: `omh-routing/references/skill-common-rail.md`. Load it when applicable; otherwise name an unavailable capability.
rlaope