Break Down Specs into Testable, Ordered Implementation Tasks

A 5-step process for decomposing work into small, verifiable tasks with explicit acceptance criteria - on the premise that good task breakdown is what separates an agent that completes work reliably from one that produces a tangled mess, and every task should be small enough to implement, test, and verify in one focused session. Step 1 enters a read-only plan mode - reading the spec and codebase, mapping dependencies, noting risks, but writing no code, since the output is a plan document, not implementation. Step 2 maps the dependency graph (e.g. database schema feeds API models, which feed endpoints, which feed the frontend client, which feeds UI components) so implementation order follows it bottom-up. Step 3 slices vertically instead of horizontally: rather than building all the database, then all the API, then all the UI, each task delivers one complete, testable feature path ("user can create an account" - schema, API, and UI together - rather than "build the entire schema" as its own task). Step 4 writes each task to a fixed structure: description, specific testable acceptance criteria, a verification section (tests to run, build to check, a manual check description), dependencies on other task numbers, likely-touched files, and an estimated scope. Step 5 orders and checkpoints the task list so dependencies are satisfied, each task leaves the system working, verification checkpoints land after every 2-3 tasks, and high-risk tasks come early to fail fast. Task sizing runs from XS (a single function or config change) through S, M, L, to XL - anything L or larger should be broken down further, since an agent performs best on S and M tasks; concrete signals a task needs splitting include needing more than roughly 2 hours of agent work, needing more than 3 bullet points to state its acceptance criteria, touching two or more independent subsystems, or having "and" in its title. A full plan document template bundles an overview, architecture decisions with rationale, a phased task list with checkpoints between phases, a risk/impact/mitigation table, and open questions needing human input. For parallelization across multiple agents or sessions, independent feature slices, tests for already-implemented features, and documentation are safe to run concurrently; database migrations, shared-state changes, and dependency chains must stay sequential; and features sharing an API contract need that contract defined first before parallelizing.

Use it when there's a spec to break into implementable units, a task feels too large or vague to start, work needs to be parallelized across agents or sessions, scope needs communicating to a human, or the implementation order isn't obvious. Do NOT use it for single-file changes with obvious scope, or when the spec already contains well-defined tasks.

Input is a spec or a vague/oversized task description. Output is a phased plan document: an ordered, dependency-respecting task list with per-task acceptance criteria, verification steps, file estimates, and checkpoints between phases.

Sits above the project-wide Definition of Done - per-task acceptance criteria answer "did we build the right thing," while the Definition of Done is the standing bar every task clears regardless of what it built.

Developers and agents turning a spec into an implementation plan who want small, independently verifiable, vertically-sliced tasks with real acceptance criteria and checkpoints, rather than a vague task list that produces rework and tangled dependencies.