/ulw-plan

name: "ulw-plan"
description: "[omh] High-stakes technical proposal needing approval: consensus planning with review gates. Use when the user says: ralplan, consensus plan, reviewed plan, issue to PR, acceptance criteria, verification command, reviewable PR, risky planning."
metadata:
  hermes:
    tags: [workflow, oh-my-hermes, planning]
    category: planning
    phase: reviewed-plan
    role: planner
    quality_tier: reviewed-plan-gated

Ralplan

This is a Hermes-native `ralplan` workflow skill.

Why This Exists

`ralplan` exists to make planning reviewable before execution: Hermes should gather codebase/source facts, compare options, expose risks, define acceptance criteria, and prepare a handoff without pretending implementation already happened.

First Steps

• Initialize the plan todo before the first planning step: declare the planning stages as `omh_todo` items (todo init) — repo facts and evidence check, options and tradeoffs, risk review, acceptance criteria and verification commands, plan record and acceptance — keep exactly one item active, and when the evidence check reveals a gap rewrite the list (`omh_todo` action=set) to insert the research stage; update the list as stages complete so the HUD todo panel shows plan progress as a bounded checklist, and treat items as declarations, never execution evidence. Phase names and task titles are written in English — short, operator-legible labels — even when the conversation runs in another language, since the HUD todo checklist is an operator surface under the repo's English-by-default output contract.

Do Not Use When

• The request is still too ambiguous to name requirements, non-goals, or acceptance criteria; use `deep-interview` first.
• The user asks for one full research-plan-implementation-review-PR cycle; use `ultrawork` (its `delivery_boundary` capability) and keep ralplan as the planning stage.
• The change is a small local refactor or cleanup with no architectural or regression risk; use `ultrawork`, or `ai-slop-cleaner` when observable behavior must stay identical.
• The refactor's direction is already decided and what is missing is its execution shape - which files move in which phase, what verifies each phase, where each phase rolls back to; use `refactor-plan`.
• One plan-blocking choice still needs behavior evidence rather than argument; run `decision-prototype` first and consume its decision receipt without transcript replay.
• The user wants a pure source lookup, citation check, or paper explanation with no implementation plan.
• The unresolved work is repository terminology alignment or a project-language decision frontier; use `context` before planning.

Examples

Good example:

• Prompt: $ralplan turn this risky refactor into a reviewable plan with acceptance criteria and verification commands.
• Expected behavior: Produce repo/source facts, alternatives, risk review, acceptance criteria, exact verification commands, and handoff readiness without editing code.
• Why: The request is clear enough to plan but risky enough to require consensus-style review before execution.

Bad example:

• Prompt: $ralplan implement the refactor now and open the PR.
• Expected behavior: Stop at the reviewed plan or route the full delivery cycle to `ultrawork` after plan acceptance.
• Why: Ralplan is a planning gate, not implementation, review, CI, or PR evidence.

Completion Checklist

• The plan todo was declared before the first planning step and every stage reached a terminal state; a plan produced without one, or with stages still pending, is not finished.
• Observed repo facts and source/web evidence gaps are named.
• At least two options or one chosen option plus rejected alternatives are recorded.
• Risks, acceptance criteria, and verification commands are testable or explicitly blocked.
• The plan exists as a recorded file-backed artifact, not only as chat narration.
• The implementation handoff is prepared only after plan acceptance and remains prepared_not_observed.
• The follow-on engine or executor path was started only after the user's explicit go-ahead in this conversation, never from plan acceptance alone.

Recovery Notes

• If requirements are still fuzzy, route back to deep-interview before planning.
• If current-source evidence is missing, route a `research` step before accepting the plan.
• If the user asks for implementation after acceptance, recommend the follow-on path that fits the work's shape (`ultrawork` with the matching capability — durable checkpoint, coordinated lanes, single-owner persistence, or one delivery cycle — or a direct selected executor handoff) with a one-line fit reason, and start it only on the user's explicit go-ahead — never auto-start an engine from acceptance alone.

Workflow Lane

• Current lane: **Intent -> plan** (`oh-my-hermes`, `meta-router`, `deep-interview`, `context`, `plan`, `ralplan`, `adversarial-consensus`, `codebase-onboarding`, `+8 more`) - clarify, plan, ship, or loop goals.
• If intent belongs to another lane, hand back to `oh-my-hermes` or name the adjacent workflow.
• Shared product, routing, compatibility, and evidence rules: `omh-routing/references/skill-common-rail.md`.

Use When

Use when requirements are clear enough for planning but architecture, evidence, alternatives, risks, or tests need a reviewed plan before execution.

Strong routing signals: `ralplan`, `$ralplan`, `consensus plan`, `reviewed plan`, `issue to PR`, `acceptance criteria`, `verification command`, `reviewable PR`, `risky planning`, `dangerous planning`, `unsafe change`, `refactor safety`, `PR로 만들`, `PR로 만들 수 있게`, `위험한 리팩터링`, `리팩터링 위험`, `리스크 있는 리팩터링`, `검증 command`, `리뷰 가능한 단위`, `코드베이스 조사`, `웹리서치 계획`, `대안 비교`, `리스크 검토`

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 freshne