Break Down Specs into Testable, Ordered Implementation Tasks
A 5-step process for breaking a spec into small, vertically-sliced tasks with explicit acceptance criteria and checkpoints.
Why it matters
Transform product requirements and feature specs into small, verifiable implementation tasks with clear acceptance criteria, dependency ordering, and test-driven workflows that guide AI agents through incremental, safe code delivery.
Outcomes
What it gets done
Decompose feature specs into atomic, independently testable tasks with explicit acceptance criteria
Establish dependency ordering and identify which tasks can run in parallel
Generate test-first implementation plans that follow thin vertical slice patterns
Create rollback-safe task sequences with feature flags and verification gates
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-planning-and-task-breakdown | bash Overview
Planning and Task Breakdown
This skill breaks a spec into small, vertically-sliced tasks through a 5-step process (plan mode, dependency graph, vertical slicing, structured task writing, ordering with checkpoints), each task carrying explicit acceptance criteria and verification steps. Use it when a spec needs breaking into implementable units, a task feels too large or vague, work needs parallelizing, or implementation order isn't obvious. Not for single-file changes or specs that already have well-defined tasks.
What it does
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.
When to use - and when NOT to
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.
Inputs and outputs
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.
Integrations
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.
Who it's for
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.
Source README
Planning and Task Breakdown
Overview
Decompose work into small, verifiable tasks with explicit acceptance criteria. Good task breakdown is the difference between an agent that completes work reliably and one that produces a tangled mess. Every task should be small enough to implement, test, and verify in a single focused session.
When to Use
- You have a spec and need to break it into implementable units
- A task feels too large or vague to start
- Work needs to be parallelized across multiple agents or sessions
- You need to communicate scope to a human
- The implementation order isn't obvious
When NOT to use: Single-file changes with obvious scope, or when the spec already contains well-defined tasks.
The Planning Process
Step 1: Enter Plan Mode
Before writing any code, operate in read-only mode:
- Read the spec and relevant codebase sections
- Identify existing patterns and conventions
- Map dependencies between components
- Note risks and unknowns
Do NOT write code during planning. The output is a plan document, not implementation.
Step 2: Identify the Dependency Graph
Map what depends on what:
Database schema
│
├── API models/types
│ │
│ ├── API endpoints
│ │ │
│ │ └── Frontend API client
│ │ │
│ │ └── UI components
│ │
│ └── Validation logic
│
└── Seed data / migrations
Implementation order follows the dependency graph bottom-up: build foundations first.
Step 3: Slice Vertically
Instead of building all the database, then all the API, then all the UI - build one complete feature path at a time:
Bad (horizontal slicing):
Task 1: Build entire database schema
Task 2: Build all API endpoints
Task 3: Build all UI components
Task 4: Connect everything
Good (vertical slicing):
Task 1: User can create an account (schema + API + UI for registration)
Task 2: User can log in (auth schema + API + UI for login)
Task 3: User can create a task (task schema + API + UI for creation)
Task 4: User can view task list (query + API + UI for list view)
Each vertical slice delivers working, testable functionality.
Step 4: Write Tasks
Each task follows this structure:
### Task [N]: [Short descriptive title]
**Description:** One paragraph explaining what this task accomplishes.
**Acceptance criteria:**
- [ ] [Specific, testable condition]
- [ ] [Specific, testable condition]
**Verification:**
- [ ] Tests pass: `npm test -- --grep "feature-name"`
- [ ] Build succeeds: `npm run build`
- [ ] Manual check: [description of what to verify]
**Dependencies:** [Task numbers this depends on, or "None"]
**Files likely touched:**
- `src/path/to/file.ts`
- `tests/path/to/test.ts`
**Estimated scope:** [Small: 1-2 files | Medium: 3-5 files | Large: 5+ files]
Step 5: Order and Checkpoint
Arrange tasks so that:
- Dependencies are satisfied (build foundation first)
- Each task leaves the system in a working state
- Verification checkpoints occur after every 2-3 tasks
- High-risk tasks are early (fail fast)
Add explicit checkpoints:
### Checkpoint: After Tasks 1-3
- [ ] All tests pass
- [ ] Application builds without errors
- [ ] Core user flow works end-to-end
- [ ] Review with human before proceeding
Task Sizing Guidelines
| Size | Files | Scope | Example |
|---|---|---|---|
| XS | 1 | Single function or config change | Add a validation rule |
| S | 1-2 | One component or endpoint | Add a new API endpoint |
| M | 3-5 | One feature slice | User registration flow |
| L | 5-8 | Multi-component feature | Search with filtering and pagination |
| XL | 8+ | Too large - break it down further | - |
If a task is L or larger, it should be broken into smaller tasks. An agent performs best on S and M tasks.
When to break a task down further:
- It would take more than one focused session (roughly 2+ hours of agent work)
- You cannot describe the acceptance criteria in 3 or fewer bullet points
- It touches two or more independent subsystems (e.g., auth and billing)
- You find yourself writing "and" in the task title (a sign it is two tasks)
Plan Document Template
### Implementation Plan: [Feature/Project Name]
### Overview
[One paragraph summary of what we're building]
### Architecture Decisions
- [Key decision 1 and rationale]
- [Key decision 2 and rationale]
### Task List
### Phase 1: Foundation
- [ ] Task 1: ...
- [ ] Task 2: ...
### Checkpoint: Foundation
- [ ] Tests pass, builds clean
### Phase 2: Core Features
- [ ] Task 3: ...
- [ ] Task 4: ...
### Checkpoint: Core Features
- [ ] End-to-end flow works
### Phase 3: Polish
- [ ] Task 5: ...
- [ ] Task 6: ...
### Checkpoint: Complete
- [ ] All acceptance criteria met
- [ ] Ready for review
### Risks and Mitigations
| Risk | Impact | Mitigation |
|------|--------|------------|
| [Risk] | [High/Med/Low] | [Strategy] |
### Open Questions
- [Question needing human input]
Parallelization Opportunities
When multiple agents or sessions are available:
- Safe to parallelize: Independent feature slices, tests for already-implemented features, documentation
- Must be sequential: Database migrations, shared state changes, dependency chains
- Needs coordination: Features that share an API contract (define the contract first, then parallelize)
Common Rationalizations
| Rationalization | Reality |
|---|---|
| "I'll figure it out as I go" | That's how you end up with a tangled mess and rework. 10 minutes of planning saves hours. |
| "The tasks are obvious" | Write them down anyway. Explicit tasks surface hidden dependencies and forgotten edge cases. |
| "Planning is overhead" | Planning is the task. Implementation without a plan is just typing. |
| "I can hold it all in my head" | Context windows are finite. Written plans survive session boundaries and compaction. |
Red Flags
- Starting implementation without a written task list
- Tasks that say "implement the feature" without acceptance criteria
- No verification steps in the plan
- All tasks are XL-sized
- No checkpoints between tasks
- Dependency order isn't considered
Verification
Before starting implementation, confirm:
- Every task has acceptance criteria
- Every task has a verification step
- Task dependencies are identified and ordered correctly
- No task touches more than ~5 files
- Checkpoints exist between major phases
- The human has reviewed and approved the plan
See Also
Acceptance criteria are per-task and answer "did we build the right thing?". They sit on top of the project-wide Definition of Done, the standing bar every task clears before it counts as done. See references/definition-of-done.md.
Limitations
- Use this skill only when the task clearly matches its upstream source and local project context.
- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.