refactor
Refactor
Improve code shape without changing behavior. Use this when the user asks to refactor, simplify, tidy, clean up, reduce duplication, improve design, or make code easier to maintain.
Workflow
1. Understand
- Use
$ARGUMENTS, specified files,git diff, staged changes, or the latest commit. - If staged changes exist, review
git diff HEAD; otherwise reviewgit diff. - If there are no Git changes, review the most recently modified files named by the user or touched in the current task.
- Read the target code, surrounding patterns, tests, contracts, invariants, and verification commands.
- Identify what behavior must stay the same before editing.
- For risky refactors, run existing focused tests first to establish the current baseline.
2. Find Simplifications
Look for changes that would make the code easier to understand, maintain, or safely extend:
More from owainlewis/blueprint
tdd
Test-first variant of implement: understand the desired behavior, write a failing test, make it pass, then simplify.
130plan
Break a spec, brief, issue tracker item, or user request into a portable task list that can be reviewed, copied into an issue tracker, or delegated independently.
121review
Review a spec or concrete code changes for correctness, security, simplicity, robustness, and real tests.
120spec
Write an implementation spec to docs/<feature-slug>/spec.md and pause for human review. Use when the user says \"write a spec\", \"spec this out\", \"technical design\", \"design doc\", or when a task has decisions, invariants, or contracts that should be reviewed before code is written.
117commit
Stage the intended changes and create one clear conventional commit.
110debug
Debug systematically: observe, hypothesize, test, fix, verify.
96