← ClaudeAtlas

refactor-javalisted

Comprehensive catalog of 60+ Java refactoring techniques for behavior-preserving code improvements. Trigger when the task is Java refactoring, code-smell cleanup, restructuring, API-compatible design improvement, or a named refactoring technique. This skill is the right lazy-load signal when the worker must preserve observable behavior, check public-contract compatibility, apply useful-only JavaDoc, and produce one Java Refactor Quality Gate verdict. Covers Java 8 and Java 11+ examples for every technique. Even if the user just pastes Java code and asks for improvement suggestions, use this skill to identify applicable techniques. También se activa en castellano: "refactorizar", "refactorizar código Java", "mejorar este código", "malos olores del código", "olores de código", "código sucio", "limpiar código", "simplificar condicionales", "principios SOLID", "cómo mejorar este código", "código limpio", "reestructurar clase", "mejorar calidad del código", "técnica de refactorización", "extraer método", "renombra
andresnator/agents-orchestrator · ★ 0 · Code & Development · score 64
Install: claude install-skill andresnator/agents-orchestrator
# Java Refactoring Catalog Skill A comprehensive, technique-by-technique catalog of refactoring best practices for Java, sourced from Martin Fowler's *Refactoring: Improving the Design of Existing Code* (2nd Edition) and Alexander Shvets' *Refactoring in Java* (Refactoring Guru). ## Core Philosophy **Refactoring is the process of changing the internal structure of code without altering its observable behavior.** It is a disciplined technique, not a random cleanup. The golden rule is: Cover → Modify → Refactor (always have tests before you start). ## Java Refactor Quality Gate Before declaring a Java refactor complete, review the result against this gate: - **Behavior preservation**: no bug fix or externally observable behavior change is mixed into the refactor. - **Readability and naming**: names explain intent; extracted methods/classes reduce cognitive load rather than hiding simple code. - **Cohesion**: moved or extracted code belongs with the data and behavior that change together. - **SOLID restraint**: apply SOLID principles only where real change pressure exists; avoid mechanical abstractions. - **Pragmatic patterns**: choose the simplest design that handles known variation; do not introduce a pattern by default. - **API compatibility**: public signatures, visibility, mutability, serialization, and caller contracts are preserved unless the task explicitly allows an API change. - **Exception robustness**: do not swallow exceptions, broaden them unnecessarily, or u