planning-and-task-breakdown

Map the dependency graph first, then slice vertically so each task delivers one complete working feature path across schema, API, and UI. Give every task acceptance criteria, verification steps, and a size estimate, keeping tasks to roughly five files or fewer.

Vertical slicing means each task builds one complete feature path end to end, such as user registration covering schema, API, and UI together. It avoids horizontal slicing where you build the entire database, then all endpoints, then all UI, which delays testable functionality.

Split a task when it exceeds one focused session, needs more than three acceptance criteria bullets, touches two independent subsystems, or has 'and' in its title. Tasks sized L (5-8 files) or larger should be decomposed into S or M tasks.

Yes. If the project's agent rules or the user designate an external tracker, create one tracker item per task instead of writing tasks/todo.md. Map acceptance criteria into the item body and dependencies via the tracker's linking mechanism, and note the tracker in tasks/plan.md.

The Skill never overwrites an incomplete plan without asking. If the existing unchecked tasks belong to different work, it stops and presents the conflict so the user can decide whether to finish the old plan, discard it, or redirect the new plan elsewhere.

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