plan-splitlisted

# Plan a code split Use this skill to plan how to **split** a large or tangled code unit along its natural single-responsibility seams — the natural boundaries where cohesive clusters separate cleanly. The output is a decomposition **plan**: what moves where, in what order, preserving behavior and the public contract, with the verification each step must pass. Governing intuition: **a good split follows the code's own structure.** Do not impose a split where the code is genuinely cohesive; the cohesive core that *is* the unit's purpose should stay whole. The win is analysis cost and single responsibility, not module count. **Input**: the code unit to split (a file, module, class, or function) — if unnamed, ask which unit, and pin the public surface that must not change before planning. **Boundary**: plans only — produces a decomposition plan; does not move code, create files, run the build, or open changes. ## Workflow ### Phase 0: Read the unit and pin its contract - Read the target unit in full and map the **public/observable surface that must not change**: exported names, signatures, re-export paths, and observable behavior. - Map the **dependency edges**: what the unit imports, and what imports *it* (inbound references decide repointing cost and cycle risk). ### Phase 1: Find the seams Identify cohesive single-responsibility clusters (see [references/seams.md](references/seams.md) for patterns). For each candidate cluster record: - What it is (a coherent resp