| name | refactor |
| description | Refactor outdated patterns in the codebase based on user input |
| argument-hint | <pattern to refactor, e.g. "Bacon.js to Zustand" or "any types to proper types"> |
| disable-model-invocation | true |
Refactoring: $ARGUMENTS
Systematically find and convert all instances of the outdated pattern described above.
Process
-
Understand the target: Parse the refactoring description to identify the
old pattern and the desired new pattern.
-
Survey the codebase: Search for all instances of the old pattern. Use grep/glob
to find every occurrence. Report the full scope before making changes:
- How many files are affected
- Which directories contain the most instances
- Any tricky cases that need special attention
-
Plan the approach: Present a migration plan:
- Group files by complexity (simple mechanical replacements vs. files needing redesign)
- Identify dependencies between files (change order matters)
- Flag any files where the refactoring might change behavior
-
Get approval: Show the plan and ask the user to confirm scope before proceeding.
The user may want to do it all at once or in batches.
-
Execute: For each file:
- Apply the refactoring
- Ensure imports are updated
- Verify the file is self-consistent after changes
-
Verify: After all changes, run bun lint to catch type errors and lint issues.
Fix any issues introduced by the refactoring.
Frontend Refactoring
For frontend/UI refactoring, prefer the /refactor-frontend skill which reads the
full coding conventions from src/client/coding-conventions.md.
Common Refactoring Targets
These are known legacy patterns in this codebase:
- Bacon.js to Zustand: Replace reactive stream patterns with Zustand stores.
any types: Replace any with proper TypeScript types.
- Raw SQL strings: Ensure all queries use
$/param/ parameterization.
Rules
- Do not change behavior — refactoring is structural, not functional.
- Run
bun lint after each batch of changes to catch issues early.
- If a file is complex, show the before/after diff concept before applying.
- Keep commits atomic — one logical change per commit when the user asks to commit.