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 at S or M size (1-5 files) and give each one acceptance criteria and a verification step.

Vertical slicing builds one complete feature path at a time, such as registration covering schema, API, and UI together, instead of building all database layers then all APIs. Each slice produces working, testable functionality.

Break a task down when it exceeds one focused session, needs more than three acceptance criteria bullets, touches two independent subsystems, or its title contains the word 'and'. Tasks sized L or larger should always be split.

Skip formal planning for single-file changes with obvious scope, or when the spec already contains well-defined tasks. The overhead of a full plan document only pays off for multi-step or multi-component work.

Independent feature slices, tests for finished 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.