Refactor
When to use
- Simplifying code after behavior already works
- Removing duplication, dead code, or unnecessary complexity
- Cleaning up a focused area without changing what it does
Process
- Choose the target from
$ARGUMENTS, current changes, or a clearly relevant recent area. If there is still no clear target, ask. - Read the code and its surrounding context before changing it.
- Remove dead code, flatten needless indirection, and simplify naming or structure where the behavior stays the same.
- Run the relevant tests and build checks.
Verification
- Behavior is unchanged
- The code is simpler or smaller
- Tests and build checks pass
Rules
- Make the smallest safe refactor.
- Preserve contracts and externally visible behavior.
- Do not erase failure-path handling in the name of simplification.
- If the goal is to change behavior, use a different skill.
- If you are not sure a change is behavior-preserving, skip it.
- Prefer deleting or simplifying over adding new abstraction.
- If the code is already clean, say so.