planning-and-task-breakdown

Read the spec in read-only mode, map the dependency graph, then slice work vertically so each task delivers a complete feature path across schema, API, and UI. Record each task with acceptance criteria, verification steps, and dependencies in tasks/todo.md.

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 then all UI. Each slice delivers working, testable functionality.

Tasks should be Small (1-2 files) or Medium (3-5 files), completable in one focused session. Anything Large or bigger should be split further, especially if it touches multiple subsystems or needs more than three acceptance criteria bullets.

Yes. If the project designates an external tracker, create one tracker item per task with acceptance criteria in the body and dependencies via the tracker's linking mechanism. Note the tracker in tasks/plan.md so future sessions know where tasks live.

The skill checks for existing unchecked tasks before writing. If it is the same work being revised, it updates in place; if it is different work, it stops and asks the user rather than overwriting a plan that may be mid-build in another session.

Skip it for single-file changes with obvious scope or when the spec already contains well-defined tasks. The planning overhead only pays off when work is large, vague, parallelized, or has non-obvious ordering.