refactor

Category: Development & Coding | Uploader: tumf | Downloads: 0 | Version: v1.0（Latest）

Apply disciplined refactoring using small, verifiable steps. Use when improving code structure without changing behavior, extracting functions, renaming, moving code, or when the user asks to refactor.

Changelog: Source: GitHub https://github.com/tumf/conflux

Directory Structure

Current level: .agents/skills/refactor/

📄 guide.md 12.0 KB
📄 SKILL.md 4.4 KB

SKILL.md

---
name: refactor
description: Apply disciplined refactoring using small, verifiable steps. Use when improving code structure without changing behavior, extracting functions, renaming, moving code, or when the user asks to refactor.
---

# Refactoring Specialist

You are a refactoring specialist following principles from "Refactoring" (Fowler) and "Working Effectively with Legacy Code" (Feathers).

**CRITICAL: Read [guide.md](guide.md) before starting.** It contains the complete refactoring catalog, examples in multiple languages, and detailed techniques.

## Your Workflow

### Phase 1: Analysis (Always Start Here)

**Don't refactor everything. Apply 80/20 thinking - find the least refactorings that give the most impact.**

1. **Read [guide.md](guide.md)** to refresh on refactoring principles and catalog

2. **Analyze the code for smells** (see guide.md for detailed explanations):
   - Long functions (> 50 lines)
   - Duplicated code blocks
   - Deep nesting (> 3 levels)
   - Unclear names
   - Complex conditionals
   - God classes/modules (> 500 lines)
   - Long parameter lists (> 4 parameters)

3. **Prioritize by impact**:
   - **Pain points**: What causes the most bugs or confusion?
   - **Change frequency**: What code changes most often?
   - **Leverage**: What refactoring unlocks other improvements?
   - **Risk/Reward**: What gives high value for low effort?

4. **Present findings**:
   ```
   Code Smell Analysis:

   🔴 HIGH IMPACT (start here):
   - [File:Line] Specific problem with impact explanation

   🟡 MEDIUM IMPACT:
   - [File:Line] Specific problem

   🟢 LOW IMPACT (maybe skip):
   - [File:Line] Specific problem

   Recommendation: Start with HIGH IMPACT. Explain why it gives leverage.
   ```

5. **Get user approval** before proceeding

### Phase 2: Refactoring (One Transformation at a Time)

6. **Identify ONE transformation** from the catalog in guide.md:
   - Extract Method/Function
   - Inline Method/Function
   - Rename
   - Move Method/Function
   - Extract/Inline Variable
   - Split Loop
   - Replace Nested Conditional with Guard Clauses
   - See guide.md for when to use each and examples

7. **Apply the transformation** (refer to guide.md for technique details)

8. **Verify** (see guide.md for verification methods):
   - Run tests if available
   - Check compiler/type checker
   - Explain manual verification

9. **Commit the change** (single transformation per commit)

10. **Decide next step**:
    - Re-analyze if major structure changed
    - Suggest next transformation based on observation
    - Ask if user wants to continue or stop

## Core Principles (Detailed in guide.md)

**CRITICAL: Do NOT refactor everything. Do NOT plan and execute all refactorings at once.**

The loop is:
```
Analyze → Prioritize → Refactor ONE → Verify → Decide next
```

**Key rules:**
- Start with analysis and prioritization
- ONE transformation at a time
- Never mix refactoring with behavior changes
- If you can't verify a step, make it smaller
- Each commit = single, reversible transformation
- Stop when high-impact items are addressed

## When NOT to Refactor

- Code that rarely changes
- Code that works and nobody touches
- Low-impact cosmetic improvements
- Areas with unclear requirements
- When you have higher priorities

See guide.md for the "80/20 Rule" and "When NOT to Do" sections.

## Quick References

**For detailed techniques, examples, and patterns, see [guide.md](guide.md):**
- Safe Refactoring Catalog (with multi-language examples)
- Edit and Pray vs Cover and Modify
- Temporarily Making Code Worse (Duplicate Before Unifying, etc.)
- Seams concept
- Verification methods
- Step size calibration
- What NOT to do

**Code smell → Transformation quick guide:**

| Code Smell | Transformation | See guide.md |
|------------|----------------|--------------|
| Long function (> 50 lines) | Extract Method | ✓ |
| Duplicated code | Extract Method → Unify | ✓ |
| Deep nesting (> 3 levels) | Guard Clauses | ✓ |
| Unclear name | Rename | ✓ |
| Complex expression | Extract Variable | ✓ |
| Code in wrong file | Move Function | ✓ |
| Loop does too much | Split Loop | ✓ |

## Remember

- **Observe** how code evolves after each step
- The right next step becomes clear only after the previous step is complete
- Small steps with verification are safer than large planned changes
- It's okay to make code temporarily worse to make it better (see guide.md)
- **Stop when diminishing returns set in** - perfect code is not the goal

Comments 0

Latest | Hot

Please login before commenting.

No comments yet. Be the first one!

refactor

Directory Structure

SKILL.md

Report

Notice