Ulw Plan

Catalog Metadata

Category: planning Phase: reviewed-plan Hermes role: planner Quality tier: reviewed-plan-gated Reasoning demand: standard

Quality bar:

• Start from observed repo facts and source/web evidence when freshness or external behavior matters.
• Include planner view, critic/risk review, alternative paths, rejected options, and a testability check before handoff.
• Produce testable acceptance criteria and exact verification commands or explain why they are not yet knowable.
• List every lane of the accepted plan in node-prompt shape - TASK, DELIVERABLE, SCOPE, VERIFY, STOP WHEN - with depends_on per lane, so ultrawork can prepare board rows from the plan without re-planning; planning itself stays a bounded in-session lane.
• Record unresolved tradeoffs and evidence gaps instead of flattening uncertainty.
• When plan-shaping evidence is missing — current external behavior, contested claims, or unstudied reference implementations — run the research workflow as a bounded in-plan stage (not an exhaustive deep-research run) before comparing options, record its dossier the way the research artifact contract requires, and consume it instead of planning on assumptions.
• Consume a recorded research dossier when one exists: plan options and rejected alternatives should cite its decision drivers and verified claims.
• End with a selected executor/runtime handoff shape only after the plan is accepted.
• Plan acceptance approves the plan content, not execution: after acceptance, recommend the follow-on path that fits the work's shape — ultrawork durable checkpoints for progress that must survive sessions as a checkpointed ledger, ultrawork coordinated lanes for an accepted plan split into disjoint parallel lanes, ultrawork single-owner persistence for one already-scoped task with a single owner, ultrawork for one bounded delivery cycle, or a direct selected executor/runtime handoff for a single prepared coding change — state the fit reason in one line, and start it only after the user's explicit go-ahead.
• Do not implement directly from consensus planning.

Handoff policy:

Keep consensus planning and review in Hermes; produce explicit selected executor/runtime handoff guidance only after the plan is accepted, and start a follow-on workflow engine only after the user explicitly confirms the recommended path.

Required inputs:

• requirements
• codebase facts
• source or web evidence when needed, or an in-plan research stage to obtain it
• options
• tradeoffs
• test shape

Expected outputs:

• reviewed plan
• acceptance criteria
• risk register
• verification commands
• handoff guidance

Artifact expectations:

• record the plan with omh hermes plan --record, which writes <repo>/.omh/plans/<slug>.md inside a repository and the user-scope OMH store outside one
• mark acceptance with omh hermes plan-accept <path> so acceptance_recorded and handoff_ready point at a real artifact

Safety rules:

• Do not implement directly from the planning lane.
• Do not invent codebase or web evidence; label missing evidence and source gaps.
• Make acceptance criteria testable.
• Record unresolved tradeoffs explicitly.
• Keep rejected options and handoff readiness separate from accepted execution evidence.
• Write plan artifacts only through the named omh hermes plan commands under <repo>/.omh/plans/; never write plans or planning state into .omc/** or any other wrapper's state root — .omc/ belongs to oh-my-claudecode, a different product.

Runtime Evidence

Preferred harness for this skill: planning.

omh runtime record --skill ralplan --harness planning --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.

• When wrapper metadata includes memory_review_card/v1 or handoff_context_pack/v1, treat it as reviewed OMH-local or wrapper-supplied context only. Use conflict-free context summaries to shape plans and handoffs, but do not claim Hermes internal memory was read or changed. Preserve workflow intent and stop conditions; verify before claiming completion. Reply in the user's own words and the host's own voice: its SOUL.md persona owns reply language, tone, speech level, and sentence endings, progress updates included (where it sets no language, use the one the user wrote in), and OMH shapes structure and content only; OMH's record terms (surface, lane, wrapper, handoff, evidence boundary, not_observed) stay in records and tool calls, never in the sentence the user reads unless they ask about one; and when a stop condition or a decision the user owns ends the turn, offer the next action as a question rather than declaring what will not be done.

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.