planning_complex_changelisted

# planning_complex_change Large changes that go in without a plan tend to balloon in scope, introduce regressions, and become impossible to review. This skill helps you decompose complex changes into a clear, ordered sequence of steps that can each be implemented, tested, and merged independently. ## Why Planning First Matters When you start writing code before understanding the full shape of the change, you'll frequently discover partway through that an earlier decision was wrong — and now you have to undo half your work. Planning surfaces these contradictions cheaply (in thought) rather than expensively (in code). A good plan also makes the work reviewable: each step has a clear purpose, and you can verify it's correct before moving on. ## Step 1: Understand the Full Scope Before proposing any plan, read the relevant code. Don't plan in the abstract — plan against the actual codebase. **Questions to answer:** - What is the user trying to achieve? (Write it as a user story if it helps: "A user should be able to...") - What parts of the codebase are directly affected? - What parts are indirectly affected (callers, dependents, DB schema, API contracts, tests)? - Are there existing tests? Do they cover the area being changed? - Are there external constraints? (backward compatibility, deploy order, data migration timing) ## Step 2: Identify the Core Dependency Chain Complex changes usually have a core sequencing constraint: you can't do step C before step B, and step B