planning-and-task-breakdown

Map the dependency graph first, then slice vertically so each task delivers one complete feature path across schema, API, and UI. Keep tasks to 1-5 files with 3 or fewer acceptance criteria; anything larger should be split further.

Vertical slicing builds one complete feature path at a time, such as registration covering schema, API, and UI together. It contrasts with horizontal slicing, which builds all of one layer first and delays working functionality until the end.

Write specific, testable conditions as checkboxes, paired with verification steps like test commands and build checks. If you cannot express the criteria in three bullet points, the task is too large and should be decomposed.

Skip 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.

Independent feature slices, tests for already-implemented features, and documentation are safe to parallelize. Database migrations, shared state changes, and dependency chains must remain sequential, and shared API contracts should be defined before parallel work begins.