Planning And Task Breakdown

Planning and Task Breakdown

Overview

Decompose specifications into small, verifiable tasks with clear acceptance criteria and dependency ordering. Good planning prevents the "implement everything at once" anti-pattern and enables incremental delivery with verification at each step.

When to Use

• You have a spec or feature description and need implementable units
• A feature is too large to build in one pass
• Multiple agents or developers will work in parallel
• You need to estimate effort or report progress

Task Decomposition Process

Step 1: Identify the Deliverables

From the spec, list every concrete deliverable:

Feature: Task Management

Deliverables:
1. Database migration for tasks table
2. API route for CRUD operations
3. TypeScript interfaces
4. List page with CollectionList
5. Create/Edit form with CollectionForm
6. RBAC permissions (roles, policies)
7. Tests (API, page, E2E)
8. Documentation

Step 2: Order by Dependencies

                ┌─── 3. Types ───────┐
1. Migration ───┤                    ├─── 5. Form ──┐
                └─── 2. API Route ───┤              ├─── 7. Tests
                                     └─── 4. List ──┘       │
                     6. RBAC ────────────────────────────────┘
                                                             │
                                                        8. Docs

Step 3: Write Tasks with Acceptance Criteria

Each task should be:

• Small — completable in one sitting (~100 lines)
• Verifiable — has clear pass/fail criteria
• Independent — can be tested without other unfinished tasks
• Committed separately — each task = one commit

### Task 1: Create tasks migration
**Depends on:** Nothing
**Files:** supabase/migrations/YYYYMMDD_create_tasks.sql
**Acceptance criteria:**
- [ ] Migration creates tasks table with fields: id, title, status, date_created, date_updated
- [ ] Standard audit fields included (user_created, user_updated)
- [ ] RLS policies for authenticated users
- [ ] Migration runs without errors

### Task 2: Create tasks API route
**Depends on:** Task 1 (migration)
**Files:** app/api/items/tasks/route.ts
**Acceptance criteria:**
- [ ] GET returns paginated task list
- [ ] POST creates a task with validation
- [ ] Proxy pattern used (calls DaaS backend)
- [ ] API tests pass

DaaS Layer Ordering

This skill feeds the tasks.md stage of spec-driven development (/buildpad-spec-tasks, or Kiro's native specs). Order tasks along DaaS dependency layers — each layer builds on the one before:

Task Size Guidelines

~30 min  → Single file change (migration, type definition)
~1 hour  → Small feature slice (API route + test)
~2 hours → Moderate slice (page + form + tests)
~4 hours → MAXIMUM for a single task — split further if larger

Output Format

## Implementation Plan: [Feature Name]

### Data Foundation
- [ ] Task 1.1: Create migration — [acceptance criteria]
- [ ] Task 1.2: Create API route — [acceptance criteria]
- [ ] Task 1.3: Define TypeScript types — [acceptance criteria]
- [ ] Task 1.4: Write API tests — [acceptance criteria]

### Core UI
- [ ] Task 2.1: Create list page — [acceptance criteria]
- [ ] Task 2.2: Create form page — [acceptance criteria]
- [ ] Task 2.3: Add navigation — [acceptance criteria]
- [ ] Task 2.4: Write page tests — [acceptance criteria]

### Risks & Dependencies
- [Known risk 1 and mitigation]
- [External dependency and fallback]

Parallelization with Subagents

Once tasks are ordered, independent branches of the dependency graph can run as parallel subagents (see subagent-delegation). Define any shared contract (API types, DaaS collection schema) as a first task, then fan out.

• Safe to parallelize: independent feature slices, read-only research, per-module reviews.
• Keep sequential: migrations, shared-state changes, and anything on one dependency chain.
• Integrate and verify each subagent's result on the main thread before marking a task done.

Common Rationalizations

Red Flags

• Tasks without acceptance criteria
• Tasks estimated at more than 4 hours
• No dependency ordering (just a flat list)
• Tasks that can't be independently tested
• Mixing different layers in a single task
• No risk identification

Verification

After planning:

• Every spec requirement maps to at least one task
• Every task has acceptance criteria
• Dependencies are identified and ordered
• No task exceeds ~4 hours of estimated work
• Each task can be independently verified
• Tasks follow DaaS layer ordering and land in the spec's tasks.md