Hogar

Skill

Productividad y flujo de trabajo

planning-and-task-breakdown

addyosmani/agent-skills

Desglosa el trabajo en tareas pequeñas y verificables, con criterios de aceptación explícitos, ordenadas según sus dependencias y divididas verticalmente para garantizar una ejecución fiable.

...Expandir todo

Tiempo actualizado 3 de septiembre de 2026

# planning # dependency graph # acceptance criteria # checkpoints # task breakdown # vertical slicing

Planificación y desglose de tareas

Resumen

Desglosa el trabajo en tareas pequeñas y verificables con criterios de aceptación explícitos. Un buen desglose de tareas marca la diferencia entre un agente que completa el trabajo de forma fiable y otro que genera un lío enredado. Cada tarea debe ser lo suficientemente pequeña como para poder implementarla, probarla y verificarla en una sola sesión centrada en ella.

Cuándo utilizarlo

Tienes unas especificaciones y necesitas dividirlas en unidades implementables
Una tarea parece demasiado grande o imprecisa como para empezar
El trabajo debe distribuirse en paralelo entre varios agentes o sesiones
Necesitas comunicar el alcance a una persona
El orden de implementación no resulta evidente

Cuándo NO utilizarlo: cambios en un único archivo con un alcance claro, o cuando las especificaciones ya contienen tareas bien definidas.

El proceso de planificación

Paso 1: Entrar en modo de planificación

Antes de escribir ningún código, trabaja en modo de solo lectura:

Lee las especificaciones y las secciones pertinentes del código fuente
Identifica los patrones y convenciones existentes
Identifica las dependencias entre los componentes
Anota los riesgos y las incógnitas

NO escribas código durante la fase de planificación. El resultado es un documento de planificación, no una implementación.

Paso 2: Identificar el grafo de dependencias

Representa qué depende de qué:

Esquema de la base de datos
    │
    ├── Modelos/tipos de la API
    │       │
    │       ├── Puntos finales de la API
    │       │       │
    │       │       └── Cliente de la API front-end
    │       │               │
    │       │               └── Componentes de la interfaz de usuario
    │       │
    │       └── Lógica de validación
    │
    └── Datos iniciales / migraciones

El orden de implementación sigue el gráfico de dependencias de abajo hacia arriba: primero se construyen los cimientos.

Paso 3: Dividir verticalmente

En lugar de desarrollar primero toda la base de datos, luego toda la API y después toda la interfaz de usuario, crea una ruta de funcionalidad completa cada vez:

Mal (división horizontal):

Tarea 1: Crear todo el esquema de la base de datos
Tarea 2: Crear todos los puntos finales de la API
Tarea 3: Crear todos los componentes de la interfaz de usuario
Tarea 4: Conectar todo

Correcto (división vertical):

Tarea 1: El usuario puede crear una cuenta (esquema + API + interfaz de usuario para el registro)
Tarea 2: El usuario puede iniciar sesión (esquema de autenticación + API + interfaz de usuario para el inicio de sesión)
Tarea 3: El usuario puede crear una tarea (esquema de tareas + API + interfaz de usuario para la creación)
Tarea 4: El usuario puede ver la lista de tareas (consulta + API + interfaz de usuario para la vista de lista)

Cada segmentación vertical ofrece una funcionalidad operativa y comprobable.

Paso 4: Redactar las tareas

Cada tarea sigue esta estructura:

## Tarea [N]: [Título descriptivo breve]

**Descripción:** Un párrafo que explique qué logra esta tarea.

**Criterios de aceptación:**
- [ ] [Condición específica y comprobable]
- [ ] [Condición específica y comprobable]

**Verificación:**
- [ ] Las pruebas se superan: `npm test -- --grep "nombre-de-la-funcionalidad"`
- [ ] La compilación se realiza con éxito: `npm run build`
- [ ] Comprobación manual: [descripción de lo que hay que verificar]

**Dependencias:** [Números de las tareas de las que depende, o «Ninguna»]

**Archivos que probablemente se modificarán:**
- `src/ruta/al/archivo.ts`
- `tests/ruta/a/prueba.ts`

**Alcance estimado:** [Pequeño: 1-2 archivos | Medio: 3-5 archivos | Grande: más de 5 archivos]

Paso 5: Orden y punto de control

Organiza las tareas de manera que:

Se cumplan las dependencias (crea primero la base)
Cada tarea deje el sistema en un estado operativo
Se realicen puntos de control de verificación cada 2-3 tareas
Las tareas de alto riesgo se realicen al principio (para detectar fallos rápidamente)

Añade puntos de control explícitos:

## Punto de control: tras las tareas 1-3
- [ ] Todas las pruebas se superan
- [ ] La aplicación se compila sin errores
- [ ] El flujo de usuario principal funciona de principio a fin
- [ ] Revisión por parte de una persona antes de continuar

Directrices para la estimación del volumen de trabajo

Tamaño	Archivos	Alcance	Ejemplo
XS	1	Cambio en una sola función o configuración	Añadir una regla de validación
S	1-2	Un componente o punto final	Añadir un nuevo punto final de API
M	3-5	Una sección de funcionalidad	Flujo de registro de usuario
L	5-8	Funcionalidad con varios componentes	Búsqueda con filtrado y paginación
XL	8+	Demasiado grande: desglosarlo aún más	—

Si una tarea es de tamaño L o mayor, debe dividirse en tareas más pequeñas. Un agente rinde mejor en tareas de tamaño S y M.

Cuándo dividir una tarea en partes más pequeñas:

Si requiere más de una sesión de trabajo concentrado (aproximadamente 2 horas o más de trabajo del agente)
No se pueden describir los criterios de aceptación en tres o menos puntos
Afecta a dos o más subsistemas independientes (por ejemplo, autenticación y facturación)
Te das cuenta de que estás escribiendo «y» en el título de la tarea (una señal de que se trata de dos tareas).

Plantilla del documento de planificación

# Plan de implementación: [Nombre de la funcionalidad/proyecto]

## Resumen
[Resumen de un párrafo sobre lo que estamos desarrollando]

## Decisiones de arquitectura
- [Decisión clave 1 y justificación]
- [Decisión clave 2 y justificación]

## Lista de tareas

### Fase 1: Bases
- [ ] Tarea 1: ...
- [ ] Tarea 2: ...

### Punto de control: Bases
- [ ] Las pruebas se superan, la compilación se realiza sin errores

### Fase 2: Funcionalidades principales
- [ ] Tarea 3: ...
- [ ] Tarea 4: ...

### Punto de control: Funcionalidades principales
- [ ] El flujo de principio a fin funciona

### Fase 3: Pulido
- [ ] Tarea 5: ...
- [ ] Tarea 6: ...

### Punto de control: Finalización
- [ ] Se cumplen todos los criterios de aceptación
- [ ] Listo para revisión

## Riesgos y medidas de mitigación
| Riesgo | Impacto | Mitigación |
|------|--------|------------|
| [Riesgo] | [Alto/Medio/Bajo] | [Estrategia] |

## Cuestiones pendientes
- [Cuestión que requiere intervención humana]

Oportunidades de paralelización

Cuando hay varios agentes o sesiones disponibles:

Se puede paralelizar con seguridad: partes independientes de las funcionalidades, pruebas de funcionalidades ya implementadas, documentación
Debe realizarse de forma secuencial: migraciones de bases de datos, cambios en el estado compartido, cadenas de dependencias
Requiere coordinación: Funcionalidades que comparten un contrato de API (definir primero el contrato y luego paralelizar)

Racionalizaciones habituales

Racionalización	Realidad
«Ya lo iré resolviendo sobre la marcha»	Así es como acabas con un lío enredado y teniendo que volver a hacer el trabajo. 10 minutos de planificación ahorran horas.
«Las tareas son obvias»	Anótalas de todos modos. Las tareas explícitas sacan a la luz dependencias ocultas y casos extremos olvidados.
«Planificar es una carga»	Planificar es la tarea. Implementar sin un plan es simplemente teclear.
«Puedo tenerlo todo en la cabeza»	Las ventanas de contexto son finitas. Los planes escritos sobreviven a los límites de las sesiones y a la compactación.

Señales de alerta

Empezar la implementación sin una lista de tareas por escrito
Tareas que dicen «implementar la funcionalidad» sin criterios de aceptación
Ausencia de pasos de verificación en el plan
Todas las tareas son de gran envergadura
No hay puntos de control entre tareas
No se tiene en cuenta el orden de las dependencias

Verificación

Antes de comenzar la implementación, confirma lo siguiente:

Que cada tarea cuente con criterios de aceptación
Cada tarea cuenta con un paso de verificación
Las dependencias de las tareas están identificadas y ordenadas correctamente
Ninguna tarea afecta a más de ~5 archivos
Existen puntos de control entre las fases principales
Una persona ha revisado y aprobado el plan

Véase también

Los criterios de aceptación son específicos de cada tarea y responden a la pregunta «¿hemos creado lo correcto?». Se sitúan por encima de la «Definición de finalizado» del proyecto, el listón que cada tarea debe superar antes de que se considere finalizada. Véase references/definition-of-done.md.

Ver en GitHub

---
name: planning-and-task-breakdown
description: Decompose work into small, verifiable tasks with explicit acceptance criteria, ordered by dependencies and sliced vertically for reliable implementation.
---

# 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:

```markdown
## 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:

1. Dependencies are satisfied (build foundation first)
2. Each task leaves the system in a working state
3. Verification checkpoints occur after every 2-3 tasks
4. High-risk tasks are early (fail fast)

Add explicit checkpoints:

```markdown
## 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

```markdown
# 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`.