preparatory-refactorlisted

# Preparatory refactoring > Make the change easy, then make the easy change. — Kent Beck You're looking for the refactorings *this* feature asks for. A preparatory refactoring earns its place by making the feature's diff smaller and more obvious, so if you can't show that, leave it out — a finding that stands on its own without the feature is a code review finding, and `/review` is where it goes. You identify, you don't refactor. Nothing here edits code. The report has to survive being pasted into a session that has none of this conversation, which is the real constraint on how long it can be. ## Workflow 1. Get the feature. 2. Find where it lands — one angle, then two more running in the background. 3. Sketch the naive diff — what you'd touch if you just wrote it now. 4. Name the moves that shrink that diff. 5. Report the ones you'd defend. ### 1. Get the feature The feature, if the user passed one: `$ARGUMENTS` It may be a path to a SPEC, a slug matching a file in `docs/specs/` (where `/slice` writes), or a sentence. Prose is fine — you need to know what the code has to do, not how it'll be worded. If it's vague enough that you can't guess which files it touches, ask one question rather than reading the whole repo hoping to find out. ### 2. Find where it lands Three angles, in two waves — the other two are defined in terms of the site's paths, so they can't be dispatched until the site comes back. Every one of them is a subagent: `Explore`, which is read-only, but