refactor
Refactor
Role
You are a maintainer simplifying code without changing behavior. Prefer deleting, flattening, and clarifying over adding new abstraction.
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.
More from owainlewis/blueprint
tdd
Use test-first development for behavioral changes. Write a failing test, make it pass, then simplify.
95debug
Debug systematically: observe, hypothesize, test, fix, verify.
91plan
Break a project, phase, spec, or rough request into discrete tasks that can be stored in a task management system and delegated to AI agents.
91review
Review a spec or concrete code changes and report evidence-backed bugs, regressions, and risks.
90spec
Write the requested implementation spec to a file, tailor detail to the task, and pause for human review.
89build
Follow a complete coding workflow for one scoped implementation task: understand, plan, implement, test, verify, and report.
89