[omh] Ralph - one owner drives a concrete task to done: implement, verify, review, repeat until the gate passes; prefer over one-shot delegation when the task needs a verification loop. Aliases: ulr.
SkillScore73Maintained
Automatic
◆Coding pack
Last verified 8/19/2026
What it changes
Passed 14 of 19 test cases with the skill, and 5 of 19 without it.
Without skill27%
With skill73%
Checks it passed that the model alone missed
Passes --json to Codex CLI to retrieve the thread_id.
Includes codex exec resume <thread-id> for session recovery.
Identifies ~/.claude/settings.json for user scope permissions.
and 10 more in the full report
10 fixed6 passed either way6 still failing0 broke
Pass-rate lift
+45 pp
Tokens
+97%
Agent turns
0%
Response time
-28%
Model gemini-3.6-flashMeasured 8/19/2026v216 of 22 cases passed with skill · 19 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 10
Prompt
ralph: initialize execution tracking for fixing service/auth.py using the standard Hermes runtime command before making edits.
What was checked, without and with the skill
Checked
Without skill
With skill
Executes omh runtime record --skill ralph --harness goal-execution --status started to initialize tracking.
Missed
Passed
case-15 · 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.md122 linessingle file
Ralph
This is a Hermes-native ralph workflow skill.
Why This Exists
ralph exists to keep execution work explicit, evidence-backed, and inside the Hermes/executor boundary instead of relying on ad hoc chat narration.
Do Not Use When
Progress must survive sessions as a ledger with multiple checkpoints and a final gate; use ultragoal.
The request is a settings-only change, one bounded edit that is explicitly low-risk and has a direct owner and verification path, or a direct answer/diagnosis; handle it directly instead of opening a finish-until-done loop.
Examples
Good example:
Prompt: ralph: finish the invoice export recovery until the smoke test passes or a blocker is recorded.
Expected behavior: Keep one completion owner, track evidence after every recovery step, and stop only on pass, block, or explicit cancel.
Why: The request needs persistent completion pressure with an observable stop condition.
Bad example:
Prompt: ralph: treat casual chat or unaccepted work as if this workflow already produced verified results.
Expected behavior: Ask a clarification question or route to a narrower workflow instead of forcing ralph.
Why: The request lacks the required inputs or would overclaim work that Hermes did not observe.
Completion Checklist
The selected coding or runtime owner is named before any implementation claim.
Prepared handoff, dispatch, execution, verification, review, CI, and merge states are separated.
The final status cites observed runtime evidence or keeps the work prepared_not_observed.
When Hermes is the selected coding owner, use hermes_coding_harness/v1 to keep builder, verifier, reviewer, docs, and PR lanes separate.
Report the current harness stage, owner, next action, and missing evidence without claiming PR creation, review, CI, merge-readiness, or merge until matching runtime observations exist.
Recovery Notes
If the selected executor is unavailable, ask for Codex, Claude Code, Hermes, or another runtime before retrying.
If dispatch or result evidence is missing, keep the handoff prepared_not_observed and expose the next observable action.