refactor

Survey git history and tests to identify and execute behavior-preserving refactors.

8|1|Updated Jul 2, 2026
One-click install
npx skills add https://github.com/duthaho/skillhub --skill refactor-duthaho
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: refactor
Source: https://github.com/duthaho/skillhub/tree/main/.claude/skills/refactor
Command: npx skills add https://github.com/duthaho/skillhub --skill refactor-duthaho

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill helps you decide where refactoring is actually worth the effort, instead of cleaning code just because it looks messy. It uses evidence like churn, recurring bugs, and upcoming work to separate real structural debt from harmless ugliness.

Core Features & Use Cases

  • Evidence-based survey: Identifies refactor candidates from git churn, complexity, bug logs, and planned work.
  • Safe execution: Performs behavior-preserving changes in small steps, with tests as the arbiter after each move.
  • Decision support: Classifies areas as REFACTOR, PREP, LEAVE, or WATCH and records the rationale in a tracker.
  • Use case: Ask for a refactor review on a codebase, then apply only the approved candidate with a green test baseline.

Quick Start

Ask the skill to survey your repository and recommend the one refactor that will pay off most without changing behavior.

Frequently Asked Questions about refactor

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I identify which parts of my codebase actually need refactoring?

Codebase refactoring targets should be identified using evidence like git churn, recurring bug logs, and planned upcoming work. This approach separates structural debt from harmless ugliness, ensuring effort is spent only where it pays off.

What is the best way to refactor code without changing its behavior?

Behavior-preserving refactoring requires executing structural improvements in small, incremental steps. Tests must act as the arbiter after each move to validate that original functionality remains completely intact throughout the process.

How do I use git history to find technical debt hotspots for refactoring?

Git history analysis identifies technical debt hotspots by evaluating code churn and complexity. Surveying these hotspots alongside recurring bugs reveals evidence-backed refactoring opportunities rather than aesthetic-only cleanup.

When should I avoid refactoring messy code?

You should avoid refactoring messy code when changes are purely aesthetic. If evidence like git churn, recurring bugs, or upcoming planned work does not justify the effort, the area should be classified as LEAVE rather than REFACTOR.

How do I track refactoring decisions and rationale in my software project?

Refactoring decisions are tracked by classifying code areas as REFACTOR, PREP, LEAVE, or WATCH. Recording this classification and underlying evidence in a tracker preserves behavior and documents structural debt decisions.