Refactor code following principles, patterns, and best practices from respected literature
Scanned 9/20/2026
Install to Claude Code
npx -y skills add tstapler/dotfiles --skill refactor --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Refactor?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/tstapler-refactor)More formats (shields.io, HTML) on the badges page.
---
description: Refactor code following principles, patterns, and best practices from respected literature
---
# Code Refactoring Guide
I'll help you refactor code by applying established software engineering principles, design patterns, and best practices from highly regarded literature and academic research. The refactoring will adapt the code to follow idioms and conventions specific to $1 or the detected language if no target language is specified.
## Refactoring Process
0. **Tidy First? Decision** (Kent Beck) — before selecting techniques, decide *when* this structural work pays for itself:
- **First** — do it now, immediately before the behavior change it's blocking or de-risking
- **After** — do it right after the behavior change that revealed the mess, while it's fresh
- **Later** — it's not blocking anything urgent; note it and batch it for a dedicated pass instead of doing it now
- **Never** — the code won't be touched again, or the cost of tidying exceeds what it buys back; leave it
- Whatever the answer, keep this structural work in its own commit(s), never mixed with a behavior change — see Implementation Phase below
1. **Analysis Phase**
- Identify code smells using Martin Fowler's classification
- Assess current design patterns and architectural approach
- Evaluate complexity using metrics (cyclomatic complexity, coupling, cohesion)
- Detect potential technical debt indicators
2. **Planning Phase**
- Select appropriate refactoring techniques from Fowler's catalog
- Identify applicable design patterns from GoF or modern equivalents
- Consider enterprise patterns and domain-driven design principles where appropriate
- Determine language-specific idioms and best practices to apply
- Plan refactoring sequence to maintain behavior while transforming structure
3. **Implementation Phase**
- Apply refactoring transformations systematically
- Incorporate language-specific idioms and conventions
- Implement selected design patterns where appropriate
- Improve naming, comments, and documentation
- **Keep structural changes in their own commit(s), separate from any behavior change** — even one done to enable the other (see `git:commit`)
4. **Validation Phase**
- Ensure behavior preservation (suggest tests if absent)
- Verify adherence to SOLID principles
- Confirm improved readability and maintainability
- Validate language-specific best practices
## Principles Applied
- **SOLID Principles** (Robert C. Martin)
- Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, Dependency Inversion
- **Clean Code Practices** (Robert C. Martin)
- Meaningful names, small functions, DRY principle, comment purposefully
- **Design Patterns** (Gang of Four + Modern Patterns)
- Creational, Structural, and Behavioral patterns as appropriate
- **Enterprise Application Patterns** (Martin Fowler)
- Domain Logic patterns (Domain Model, Transaction Script)
- Data Source Architectural patterns (Table Data Gateway, Active Record, Data Mapper)
- Object-Relational Behavioral/Structural patterns (Identity Map, Unit of Work, Lazy Load)
- Web Presentation patterns (MVC, Front Controller, Template View)
- **Domain-Driven Design Principles** (Eric Evans)
- Ubiquitous Language and Bounded Contexts
- Strategic Design with Context Maps
- Tactical Design with Aggregates, Entities, Value Objects
- Domain Events and Event Sourcing
- **Code Quality Metrics**
- Reduced complexity, improved cohesion, decreased coupling
- Language-specific performance considerations
- **Technical Debt Reduction** (Ward Cunningham concept)
- Identifying and addressing deliberate and inadvertent technical debt
## Language-Specific Considerations
I'll adapt the refactoring to follow $1-specific (or detected language) idioms, including:
- Language-specific design patterns
- Standard library utilization
- Performance optimizations
- Community-established conventions
- Modern language features
## Academic and Industry References
- "Refactoring: Improving the Design of Existing Code" (Martin Fowler)
- "Tidy First?: A Personal Exercise in Empirical Software Design" (Kent Beck) — the First/After/Later/Never timing decision, and the discipline of never mixing structural and behavioral changes in one commit
- "Clean Code: A Handbook of Agile Software Craftsmanship" (Robert C. Martin)
- "Design Patterns: Elements of Reusable Object-Oriented Software" (Gamma, Helm, Johnson, Vlissides)
- "Working Effectively with Legacy Code" (Michael Feathers)
- "Patterns of Enterprise Application Architecture" (Martin Fowler)
- "Domain-Driven Design: Tackling Complexity in the Heart of Software" (Eric Evans)
- "Implementing Domain-Driven Design" (Vaughn Vernon)
- "A Philosophy of Software Design" (John Ousterhout)
- "Clean Architecture: A Craftsman's Guide to Software Structure and Design" (Robert C. Martin)
- "Building Evolutionary Architectures" (Neal Ford, Rebecca Parsons, Patrick Kua)
- Relevant language-specific style guides and research papers
Let me analyze your code and provide a comprehensive refactoring that preserves behavior while improving design, readability, and maintainability according to established principles and $1-specific best practices.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!