planning-and-task-breakdown

Map the dependency graph first, then slice vertically so each task delivers one complete working feature path rather than a horizontal layer. Give every task acceptance criteria, verification steps, dependencies, and a size estimate.

Vertical slicing builds one complete feature path at a time, such as registration covering schema, API, and UI together. It avoids horizontal slicing where the entire database, then all endpoints, then all UI are built separately and only connected at the end.

Tasks should be Small (1-2 files) or Medium (3-5 files), completable in one focused session. Anything Large (5-8 files) or bigger should be broken down further, especially if the title contains 'and' or touches multiple subsystems.

Yes. If the project's agent rules or the user designate 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 to look.

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, parallelizable, or has non-obvious implementation order.

The Skill never overwrites an incomplete plan. If it is the same work being revised, update in place; if it is different work, stop and ask the user, since unchecked tasks may be mid-build in another session.