// Use when code quality needs improvement after implementation, without changing behavior
| name | refactor |
| description | Use when code quality needs improvement after implementation, without changing behavior |
Improve code structure without changing behavior. Propose changes, get approval, make one change at a time with tests between each.
Core principle: Never change behavior. Tests must stay green after every change.
Run the test suite first. Actually run it.
~/bin/eldev etest -r dot
Record the result. This is your safety net. If tests aren't green before you start, fix that first.
git diff main...HEAD # if on a branch
git log --oneline -N # user specifies range
Read all changed files in full — not just the diff. Context matters.
Look for:
| Issue | Signal |
|---|---|
| DRY violations | Same logic in two places |
| SRP violations | Function hard to name (doing too much) |
| Naming | Names don't match what the code does |
| Unnecessary complexity | Abstraction not earning its keep |
| Dead code | Unreachable branches, unused functions |
Don't look for:
Present refactorings ordered by highest impact, lowest risk first:
### 1. [Title] — Impact: High, Risk: Low
**What**: [what to change]
**Why**: [why it improves the code]
**Risk**: [what could go wrong]
Ask the user which to do. Don't start changing code without approval.
For each approved refactoring:
If tests fail after a change: revert immediately. You introduced a bug.
~/bin/eldev etest -r dot
All tests must pass. Report the final state.
| Mistake | Fix |
|---|---|
| Changing behavior ("while I'm here") | Refactoring changes structure ONLY. If tests break, revert. |
| Not running tests before starting | Run tests FIRST. No green baseline = no refactoring. |
| Making changes without user approval | Propose, get approval, then act. |
| Multiple changes at once | One change, one test run, one commit. Atomic. |
| Renaming public API | That's a breaking change, not a refactoring. |
| Proposing 10+ changes | Focus on 3-5 highest-impact items. Less is more. |
| Describing changes without making them | Actually edit the files. Actually run the tests. |
Use EVERY TIME you need to run tests, verify tests pass, or check for regressions. ALWAYS use this instead of running eldev directly.
Use when implementation is complete and you want to verify quality through adversarial testing that writes code and provides evidence
Use when a design exists and it's time to break it into tasks and execute with subagent dispatch and review
Use when requirements exist and a technical design is needed before implementation begins
Use when a new feature request, bug report, or work request needs requirements defined before implementation
Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions