메뉴
Use when code quality needs improvement after implementation, without changing behavior
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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
| 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. |