code-refactoring

# refactorer ## When to use Use this skill when renaming, moving, extracting, or restructuring code — any change that may have downstream effects on callers, interfaces, tests, documentation, or API contracts. Do NOT use when: - New feature development (use `feature-planning` skill) - Bug fixes that don't involve restructuring (use `bug-analyzer` skill) ## Before refactoring 1. **Read the agent docs** — check `agents/reference/docs/` and `agents/settings/contexts/` for the area you're refactoring. For modules, also read the project's module-docs directory (path varies by stack — Laravel: `app/Modules/{Module}/agents/`; Nx: `apps/{app}/docs/`; mono-repo: per-package `docs/`). See the `project-docs` skill for the mapping. 2. **Understand the scope** — what exactly needs to change and why? 3. **Find ALL references** — use `codebase-retrieval` and `view` with `search_query_regex` to find every caller, implementation, test, and configuration that references the code being changed. **If the change is to a closed set** — an enum, union, literal type, state machine, role or permission set — identifier search is not enough: the consumers that break are the ones that never name the type. Search by shape as well (`switch` / `match` / if-chains over it, lookup tables keyed by it, validators, serializers, schemas, fixtures, translation keys) and classify each as exhaustive, deliberate fallback, or missing case. Procedure: [`downstream-changes-mechanics`](....