/omh-refactor-plan

name: "omh-refactor-plan"
description: "[omh] Decided cross-module refactor to phase: refactor planning - turn a decided boundary-changing refactor into a phased plan - reconnaissance, contracts-first phase order, per-phase verification and rollback, a files table, and an explicit approval gate before any edit. Use when the user says: refactor-plan, refactor plan, plan this refactor, plan the refactor, refactor planning, refactor phases, phased refactor, refactor in phases."
metadata:
  hermes:
    tags: [workflow, oh-my-hermes, planning]
    category: planning
    phase: refactor-plan
    role: planner
    quality_tier: plan-gated

Refactor Plan

This is a Hermes-native `refactor-plan` workflow skill.

Why This Exists

`refactor-plan` exists because boundary-changing refactors bounced between goal planning and behavior-preserving cleanup with neither owning the execution shape: the phase order, the per-phase rollback, and the files table that make a large refactor reviewable and abortable.

Do Not Use When

• The refactor's direction is still contested or the goal itself needs consensus planning; use `ralplan`.
• The work is deletion-first cleanup with no boundary changes; use `ai-slop-cleaner`.
• The plan is done and the claim is that work is complete; use `verification-gate` for the evidence close.
• The version bump carries a security advisory, a CVE, or a leaked secret; use `security-event-response`, which owns containment and closure.

Examples

Good example:

• Prompt: We decided to split the billing module out of orders - plan the refactor so each step is shippable.
• Expected behavior: Map affected files and consumers from the import graph, name hidden coupling and blast radius, order the five phases with per-phase verification and rollback, ship the files table, and stop at the approval gate.
• Why: The direction is decided and the need is a phased, abortable execution shape - exactly this workflow's territory.

Bad example:

• Prompt: Should we even split billing out of orders?
• Expected behavior: Route to `ralplan`: the direction is not decided, so consensus planning comes before phase planning.
• Why: A phase plan for a contested direction launders a decision through logistics.

Completion Checklist

• Reconnaissance names affected files, boundaries, coupling, and blast radius from observed evidence.
• Every phase carries its verification command and its rollback point, and ends at a shippable commit.
• The files table covers every touched file with action, phase, and dependencies.
• For an upgrade, every breaking change row names its call sites or an observed empty search, and every stage names its rollback.
• The plan stopped at the approval gate; no implementation began without the user's go.

Recovery Notes

• If the import graph is unavailable, build the codegraph first or reduce the plan's confidence and say which files are unverified.
• If a phase cannot be made independently green, split it further; two half-phases beat one unabortable one.
• If reconnaissance finds the direction itself is unsettled, route back to `ralplan` before ordering phases.

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 a refactor that crosses module boundaries is already decided and needs its execution shaped: which files move in which phase, what verifies each phase, and where each phase rolls back to - before anything is edited.

Strong routing signals: `refactor-plan`, `refactor plan`, `plan this refactor`, `plan the refactor`, `refactor planning`, `refactor phases`, `phased refactor`, `refactor in phases`, `refactor rollback plan`, `blast radius`, `module restructure plan`, `restructure plan`, `dependency upgrade`, `major version upgrade`, `framework upgrade`, `upgrade to the next major`, `breaking change upgrade`, `lockfile`, `리팩터링 계획`, `리팩토링 계획`, `리팩터링 단계`, `단계별 리팩터링`, `리팩터링 계획 세워줘`, `리팩터링 롤백 계획`

Catalog Metadata

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

Quality bar:

• Reconnaissance first: affected files, ownership boundaries, hidden coupling, and blast radius are mapped before any phase is ordered; the full contract is `omh-refactor-plan/references/refactor-phases.md`.
• Order phases contracts-first: types and interfaces, then implementations, then callers in reviewable groups, then tests, then cleanup - and name what verifies each phase and where it rolls back to.
• Ship the files table with the plan: one row per file with action, phase, and blocks/blocked-by; a row without a phase is unplanned work.
• Size verification to the blast radius, not to optimism: a phase touching public surfaces or persisted shapes carries the full gate, not the fast one.
• For a dependency or framework upgrade, read four inputs before ordering phases — advisory and end-of-life intake, the licence delta at the target version, the upstream migration guide item by item against this codebase, and lockfile handling in the same commit as the manifest; a breaking change nobody checked is a gap, not a pass. The full contract is `omh-refactor-plan/references/dependency-upgrade.md`.
• Stop at the approval gate and hand the user the go/no-go, whole plan or first phase.

Handoff policy:

Hermes owns reconnaissance and the phased plan; implementation of any approved phase is coding work for the selected executor lane under its own evidence rules. An approved plan is approval of the order, not evidence any phase ran.

Required inputs:

• the decided target shape (what moves where), or a pointer to t