Agent Task Breakdown

Break architecture into executable tasks. Build them one at a time with AI agents.

Phase 1: Task Decomposition

Task Format

Task [N]: [Title]

Depends on: [Task numbers this requires, or "None"]

Outcome: [What exists when done - one sentence]

Why: [What this unblocks]

Acceptance: [How to verify - specific test, expected result]

Human action: [External setup needed, if any]

Sizing Rules

Right size:

• Changes ONE testable thing

• 5-30 min agent implementation time

• Failure cause is obvious and isolated

Split if:

• Multiple independent things to test

• Multiple files for different reasons

• Acceptance has multiple unrelated conditions

Content Rules

Outcomes, not implementation.

Bad: "Create users table with id, email, created_at using Prisma" Good: "Database stores user records with unique emails and timestamps"

Bad: "Install React Query and create useUser hook" Good: "User data fetches efficiently with caching"

The agent knows their tools. Define success, not steps.

Risk-first ordering.

Put uncertain/complex tasks early. Fail fast on hard problems. Don't save integrations and edge cases for the end.

Typical flow: setup > risky core logic > database > API > UI > integration

Dependencies explicit.

Every task lists what it needs. Enables parallel work and failure impact analysis.

Output Structure

[Project] Tasks

Prerequisites

[External setup: accounts, keys, env vars]

Tasks

[Ordered task list with dependencies]

Out of Scope

[What's NOT in this MVP]

Validation Checklist

Before starting execution, verify:

• Every task has exactly ONE acceptance test

• No task depends on something not yet defined

• Risky/uncertain work is front-loaded

• All external config is in Prerequisites, not buried in tasks

• A junior dev could verify each acceptance criteria

• No task requires unstated knowledge to complete

Anti-Patterns

Too big: "Build the auth system" - This is 5+ tasks disguised as one.

Too small: "Create the Button component" then "Add onClick to Button" - Combine unless genuinely separate concerns.

Hidden dependency: Task 8 needs an API key not mentioned until Task 8. Put it in Prerequisites.

Vague acceptance: "User flow works correctly" - Works how? What's the test?

Implementation-as-outcome: "Use Redux for state management" - That's a how, not a what.

Phase 2: Task Execution

Before Starting

• Read architecture doc fully

• Read task list fully

• Understand the end state before writing code

• If ANYTHING is ambiguous, ask. Don't assume.

Per-Task Protocol

• State which task you're starting

• Write minimum code to pass acceptance

• State exactly what to test and expected result

• STOP. Wait for confirmation.

• Pass → commit, announce next task

• Fail → fix the specific issue only, don't expand scope

Coding Rules

DO:

• Write absolute minimum code required
• Focus only on current task
• Keep code modular and testable
• Preserve existing functionality

DO NOT:

• Make sweeping changes
• Touch unrelated code
• Refactor unless task requires it
• Add features not in current task
• Optimize prematurely
• Assume - ask instead

WHEN HUMAN ACTION NEEDED:

• State exactly what to do
• State which file/value to update
• Wait for confirmation before continuing

When Stuck

• State what's blocking

• Propose smallest modification to unblock

• Wait for approval

Never silently skip acceptance criteria. Never reinterpret the task.

Scope Change Protocol

If you discover a missing requirement:

• STOP current task

• State what's missing and why it's needed

• Propose where it fits in task order

• Wait for PM to update task list

• Resume only after task list is updated

Don't improvise new requirements into existing tasks.

PM Feedback Format

When reporting test results:

Task [N]: PASS | FAIL | BLOCKED

[If FAIL]: What broke, error message, steps to reproduce [If BLOCKED]: What's preventing test

Keep it tight. Agent needs signal, not narrative.

Example

Todo App Tasks

Prerequisites

• Supabase project with URL + anon key in .env.local
• Resend API key in .env.local

Tasks

Task 1: Scaffold

Depends on: None Outcome: Next.js app runs with Supabase client configured Why: Foundation for all features Acceptance: npm run dev shows page, console logs "Supabase connected"

Task 2: Signup

Depends on: 1 Outcome: Users create accounts via email/password Why: Unblocks all authenticated features Acceptance: Submit signup form → user appears in Supabase Auth → confirmation email sent

Task 3: Login + Protected Routes

Depends on: 2 Outcome: Users log in and access protected pages Why: Unblocks task management UI Acceptance: Login → redirect to /dashboard. Visit /dashboard logged out → redirect to /login

Task 4: Tasks Table + RLS

Depends on: 1 Outcome: Database stores tasks per user Why: Unblocks task CRUD Acceptance: Insert task via Supabase dashboard with user_id, title, due_date, completed. Query as different user returns empty.

Task 5: Create Task

Depends on: 3, 4 Outcome: Users create tasks from UI Why: Core feature Acceptance: Submit form → task in DB → appears in list without refresh

Out of Scope

• Social auth
• Task sharing
• Mobile app