trace-mcp-refactoring

# trace-mcp — Refactoring Workflow Use this skill whenever you are about to rename, restructure, extract, or otherwise refactor code in a project indexed by trace-mcp. The goal is to never break cross-file references and never guess at what is affected. ## When to Use - Renaming a class, function, method, variable, or file - Extracting a function or method - Restructuring a module or splitting a file - Changing a function signature - Any change that touches more than one call site ## Refactoring Workflow ### 1. Assess before touching anything ``` assess_change_risk({ file_path: "src/foo.ts" }) # or assess_change_risk({ symbol_id: "<id>" }) ``` This returns the risk level of the target change based on churn, complexity, fan-in/fan-out, and test coverage. Use it to decide whether to proceed, add tests first, or split the change. ### 2. Find what actually needs refactoring ``` get_refactor_candidates() ``` Do not guess. This surfaces high-complexity, high-churn, and anti-pattern-laden symbols that are the real refactor targets. ### 3. Know what will break ``` get_change_impact({ symbol_id: "<id>" }) ``` Returns the reverse-dependency graph: every file, symbol, and test that depends on the target. Review this list before editing. ### 4. Quantify complexity ``` get_complexity_report({ file_path: "src/foo.ts" }) ``` Gives you a baseline so you can verify the refactor actually reduced complexity. ## Renaming a Symbol — MANDATORY Flow **Never** rename with `Edit` an...