planning-and-task-breakdown

Slice the feature vertically so each task delivers one complete working path, such as schema plus API plus UI for a single user action. Keep tasks to 1-5 files, give each one acceptance criteria and verification steps, and split anything larger.

Vertical slicing builds one complete feature path at a time across all layers instead of building the entire database, then all APIs, then all UI. Each slice produces working, testable functionality that leaves the system in a valid state.

A task is too large when it touches more than about 5 files, takes more than one focused session, needs more than 3 acceptance criteria bullets, spans two independent subsystems, or contains the word "and" in its title. Break it down further.

Yes. If the project's agent rules or the user designate an external tracker such as GitHub Issues, Jira, Linear, or beads, one tracker item is created per task instead of writing tasks/todo.md, with dependencies mapped via the tracker's linking mechanism.

The Skill never overwrites an incomplete plan. If the existing file has unchecked tasks for the same work, it updates in place; for different work, it stops and asks the user rather than deleting or renaming the existing plan.

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-step work where dependencies, ordering, or scope are not immediately clear.