Quality
Install
Extracted Skills
Big Refactoring Planner
Plan and execute architectural-scale refactoring campaigns that take weeks to months — the four named patterns for large-scale structural restructuring from Fowler and Beck's Chapter 12. Use when: an inheritance hierarchy is doing two distinct jobs and subclass names share the same adjective prefix at every level (Tease Apart Inheritance); a codebase written in an object-oriented language uses a procedural style with long methods on behavior-less classes and dumb data objects (Convert Procedural Design to Objects); GUI or window classes contain SQL queries, business rules, or pricing logic instead of just display code (Separate Domain from Presentation); a single class has accumulated so many conditional statements that every new case requires editing the same class in multiple places (Extract Hierarchy). Applies when code-smell-diagnosis has surfaced Parallel Inheritance Hierarchies, Data Class, or Large Class with deep conditional branching and the fix is too large for a single refactoring session. Distinguishes between the four patterns by structural signal, selects the correct pattern and variant, and produces a multi-week campaign plan with interleaved feature development milestones.
Build Refactoring Test Suite
Build a sufficient automated test suite before refactoring existing code by applying a 6-step sequential construction workflow (test class → fixture → normal behavior → boundary conditions → expected errors → green-suite gate) and a bug-fix variant (write failing test first → reproduce → fix → verify green). Use this skill when you are about to refactor a class or module that lacks tests, when a bug report arrives and you need to pin it down before fixing it, when you want to establish the compile-and-test gate that makes every subsequent refactoring step safe to revert, or when you need to assess whether an existing test suite is adequate to protect a planned refactoring.
Class Responsibility Realignment
Redistribute methods and fields to the classes that own them, repair broken inheritance hierarchies, and extend unmodifiable library classes. Use when: a method uses another class's data far more than its own (Feature Envy — the method belongs in the other class); a single logical change forces edits across many files (Shotgun Surgery — scattered behavior needs consolidation); a class delegates half or more of its methods without adding value (Middle Man — remove the hollow layer or collapse it into inheritance); two classes share too much private knowledge about each other (Inappropriate Intimacy — separate the entangled pieces); a recurring group of fields travels together across class boundaries (Data Clumps — extract the group into its own class); a class has grown to serve two distinct responsibilities that change for different reasons (Extract Class — split it); a class that used to have a purpose has been refactored down to almost nothing (Inline Class — absorb it into its most active collaborator). For inheritance hierarchies: move common behavior upward (Pull Up Method, Pull Up Field) when subclasses duplicate it; push specialized behavior downward (Push Down Method, Push Down Field, Extract Subclass) when only some subclasses need it; create a shared abstraction over two similar but unrelated classes (Extract Superclass); extract a protocol-only contract (Extract Interface) when clients use only a subset of the class; merge a hierarchy that has converged (Collapse Hierarchy); move similar-but-not-identical subclass methods into a common template (Form Template Method); swap inheritance for delegation (Replace Inheritance with Delegation) when a subclass uses only part of the superclass interface or inherits inappropriate data; swap back (Replace Delegation with Inheritance) when the delegation covers the full interface and adds no control. For unmodifiable library classes: add one or two methods as foreign methods in the client class; add many methods via a local extension (subclass or wrapper). Decision rule for encapsulation balance: Hide Delegate to shield clients from internal structure; Remove Middle Man when the delegating layer has grown hollow. Decision rule for inheritance vs delegation: use Extract Subclass when variation is fixed at construction time and single-dimensional; use Extract Class (delegation) when variation is runtime-flexible or multi-dimensional — "if you want the class to vary in several different ways, you have to use delegation for all but one of them."
Code Smell Diagnosis
Scan a codebase or code fragment for the 22 named code smells from Fowler's refactoring catalog and produce a prioritized diagnosis report with the specific refactoring prescription for each smell. Use when: a developer wants to know what is wrong with existing code before touching it; a code review reveals structural problems but no clear fix; a class or method feels wrong but the exact smell is hard to name; a refactoring effort needs a starting point and a prioritized order of attack; a code author wants to justify a refactoring to a team by naming the specific smell and the prescribed remedy. Covers all 22 smells: Duplicated Code, Long Method, Large Class, Long Parameter List, Divergent Change, Shotgun Surgery, Feature Envy, Data Clumps, Primitive Obsession, Switch Statements, Parallel Inheritance Hierarchies, Lazy Class, Speculative Generality, Temporary Field, Message Chains, Middle Man, Inappropriate Intimacy, Alternative Classes with Different Interfaces, Incomplete Library Class, Data Class, Refused Bequest, Comments. Maps each smell to its Fowler-prescribed refactoring(s) including conditional branches (same class vs. sibling subclasses vs. unrelated classes for Duplicated Code; few cases vs. type code vs. null for Switch Statements; etc.).
Conditional Simplification Strategy
Select and apply the correct refactoring for complex or tangled conditional logic. Use when: a method has a complicated if-then-else that obscures why branching happens (not just what happens); a series of conditions all produce the same result; the same code fragment appears inside every branch; a boolean variable is being used as a control flag to track loop state; nested conditionals bury the normal execution path under special-case checks; a switch statement (or long if-else-if chain) branches on an object's type and new types are expected; a method's parameter controls which of several distinct operations runs; null checks are scattered throughout client code for the same object. Covers all 8 conditional refactorings from Fowler Chapter 9: Decompose Conditional, Consolidate Conditional Expression, Consolidate Duplicate Conditional Fragments, Remove Control Flag, Replace Nested Conditional with Guard Clauses, Replace Conditional with Polymorphism, Replace Parameter with Explicit Methods, Introduce Null Object. Also covers the supporting technique Introduce Assertion for making implicit state assumptions explicit. Includes the key semantic distinction between guard clauses (rare special cases that exit) and if-else (equal-weight alternatives), and Fowler's rejection of the single-exit-point rule as a reason to avoid early returns.
Data Organization Refactoring
Apply the correct data organization refactoring when code smells in data structure design are diagnosed — Primitive Obsession, Data Clumps, Data Class, or raw structural anti-patterns like magic numbers, positional arrays, and naked public fields. Covers the full Chapter 8 catalog: Replace Data Value with Object (primitive → first-class object); Change Value to Reference / Change Reference to Value (value vs. reference object decision); Self Encapsulate Field (internal field access via accessors); Encapsulate Field (public → private with accessors); Encapsulate Collection (raw collection → controlled add/remove protocol); Replace Array with Object (positional array → named-field object); Replace Magic Number with Symbolic Constant; Replace Record with Data Class (legacy record → typed wrapper); Duplicate Observed Data (domain data trapped in GUI → domain class + observer sync); Change Unidirectional Association to Bidirectional (one-way link → two-way when both ends need navigation); Change Bidirectional Association to Unidirectional (drop unnecessary back pointer). Use when: a field stores a raw primitive (string, int) but has behavior waiting to happen (formatting, validation, comparison); the same 2-4 data items travel together through method signatures and field lists (Data Clumps); a class exists only as a getter/setter bag with no behavior (Data Class); a collection field is exposed so callers can mutate it directly; positional arrays or records need to cross the boundary into object-oriented design; a numeric literal with special meaning appears in more than one place; a GUI class owns domain data that business methods need; a one-way association is insufficient or a two-way association has become unnecessarily complex. Type code refactorings (Replace Type Code with Class/Subclasses/State-Strategy) are handled by the sibling skill `type-code-refactoring-selector`.
Method Decomposition Refactoring
Decompose long, tangled methods into clean, composable units using the 9 composing-method refactorings from Fowler's catalog. Use when: a method has grown too long to understand at a glance; code contains a comment that explains what a block does (the comment is a signal to extract); a method cannot be changed without understanding all of its internals; local variables are so numerous that Extract Method keeps failing; a method is doing several conceptually distinct things that are collapsed into one body. The flagship technique is Extract Method — applied when the semantic distance between the method name and its body is too large; name the fragment after what it does, not how it does it. Companion techniques handle the obstacles: Replace Temp with Query eliminates the local variables that block extraction; Split Temporary Variable separates a temp that has been reused for two different things; Introduce Explaining Variable names a sub-expression when extraction is blocked by too many locals; Remove Assignments to Parameters prevents a parameter from being reassigned and muddying the intent; Inline Method collapses a method whose body is as clear as its name; Inline Temp removes a temp that obstructs another refactoring; Replace Method with Method Object converts a hopelessly entangled method into its own class so that Extract Method can be applied freely; Substitute Algorithm replaces an obscure implementation with a cleaner one once the method is small enough. Trigger: Long Method smell from code-smell-diagnosis, or any method where a comment is needed to understand a code block.
Profiling Driven Performance Optimization
Optimize code performance by first refactoring to a well-factored structure, then running a profiler to find actual hot spots, and applying targeted optimizations only where the profiler points — never by guessing. Use this skill when users report the program is too slow, before any performance work begins on an unfactored codebase, or after refactoring is complete and performance must now be tuned to acceptable levels.
Refactoring Readiness Assessment
Assess whether a codebase situation warrants refactoring and determine the right approach before any structural changes begin. Use this skill when a developer is about to modify existing code and needs to decide: should I refactor first, refactor not at all, or rewrite entirely? Triggers include: developer is adding a feature and the existing code is hard to understand or extend; developer just received a bug report and suspects the code structure is hiding more bugs; a code review has surfaced design concerns and the team wants concrete guidance; code appears to have been copied more than twice in similar form; developer is unsure whether to clean up code before a deadline; codebase uses a published interface or is tightly coupled to a database schema and the developer wants to know the constraints before restructuring; developer suspects the code is so broken it cannot be stabilized without a full rewrite. This skill produces a structured go/no-go assessment and session plan — it does not apply any refactoring itself. Use code-smell-diagnosis after this skill to identify specific smells, then individual refactoring skills to apply transformations.
Type Code Refactoring Selector
Select and execute the correct refactoring path for type codes — enumerations, integer constants, or string tags that flag object variants (e.g., ENGINEER/SALESMAN/MANAGER as ints, blood group as 0/1/2/3, ORDER_STATUS as strings). Applies Fowler's three-way decision tree to pick between Replace Type Code with Class, Replace Type Code with Subclasses, and Replace Type Code with State/Strategy, then drives the full mechanics for the chosen path through to Replace Conditional with Polymorphism. Use when: a class stores an integer or enum constant that controls conditional behavior in switch statements or if-else chains scattered across multiple methods or callers; Primitive Obsession or Switch Statements smells have been diagnosed and the root cause is a type code; a new variant keeps requiring edits in multiple places (classic signal that polymorphism is needed); a type code is passed between classes as a raw integer, weakening type safety and allowing invalid values; subclasses exist that vary only in constant return values (reverse path: Replace Subclass with Fields). Also covers the exceptions: use Replace Parameter with Explicit Methods instead of polymorphism when the switch affects only a single method and variants are stable; use Introduce Null Object when one of the cases is null.