planning-and-task-breakdown

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 projects and assemblies
• 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 / EF Core entities
    │
    ├── DTOs / contracts
    │       │
    │       ├── API endpoints or service methods
    │       │       │
    │       │       └── UI bindings (Avalonia / Blazor / MAUI)
    │       │               │
    │       │               └── Views and view models
    │       │
    │       └── Validation logic (FluentValidation, DataAnnotations)
    │
    └── Seed data / migrations (EF Core `dotnet ef migrations`)

Implementation order follows the dependency graph bottom-up: build foundations first. Within a .NET solution, that usually means MyApp.Core → MyApp.Infrastructure → MyApp.Contracts → MyApp (host project).