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. Write each task with acceptance criteria, verification steps, and dependencies, keeping tasks to roughly five files or fewer.

Vertical slicing builds one complete feature path at a time, such as user registration end to end, instead of building all database layers, then all APIs, then all UI. Each slice leaves the system in a working, testable state.

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.

Split a task when it exceeds one focused session, touches more than about five files, spans two independent subsystems, or cannot be described in three acceptance criteria bullets. Tasks sized L or XL should always be decomposed into S or M tasks.

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.

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, ambiguous, parallelized, or spans multiple sessions.