Improve internal code structure - readability first - without changing observable behavior, through small verified transformations, each gated by a safety net (tests / tooling / types) and committed separately from any behavior change.
Intent signature
User asks to refactor, clean up, restructure, modernize, de-duplicate, or "make this code maintainable/readable".
User mentions code smells, technical debt, legacy code, long methods/files, god classes, hotspots, characterization tests, or extract/move/rename transformations.
User asks "where should we refactor first?" or wants a refactoring plan/priority for a codebase.
When to use
Executing a refactoring on specific files/modules (extract, move, rename, decompose, pattern/idiom alignment)
Preparatory refactoring before a feature ("make the change easy, then make the easy change")
Legacy (brownfield) rescue: seam discovery + characterization tests, then restructuring
Refactoring target selection and prioritization (smells + SATD + hotspot = churn x complexity)
Auditing whether code is safe to refactor now (coverage breadth x mutation strength x flakiness)
When NOT to use
Fixing a reported bug or failing behavior -> use oma-debug (refactoring must not change behavior)
Security/performance/accessibility review or quality audit -> use oma-qa
System design, module boundary decisions, ADRs, convention changes -> use oma-architecture (a convention/pattern change is an architecture decision, not a local refactoring)
DB schema design or migration mechanics -> use oma-db (this skill only plans the expand-contract sequence)
Commit splitting / staging mechanics -> use oma-scm
Performance optimization as a goal -> out of scope by definition (tuning is a side effect, never the objective)
Expected inputs
target: file/module/path, smell report, SATD marker, or the feature request motivating preparatory refactoring
verification: project test command(s) per the tool registry; coverage/mutation tooling if available