[omh] Ultragoal - durable multi-session goal tracking: a checkpointed ledger survives context loss and resumes exactly where work stopped, with a final completion gate. Aliases: ulg.
SkillScore86Maintained
Automatic
◆Project Management pack
Last verified 8/18/2026
What it changes
Passed 17 of 20 test cases with the skill, and 6 of 20 without it.
Without skill32%
With skill86%
Checks it passed that the model alone missed
Inspects the .omh/goals directory for existing goal state files
Specifies the --output-format json flag to capture session output
Marks or retains the coding milestone status as prepared_not_observed
and 16 more in the full report
12 fixed7 passed either way3 still failing0 broke
Pass-rate lift
+55 pp
Tokens
+102%
Agent turns
0%
Response time
-51%
Model gemini-3.6-flashMeasured 8/18/2026v219 of 22 cases passed with skill · 20 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 11 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 11
Prompt
Here is an accepted architecture plan and clarified brief for a database migration. We are ready to move forward into goal tracking. State your setup line and request my go-ahead.
What was checked, without and with the skill
Checked
Without skill
With skill
Restates the proposed engine, scope, and selected executor in a single line
Missed
Passed
Waits for explicit user confirmation before initiating the engine workflow
Passed
Passed
case-07 · gemini-3.6-flash · 8/18/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md133 linessingle file
Ultragoal
This is a Hermes-native ultragoal workflow skill.
Why This Exists
ultragoal exists for work that can outlive one chat turn: it turns ambition into durable stories, checkpoints, and completion gates so progress can resume without pretending a summary is evidence.
Do Not Use When
The request is a single-turn answer, quick diagnosis, or small edit that does not need a durable ledger.
One concrete, already-scoped task only needs one owner to finish and verify; use ralph.
The next work must be discovered or reframed repeatedly through research and feedback cycles; use loop.
The request is a settings-only or single configuration change (for example a gateway channel policy, a mention rule, or one config key) that the wrapper or Hermes can apply directly; apply the configuration change, verify the new value, and report it instead of opening a goal ledger or preparing a coding handoff.
Acceptance criteria, current checkpoint, and final gate expectations are too vague to make a goal inspectable.
The user expects hidden Hermes code execution rather than explicit executor handoff and observed verification evidence.
Examples
Good example:
Prompt: $ultragoal turn OMH skill quality into a durable goal with rubrics, generated skill sync, tests, and a PR gate.
Expected behavior: Create or update a goal ledger, split the story into verifiable checkpoints, and close only after generated docs, skills, and tests match.
Why: The task has multiple milestones and a final quality gate that should be inspectable across interruptions.
Bad example:
Prompt: $ultragoal what does this one error mean?
Expected behavior: Route to diagnosis or a direct answer instead of creating a durable goal.
Why: A narrow explanation does not need checkpointed long-running state.
Completion Checklist
The goal_ledger/v1 names the current criteria, checkpoints, blockers, and next action.
The goal_completion_gate/v1 result passes from required evidence, not from a summary-only message.
All explicitly linked coding milestones have matching observed runtime evidence or are still named as gaps.
The final user-facing status says complete, blocked, or continue with the exact remaining checkpoint.
Long-running or background executor milestones report observed handles, current state, changed-file summaries, missing checks, and prepared-vs-observed boundaries while work is running.
When Hermes is the coding owner, use hermes_coding_harness/v1 to separate builder, verifier, reviewer, docs, and PR lanes.
Branch, PR, CI, review, and merge claims are verified against local HEAD, remote branch SHA, PR head SHA, and merge commit before saying a fix landed.