Safe Refactor

Use this skill to make one coherent behavior-preserving refactor whose value is justified by improved simplicity, maintainability, correctness resilience, performance, type safety, testability, or boundary clarity.

Prefer the highest-value refactor that can be safely bounded, staged, tested, and validated. The refactor does not need to be tiny, but every touched file should serve one architectural goal. A successful run may either implement a safe refactor or stop with a concrete recommendation when the best opportunity is too broad and no independently valuable first stage exists.

Workflow

0. Check Starting State

Start by reading repo instructions and required docs. Check worktree status before editing.

If tracked files are already modified, do not start code edits without user confirmation. Report the modified files, whether they appear related to the intended refactor, overlap risk, and your recommended action. You may still inspect code and propose candidates. You may proceed without confirmation only when existing changes are clearly unrelated untracked/generated artifacts and the refactor will not touch or depend on them.

Follow repo branch conventions. For larger refactors, mention branch status before editing, but do not create branches unless repo rules or the user require it.

1. Find a High-Value Bounded Candidate

Inspect nearby code and tests before proposing edits. Scout enough to avoid grabbing the first easy cleanup.