planning-and-task-breakdown

Map the dependency graph first, then slice vertically so each task delivers one complete working feature path such as schema plus API plus UI. Give every task acceptance criteria, verification steps, and a size estimate, and split anything larger than about five files.

Vertical slicing means building one complete feature path at a time, like user registration end to end, instead of building all the database, then all the API, then all the UI. Each slice produces working, testable functionality.

Skip formal planning for single-file changes with obvious scope, or when the spec already contains well-defined tasks. Planning adds value when work is large, vague, parallelized, or has unclear implementation order.

Aim for small tasks touching one to two files or medium tasks touching three to five files. Anything estimated at five or more files, spanning multiple subsystems, or needing more than three acceptance criteria bullets should be broken down further.

Independent feature slices, tests for already-implemented features, and documentation are safe to parallelize. Database migrations, shared state changes, and dependency chains must stay sequential, and features sharing an API contract need the contract defined first.