Refactor

Use for structural refactors. Use simplify-implementation for local readability, dead code, or small logic cleanup.

Rules

Preserve behavior and public contracts unless changes are explicit.
Classify first: small = local/no public movement; medium = multi-file/extraction/boundary/export touch; large = package/cross-package/staged migration/broad consumers.
For medium/large refactors, write a brief before editing: evidence, pressure, remaining delta, do/defer/avoid ranking, non-goals, contracts, target shape, validation, compatibility.
Do not propose target trees without current-code evidence: tree, file size/mixed concerns, imports/exports, consumers, validation commands.
Separate moves/renames from logic changes and design/API behavior questions.
Prefer existing conventions, provider locality, and the smallest structure that solves observed pressure.
Subtract before adding: remove dead wrappers, redundant validators, stale exports, and unused paths before introducing new structure.
Avoid taste refactors, premature abstractions, and thin one-file directories unless staged or conventional.
Validate with fresh command output.