491a45dd43
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
1.3 KiB
1.3 KiB
name, description, argument-hint, disable-model-invocation
| name | description | argument-hint | disable-model-invocation |
|---|---|---|---|
| refactor | Safely refactor code with test coverage as a safety net | [target to refactor — file, function, or pattern] | true |
Refactor $ARGUMENTS safely.
Process
1. Understand the current state
- Read the code and its tests
- Identify what the code does, its callers, and its dependencies
- If there are no tests, WRITE TESTS FIRST — you need a safety net before changing anything
2. Plan the refactoring
- State what you're changing and why (clearer naming, reduced duplication, better structure)
- List the specific transformations (extract function, inline variable, move module, etc.)
- Check: does this change any external behavior? If yes, this isn't a refactor — reconsider.
3. Make changes in small, testable steps
- One transformation at a time
- Run tests after EACH step — not at the end
- If a test breaks, undo the last step and make a smaller change
4. Verify
- All existing tests pass
- Lint and typecheck pass
- The public API hasn't changed (unless that was the explicit goal)
- The code is objectively simpler — fewer lines, fewer branches, clearer names
Rules
- If you can't run the tests, don't refactor
- Never mix refactoring with behavior changes in the same commit
- If the refactoring is large (10+ files), break it into multiple commits