← ClaudeAtlas

memtrace-refactoring-guidelisted

Build a phased, risk-scored refactoring plan from Memtrace complexity, dead-code, bridge, impact analysis, and Cortex decision-memory constraints. Use when the user wants to refactor source code, reduce complexity, clean technical debt, delete dead code, split large functions, extract modules, reorganize code, or choose refactoring priorities. Do not plan refactors from grep/manual reference search alone; check graph impact and decision rationale/bans/contracts before changing existing code.
syncable-dev/memtrace-public · ★ 474 · Code & Development · score 79
Install: claude install-skill syncable-dev/memtrace-public
## Overview Guided refactoring workflow — identifies refactoring candidates using structural analysis, scores them by risk and priority, checks Cortex decision memory for rationale/bans/contracts, and produces a phased refactoring plan. Combines complexity metrics, dead code detection, bridge analysis, temporal evolution, and decision memory to prioritize what to refactor first and how to do it safely. ## Steps ### 1. Identify refactoring candidates Run these three tools in parallel to build a candidate list: **a) Complexity hotspots:** Call `find_most_complex_functions` with `top_n: 20` **b) Dead code:** Call `find_dead_code` to find unused symbols **c) Architectural bottlenecks:** Call `find_bridge_symbols` to find chokepoints with too much responsibility ### 2. Score candidates by volatility Call `get_evolution` with `from: "90d ago"` and `mode: "compound"`. Review `top_touched_symbols` and `top_changed_files`: - Symbols that are BOTH complex AND frequently changing are the highest priority - Complex but stable code can wait — it's not causing active pain - Volatile but simple code may be fine — frequent changes to simple code is normal **Priority matrix:** | | Low Complexity | High Complexity | |---|---|---| | **Stable (low change freq)** | Leave alone | Monitor; refactor if touched | | **Volatile (high change freq)** | Normal; leave alone | **TOP PRIORITY** — refactor first | ### 3. Assess risk for top candidates For each top-priority candidate, call `get_i