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 of Small or Medium.

Vertical slicing builds one complete feature path at a time, such as schema plus API plus UI for registration, instead of building the entire database, then all endpoints, then all UI. Each slice leaves the system in a working, testable state.

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 Large or bigger should always be split.

Yes. If the project's agent rules or the user designate an external tracker such as GitHub Issues, Jira, Linear, or beads, create one tracker item per task instead of writing tasks/todo.md, and note the tracker in tasks/plan.md.

The Skill never overwrites an incomplete plan. If the existing plan covers different work, it stops and asks the user whether to finish the old plan, discard it, or write the new plan elsewhere, since unchecked tasks 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 process is designed for multi-component work where implementation order and dependencies are not obvious.