refactor
Refactor Workflow Skill
Overview
Two-track workflow for improving existing code. Polish track for small, contained refactors; overhaul track for architectural changes and migrations. Both tracks emphasize exploration before commitment and mandatory documentation updates.
Triggers
Activate this skill when:
- User runs
/exarchos:refactorcommand - User wants to improve existing code structure
- User mentions "refactor", "restructure", "clean up", "migrate"
- User asks to "move", "extract", "rename", or "reorganize" code
Disambiguation: If the user says "fix" or "clean up" — use /exarchos:refactor when the code works but needs structural improvement. Use /exarchos:debug when something is broken (error, crash, wrong behavior).
Workflow Overview
/exarchos:refactor
|
+-----+-----+
| Explore |
+-----+-----+
|
+--------------+--------------+
| |
--polish (default)
| |
v v
+--------------+ +--------------+
| Polish | | Overhaul |
| Track | | Track |
+--------------+ +--------------+
Command Interface
Start Refactor Workflow
# Default: overhaul track
/exarchos:refactor "Description of what needs refactoring"
# Fast path: polish track
/exarchos:refactor --polish "Small contained refactor description"
# Explore first, then decide track
/exarchos:refactor --explore "Unsure of scope, explore first"
Mid-Workflow Commands
# Switch from polish to overhaul (during explore/brief)
/exarchos:refactor --switch-overhaul
# Resume after context compaction
/exarchos:rehydrate
Track Comparison
| Aspect | Polish | Overhaul |
|---|---|---|
| Scope | <=5 files, single concern | No limit |
| Worktree | No (direct) | Yes (isolated) |
| Delegation | No | Yes (full workflow) |
| Documentation | Mandatory update phase | Mandatory update phase |
| Human Checkpoints | 0 | 1 (merge) |
Characterization Testing (Both Tracks)
Before modifying any existing code behavior, capture current behavior as characterization tests. This is a mandatory pre-step for both tracks:
- Before changes: Write tests that document what the code currently does (not what it should do). Exercise the code through the most appropriate observable seam (API, CLI, integration boundary, or function) with representative inputs and assert on actual outputs/effects.
- During changes: Any characterization test failure means behavior changed. Evaluate: intentional or accidental?
- After changes: Document which characterization test failures were expected. Remaining characterization tests become regression tests.
This aligns with Michael Feathers' approach in Working Effectively with Legacy Code — understand behavior before changing it.
Polish Track
Fast path for small, contained refactors (<=5 files, single concern). Orchestrator may write code directly (exception to orchestrator constraints). No worktree, no delegation.
HSM phases: explore → brief → polish-implement → polish-validate → polish-update-docs → completed
For detailed phase instructions, state management, and auto-chain behavior, see @skills/refactor/references/polish-track.md.
Overhaul Track
Rigorous path for architectural changes, migrations, and multi-file restructuring. Uses full delegation model with worktree isolation.
HSM phases: explore → brief → overhaul-plan → overhaul-plan-review → overhaul-delegate → overhaul-review → overhaul-update-docs → synthesize → completed
For detailed phase instructions, skill invocations, and auto-chain behavior, see @skills/refactor/references/overhaul-track.md.
State Management
Initialize refactor workflow:
action: "init", featureId: "refactor-<slug>", workflowType: "refactor"
Use describe to discover the full state schema at runtime: exarchos_workflow({ action: "describe", actions: ["init"] }).
Phase Transitions and Guards
Sequential traversal required. Every phase MUST be traversed in order — you cannot skip phases, even if you have all the data for a later phase ready. For example,
exploremust transition tobriefbeforeoverhaul-plan— attemptingexplore→overhaul-plandirectly will be rejected by the HSM. Frombriefyou must go topolish-implementoroverhaul-plan, not directly tocompleted. Each transition requires its guard to be satisfied viaupdatessent alongside thephaseparameter in a singlesetcall. See@skills/refactor/references/polish-track.mdor@skills/refactor/references/overhaul-track.mdfor the exact tool call at each step.
Every phase transition has a guard that must be satisfied. Before transitioning, consult @skills/workflow-state/references/phase-transitions.md for the exact prerequisite for each guard.
The pattern for every transition: send the guard prerequisite in updates and the target in phase in a single set call.
Schema Discovery
Use exarchos_workflow({ action: "describe", actions: ["set", "init"] }) for
parameter schemas and exarchos_workflow({ action: "describe", playbook: "refactor" })
for phase transitions, guards, and playbook guidance.
Decision Runbooks
For track-selection criteria at the explore phase, query the decision runbook:
exarchos_orchestrate({ action: "runbook", id: "scope-decision" })
This runbook provides structured criteria for choosing between polish and overhaul tracks based on file count, structural impact, and PR scope.
Track Switching
If scope expands beyond polish limits during explore or brief phase, use mcp__plugin_exarchos_exarchos__exarchos_workflow with action: "set" to set track to "overhaul" and update explore.scopeAssessment.recommendedTrack.
Scope thresholds: If >5 files affected OR changes cross module boundaries -> recommend overhaul track.
Indicators to switch:
- More than 5 files affected
- Multiple concerns identified
- Cross-module changes needed
- Test coverage gaps require new tests
Output: "Scope expanded beyond polish limits. Switching to overhaul track."
Integration Points
CRITICAL: All skill invocations MUST use explicit Skill() tool calls:
| Skill | Invocation | Usage |
|---|---|---|
/exarchos:plan |
Skill({ skill: "exarchos:plan", args: "--refactor <state-file>" }) |
Task extraction from brief |
/exarchos:delegate |
Skill({ skill: "exarchos:delegate", args: "<state-file>" }) |
Subagent dispatch for TDD |
/exarchos:review |
Skill({ skill: "exarchos:review", args: "<state-file>" }) |
Quality review |
/exarchos:synthesize |
Skill({ skill: "exarchos:synthesize", args: "<feature>" }) |
PR creation |
Anti-Patterns
| Don't | Do Instead |
|---|---|
| Skip exploration | Always assess scope first (see references/explore-checklist.md) |
| Use polish for large changes | Switch to overhaul when scope expands |
| Skip doc updates | Documentation is mandatory (see references/doc-update-checklist.md) |
| Add features during refactor | Scope creep - stick to brief goals |
| Skip tests because "just moving code" | Refactors need test verification |
| Create design document for polish | Use brief in state file instead |
| Work in main for overhaul | Use worktree isolation |
Exarchos Integration
When Exarchos MCP tools are available, emit events throughout the refactor workflow:
- At workflow start (explore):
mcp__plugin_exarchos_exarchos__exarchos_eventwithaction: "append"→workflow.startedwith workflowType "refactor" - On track selection: Auto-emitted by
exarchos_workflowsetwhenphaseis provided — emitsworkflow.transitionwith selected track (polish/overhaul) - On each phase transition: Auto-emitted by
exarchos_workflowsetwhenphaseis provided — emitsworkflow.transitionwith from/to/trigger/featureId - Overhaul track stacking: Handled by
/exarchos:delegate(subagents usegit commit+git pushper implementer prompt) - Polish track commit: Single
git commit -m "refactor: <description>"+git push— no multi-branch stacking needed - On complete: Auto-emitted by
exarchos_workflowsetwhen transitioning to terminal state — emitsworkflow.transitionto "completed"
More from lvlup-sw/exarchos
cleanup
Post-merge workflow resolution. Verifies PR merge status, backfills synthesis metadata, force-resolves review statuses, transitions to completed, and cleans up worktrees/branches. Use when the user says 'cleanup', 'resolve workflow', 'mark as done', or runs /cleanup. Do NOT use before PRs are merged.
27xml-tags
A skill with <xml-tag> characters in the description.
26shepherd
Shepherd PRs through CI and reviews to merge readiness. Operates as an iteration loop within the synthesize phase (not a separate HSM phase). Uses assess_stack to check PR health, fix failures, and request approval. Triggers: 'shepherd', 'tend PRs', 'check CI', or /shepherd.
26dogfood
Review failed Exarchos MCP tool calls from the current session, diagnose root causes, and categorize into code bug, documentation issue, or user error. Use when the user says 'dogfood', 'review failures', 'what went wrong', 'triage errors', or runs /dogfood. Scopes exclusively to Exarchos tools (exarchos_workflow, exarchos_event, exarchos_orchestrate, exarchos_view, exarchos_sync). Do NOT use for debugging application code or non-Exarchos tool failures.
26debug
Bug investigation and fix workflow. Triggers: 'debug', 'fix bug', 'investigate issue', 'something is broken', or /debug. Hotfix track for quick fixes, thorough track for root cause analysis. Do NOT use for feature development or refactoring. Do NOT escalate to /ideate unless the fix requires architectural redesign.
26broken-reference
A skill with a broken reference link.
26