[omh] Hermes Idea-to-Deploy workflow: shape an app idea into decisions, delivery handoff, verification, release, and monitoring status.
SkillScore77Maintained
Automatic
◆Product Management pack
Last verified 8/18/2026
What it changes
Passed 16 of 21 test cases with the skill, and 6 of 21 without it.
Without skill27%
With skill77%
Checks it passed that the model alone missed
Classifies deployment status as unobserved or not_observed.
Classifies deployment status as unobserved pending runtime evidence.
Categorizes outputs into prepared, observed, blocked, or missing states.
and 12 more in the full report
11 fixed6 passed either way5 still failing0 broke
Pass-rate lift
+50 pp
Tokens
+34%
Agent turns
0%
Response time
-30%
Model gemini-3.6-flashMeasured 8/18/2026v217 of 22 cases passed with skill · 21 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
Show the exact CLI runtime recording command to register that the app delivery loop has started for the `idea-to-deploy` skill.
What was checked, without and with the skill
Checked
Without skill
With skill
Outputs the exact CLI command omh runtime record with --skill idea-to-deploy --harness app-delivery-loop --status started.
Missed
Passed
case-16 · 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.md109 linessingle file
Idea To Deploy
This is a Hermes-native idea-to-deploy workflow skill.
Why This Exists
idea-to-deploy exists to keep delivery work explicit, evidence-backed, and inside the Hermes/executor boundary instead of relying on ad hoc chat narration.
Do Not Use When
The task is already a concrete repo change whose stopping point is one PR-ready cycle, not product or release operations; use ultrawork.
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 product delivery loop.
Examples
Good example:
Prompt: idea-to-deploy: turn this onboarding idea into a scoped plan, implementation handoff, QA gate, and release path.
Expected behavior: Prepare the idea-to-release lane while keeping implementation, QA, and deploy evidence observed-only.
Why: The request spans product shaping through deploy readiness instead of a single task.
Bad example:
Prompt: idea-to-deploy: 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 idea-to-deploy.
Why: The request lacks the required inputs or would overclaim work that Hermes did not observe.
Completion Checklist
Confirm the workflow target, evidence boundary, and stop condition are named.
Report which outputs are prepared, observed, blocked, or missing.
Name the smallest next verification or handoff instead of claiming completion from narration.
Recovery Notes
If required context is missing, ask one blocking question or route back to the narrower workflow.
If runtime or wrapper evidence is unavailable, keep the status as not_observed and expose the next observable action.