refactor
- Repo stars 0
- Author updated Live
- Author repo skills-registry
- Domain
- AI
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @tomevault-io · no license declared
- Token usage
- Moderate
- Setup complexity
- Guided setup
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- Python
- Permissions
-
- Read-only
- Write / modify
- Shell exec
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools，默认拥有全部工具权限。
---
name: refactor
description: | Use when this capability is needed. A comprehensive, technique-by-technique catalog of refacto…
category: ai
runtime: Python
---
# refactor output preview
## PART A: Task fit
- Use case: | Use when this capability is needed. A comprehensive, technique-by-technique catalog of refactoring best practices for any language, sourced from Martin Fowler's Refactoring: Improving the Design of Existing Code (2nd Edition) and Alexander Shvets' Refactoring in Java (Refactoring Guru). Adapted for Python, TypeScript, Go, and Rust with idiomatic example….
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Step 0: Detect Language / Language Support Matrix / Core Philosophy” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “| Use when this capability is needed. A comprehensive, technique-by-technique catalog of refactoring best practices for any language, sourced from Martin Fowler's Refactoring: Improving the Design of Existing Code (2nd Edition) and Alexander Shvets' Refactoring in Java (Refactoring Guru). Adapted for Python, TypeScript, Go, and Rust with idiomatic example…”.
- **02** When the source has headings, the agent prioritizes “Step 0: Detect Language / Language Support Matrix / Core Philosophy” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. Choose the trigger
The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Provide inputs and boundaries
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, run shell commands.
Validate with a small run
Start with a small task and check whether the result follows “Step 0: Detect Language / Language Support Matrix / Core Philosophy”. Inspect diffs, logs, previews, or tests before expanding scope.
Review before delivery
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: refactor
description: | Use when this capability is needed. A comprehensive, technique-by-technique catalog of refacto…
category: ai
source: tomevault-io/skills-registry
---
# refactor
## When to use
- | Use when this capability is needed. A comprehensive, technique-by-technique catalog of refactoring best practices fo…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Step 0: Detect Language / Language Support Matrix / Core Philosophy” and keep inference separate from source facts.
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. Evidence boundary and execution chain
The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "refactor" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Step 0: Detect Language / Language Support Matrix / Core Philosophy
rules -> SKILL.md triggers / order / output contract
runtime -> Python | read files, write/modify files, run shell commands | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
}Refactoring Catalog (Multi-Language)
A comprehensive, technique-by-technique catalog of refactoring best practices for any language, sourced from Martin Fowler's Refactoring: Improving the Design of Existing Code (2nd Edition) and Alexander Shvets' Refactoring in Java (Refactoring Guru). Adapted for Python, TypeScript, Go, and Rust with idiomatic examples.
Step 0: Detect Language
Before applying any technique, detect the project's stack:
| Project File | Language | Idiom Style |
|---|---|---|
pom.xml / build.gradle |
Java | OOP, Stream API |
pyproject.toml / requirements.txt / setup.py |
Python | Duck typing, comprehensions |
package.json + tsconfig.json |
TypeScript | Functional-OOP hybrid |
package.json (no tsconfig) |
JavaScript | Prototype-based, functional |
*.csproj |
C# | OOP, LINQ |
go.mod |
Go | Composition, implicit interfaces |
build.gradle.kts |
Kotlin | OOP + functional |
Gemfile |
Ruby | Duck typing, open classes |
composer.json |
PHP | OOP |
Cargo.toml |
Rust | Ownership, traits, no inheritance |
Package.swift |
Swift | Protocol-oriented |
If the language is Java, apply techniques with Java OOP, Stream API where appropriate, and the project's detected Java version constraints.
Language Support Matrix
| Concept | Python | TypeScript | Go | Rust |
|---|---|---|---|---|
| Class / struct | class |
class |
struct + methods |
struct + impl |
| Inheritance | class Child(Parent) |
extends |
Embedding (no inheritance) | Traits (no inheritance) |
| Interface / contract | Protocol / ABC |
interface |
interface (implicit) |
trait |
| Encapsulation | _private convention |
private keyword |
Unexported (lowercase) | Private by default, pub |
| Polymorphism | Duck typing + ABC | Interfaces + classes | Implicit interfaces | Trait objects + generics |
| Generics | typing.Generic[T] |
<T> |
[T any] |
<T: Trait> |
| Error handling | Exceptions | Exceptions | Error values (error) |
Result<T, E> |
| Null safety | None / Optional[T] |
null / undefined / ? |
nil (zero values) |
Option<T> |
| Collections pipeline | Comprehensions / generators | Array methods (.map, .filter) |
for range (no pipeline) |
Iterator chain (.filter().map()) |
| Pattern matching | match (3.10+) |
switch (no pattern matching) |
switch (no pattern matching) |
match (exhaustive) |
| Factory pattern | @classmethod / module function |
Static method / function | NewXxx() function |
Type::new() associated fn |
| Builder pattern | __init__ + kwargs / dataclass |
Fluent builder class | Functional options | Builder with consuming self |
For detailed concept-to-language mappings, see references/language-idioms.md.
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).
How to Use This Skill
- Detect the language (Step 0 above)
- Diagnose first: Identify the code smell (see
techniques/00-code-smells-diagnostic.md) - Check applicability: See
references/language-applicability.mdfor technique availability per language - Select technique: Each smell maps to one or more refactoring techniques
- Read the technique file: Each technique has multi-language examples (Python, TypeScript, Go, Rust)
- For Java: Use Java OOP/Stream idioms and honor Java 8 versus Java 11+ API availability
- For language idiom mapping: See
references/language-idioms.md - Apply incrementally: Small steps, test after each change, commit frequently
Technique Categories
The techniques are organized in 7 groups. Each technique has its own file in the techniques/ directory.
Group 1: Composing Methods (techniques/01-XX)
Techniques for building clean, well-structured methods. The foundation of all refactoring.
01-extract-method.md— Extract a code fragment into a named function02-inline-method.md— Replace a function call with the function body03-extract-variable.md— Give a name to a complex expression04-inline-variable.md— Remove a variable that adds no clarity05-replace-temp-with-query.md— Replace temp variables with function calls06-replace-method-with-method-object.md— Turn a complex function into its own class/struct07-substitute-algorithm.md— Replace an algorithm with a clearer version
Group 2: Moving Features (techniques/02-XX)
Techniques for placing code where it truly belongs.
08-move-method.md— Move a function to where it has more cohesion09-move-field.md— Move a field to the type that uses it most10-extract-class.md— Split a type with multiple responsibilities11-inline-class.md— Merge a type that does too little12-hide-delegate.md— Encapsulate chain navigation behind a simpler interface13-remove-middle-man.md— Remove unnecessary delegation14-move-statements.md— Move statements into/out of functions, slide statements15-split-loop.md— Separate a loop that does multiple things16-replace-loop-with-pipeline.md— Use declarative pipelines instead of imperative loops17-remove-dead-code.md— Delete unused code
Group 3: Organizing Data (techniques/03-XX)
Techniques for enriching data with behavior and protecting internal state.
18-encapsulate-variable.md— Wrap data access with getters/functions19-encapsulate-record.md— Convert data structures into objects/structs20-encapsulate-collection.md— Protect collections from external mutation21-replace-primitive-with-object.md— Create domain types instead of using raw primitives22-split-variable.md— Give each purpose its own variable23-rename-field.md— Improve field names for clarity24-replace-derived-variable-with-query.md— Calculate values on demand25-change-reference-to-value.md— Make objects immutable (Value Objects)26-change-value-to-reference.md— Share a single instance across consumers27-replace-type-code-with-subclasses.md— Convert type codes to polymorphic hierarchy
Group 4: Simplifying Conditionals (techniques/04-XX)
Techniques for taming conditional complexity.
28-decompose-conditional.md— Name condition and branches29-consolidate-conditional.md— Merge related conditions30-replace-nested-conditional-with-guard-clauses.md— Early returns for special cases31-replace-conditional-with-polymorphism.md— Use polymorphism instead of switch/if-type32-introduce-special-case.md— Null Object pattern for default behavior33-introduce-assertion.md— Document invariants with executable assertions34-replace-control-flag.md— Replace boolean flags with break/return
Group 5: Simplifying Method Calls / API Design (techniques/05-XX)
Techniques for building self-documenting interfaces.
35-change-function-declaration.md— Rename functions and change parameters36-introduce-parameter-object.md— Group related parameters into an object37-parameterize-function.md— Unify similar functions with a parameter38-remove-flag-argument.md— Replace boolean params with named functions39-preserve-whole-object.md— Pass the object instead of extracted values40-replace-parameter-with-query.md— Let the function calculate what it needs41-replace-query-with-parameter.md— Pass value as param for purity/testability42-remove-setting-method.md— Make properties read-only43-replace-constructor-with-factory.md— Use factory functions for flexible creation44-replace-function-with-command.md— Encapsulate function as object45-separate-query-from-modifier.md— CQS: separate reads from writes
Group 6: Dealing with Generalization (techniques/06-XX)
Techniques for refactoring type hierarchies and shared behavior.
46-pull-up-method.md— Move duplicated functions to shared parent/trait/interface47-push-down-method.md— Move specialized functions to specific types48-pull-up-constructor-body.md— Unify constructor/initialization logic49-extract-superclass.md— Create common parent for shared behavior50-extract-interface.md— Define a contract without implementation51-collapse-hierarchy.md— Merge unnecessary hierarchy levels52-form-template-method.md— Template Method pattern53-replace-subclass-with-delegate.md— Composition over inheritance54-replace-superclass-with-delegate.md— Replace extends with has-a55-replace-inheritance-with-delegation.md— General inheritance to delegation
Group 7: Additional Techniques (techniques/07-XX)
Cross-cutting techniques from both sources.
56-combine-functions-into-class.md— Group functions that share data57-combine-functions-into-transform.md— Enrich read-only data58-split-phase.md— Separate code into processing phases59-introduce-foreign-method.md— Extend third-party types you can't modify60-introduce-local-extension.md— Wrapper or subclass for library extension61-replace-error-code-with-exception.md— Modernize error handling62-replace-exception-with-test.md— Don't use exceptions for control flow
Diagnostic Guide
Start with techniques/00-code-smells-diagnostic.md to identify which techniques apply to your code. The diagnostic maps 24 code smells to their recommended refactoring techniques.
Applying the Skill
When given code to refactor:
- Detect the language (Step 0)
- Read
techniques/00-code-smells-diagnostic.mdto identify the smells present - For each identified smell, read the corresponding technique file(s)
- Check
references/language-applicability.md— if the technique doesn't apply to the target language, the table shows the alternative - Apply techniques in small steps, always testing between changes
- Provide idiomatic examples for the detected language
- Explain WHY each refactoring improves the code, not just HOW to do it
- For language-specific idiom translations, consult
references/language-idioms.md
Key Principles
These principles underpin every technique in the catalog:
- Names matter more than length — a well-named 1-line function is better than an inline expression
- Small steps — extract small fragments, test, commit. Never batch multiple changes
- Intention over implementation — code should communicate WHAT, not HOW
- Data and logic that change together should live together — cohesion is king
- Prefer composition over inheritance — delegation is more flexible than extends
- Immutability is a powerful preservative — immutable data is easier to reason about
- CQS (Command-Query Separation) — a function either returns a value or modifies state, never both
Reference Files
| File | Content |
|---|---|
references/language-idioms.md |
Refactoring concept → {Python, TypeScript, Go, Rust} equivalents |
references/language-applicability.md |
62-technique × language applicability matrix with alternatives |
Source: andresnator/agents-orchestrator — distributed by TomeVault.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review