[omh] Turn product evidence into a decision-ready PRD, prioritization frame, and roadmap brief.
SkillScore77Maintained
Automatic
◆Product Management pack
Last verified 8/19/2026
What it changes
Passed 17 of 22 test cases with the skill, and 5 of 22 without it.
Without skill23%
With skill77%
Checks it passed that the model alone missed
Refrains from declaring public market commitments.
Designates the required decision owner for sign-off.
Includes explicit non-goals to define scope boundaries.
and 12 more in the full report
12 fixed5 passed either way5 still failing0 broke
Pass-rate lift
+55 pp
Tokens
+22%
Agent turns
0%
Response time
-16%
Model gemini-3.6-flashMeasured 8/19/2026v217 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 12 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 12
Prompt
The product team already approved PRD-402 for adding Google OAuth. The detailed technical specs, repo constraints, and test plans are finalized. Create the delivery implementation plan and initiate code changes.
What was checked, without and with the skill
Checked
Without skill
With skill
Recommends routing to ralplan for technical execution planning.
Missed
Passed
Refrains from generating a new product requirements document.
Passed
Passed
case-05 · 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.md113 linessingle file
Product Brief
This is a Hermes-native product-brief workflow skill.
Why This Exists
product-brief turns product evidence into a reviewable PRD and prioritization frame before delivery planning without treating a draft as an accepted roadmap commitment.
Do Not Use When
The input is unprocessed feedback, bug reports, or feature asks that first need clustering and evidence boundaries; use feedback-triage.
The user needs a company or product strategy decision across high-level options rather than a requirements or roadmap artifact; use strategy-brief.
The request is an accepted, code-ready change with repository constraints and verification needs; use ralplan or ultrawork rather than recreating a PRD.
The user asks to create or update Jira, Linear, Aha!, or a roadmap system directly; use connector-operator with explicit target, approval, and observed evidence.
Examples
Good example:
Prompt: Create a PRD and prioritization options for reducing first-time user drop-off in onboarding.
Expected behavior: Prepare the product problem, user and metric brief, PRD, roadmap options, tradeoffs, and downstream prerequisites.
Why: The request needs a decision-ready requirements and prioritization artifact before delivery planning.
Bad example:
Prompt: Implement the accepted onboarding PRD and open a PR.
Expected behavior: Route to ultrawork or ralplan, not product-brief.
Why: Accepted implementation work should move into planning or delivery rather than recreate a PRD.
Completion Checklist
The plan names goals, non-goals, assumptions, acceptance criteria, and verification shape.
Draft recommendations, accepted decisions, and executor handoffs are separate states.
Rejected options or unresolved tradeoffs are recorded before handoff.
Recovery Notes
If acceptance criteria or verification are missing, route back to clarification before handoff.
If assumptions materially affect the plan, keep them visible and avoid treating the plan as accepted.