intuitive-refactorlisted

# Intuitive Refactor Use this skill to set the goal, scope, evidence, and stop condition for a bounded refactor before code changes start. Once a target slice is accepted, the default posture is aggressive cleanup: move callers to the new intuitive API, layout, or module boundary and remove stale compatibility surfaces. This workflow owns the scope gate and stop condition. Architecture scanners, TDD, diagnosis, or planning workflows are optional inputs: use them when they raise evidence quality, but keep the accepted checklist and stop condition here. When no specialist workflow is needed, gather repo context directly and proceed against the same gate. ## Operating rule Start with a scope gate. For broad or ambiguous requests, make the first pass report-only. When the user names a bounded target and asks for execution, treat that as approval to clean the target up aggressively. Do not edit production code until all of these are explicit: - the target module or seam - the accepted issue checklist - which issue severities are in scope, defaulting to P0/P1/P2 inside the target - the required evidence level - the stop condition - the persistent gate file, if this is more than advice The goal is not "no more possible refactors." Any healthy project will always have possible refactor points. The goal is "the accepted checklist inside the target is green, the new API/layout is canonical, and cross-seam ideas are parked instead of implemented by drift." Start refactors from p