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. Each task should have acceptance criteria, verification steps, and touch no more than about five files.

Write specific, testable conditions as checkboxes, such as tests passing with a named command, a successful build, and a manual verification step. If you cannot express the criteria in three or fewer bullets, the task is too large and should be split.

Skip it for single-file changes with obvious scope, or when the spec already contains well-defined tasks. Planning overhead only pays off when work is large, vague, parallelized, or has unclear implementation order.

Horizontal slicing builds all of one layer at a time, such as the entire database then all endpoints. Vertical slicing builds one complete feature path end to end, so every task leaves the system in a working, testable state.

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 shared API contracts should be defined before parallel work begins.