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

Vertical slicing means each task builds one complete feature path across all layers, 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.

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 so future sessions know where tasks live.

Split a task when it exceeds one focused session, when acceptance criteria need more than three bullet points, when it touches two independent subsystems, or when the title contains the word 'and'. Tasks sized Large or bigger should always be decomposed.

The Skill never overwrites an incomplete plan. If the existing unchecked tasks belong to different work, it stops and asks the user whether to finish the old plan, discard it explicitly, or store the new plan elsewhere, since those tasks may be mid-build in another session.

Skip the planning process for single-file changes with obvious scope or when the spec already contains well-defined tasks. Writing a full plan for trivial work adds overhead without reducing risk.