4. Task Board y Dependencias

Descripción

Ya tienes un team lead que coordina y teammates que ejecutan. Pero ¿cómo sabe el team lead qué tareas existen, en qué orden ejecutarlas, y qué depende de qué? Sin un task board, el team lead improvisa — asigna tareas en el orden que le parece lógico, espera que las dependencias se resuelvan por casualidad, y no tiene forma de reportar el estado del equipo. Eso es exactamente la coordinación manual que queríamos superar.

El task board es la estructura que conecta al team lead con el trabajo. Es una lista de tareas con estados (pending, in-progress, done, blocked), asignaciones (qué teammate hace qué), dependencias (qué tarea requiere que otra termine primero), y prioridades (qué hacer primero cuando no hay dependencias). El team lead consulta el task board para decidir qué lanzar, y lo actualiza cuando un teammate reporta resultados.

En esta cápsula aprenderás a diseñar task boards en el system prompt del team lead, a declarar dependencias entre tareas, a manejar prioridades, y a entender qué pasa cuando una dependencia no se cumple. El task board es el corazón de Agent Teams — sin él, tienes un team lead con teammates pero sin plan.

⚠️ FEATURE EXPERIMENTAL

La implementación del task board en Agent Teams puede variar entre versiones de Claude Code. El concepto de task board como estructura de coordinación es estable y transferible. La cápsula enseña el patrón independientemente de la API específica.

Última verificación: Marzo 2026

El Task Board: Modelo Mental

Piensa en kanban

El task board funciona como un tablero kanban con asignación automática:

BACKLOG              IN PROGRESS          DONE
┌─────────────┐      ┌─────────────┐      ┌─────────────┐
│ T1: Schema  │  ──→ │ T2: GET API │  ──→ │             │
│ T3: PUT API │      │ (backend)   │      │             │
│ T4: UI Page │      └─────────────┘      │             │
│ T5: UI Form │                           │             │
│ T6: Review  │      BLOCKED              │             │
└─────────────┘      ┌─────────────┐      │             │
                     │ T4: UI Page │      │             │
                     │ waits for   │      │             │
                     │ T2          │      │             │
                     └─────────────┘      └─────────────┘

El team lead mueve las tarjetas. Cuando T2 pasa a DONE, verifica qué tareas bloqueadas se desbloquean (T4 esperaba T2) y las mueve a IN PROGRESS asignándolas al teammate apropiado.

Los 5 estados de una tarea

PENDING       → No iniciada, sin dependencias bloqueantes
BLOCKED       → No iniciada, esperando que dependencias terminen
IN_PROGRESS   → Asignada a un teammate, ejecutándose
DONE          → Completada exitosamente
FAILED        → Falló, necesita reintento o reasignación

El flujo normal es: PENDING → IN_PROGRESS → DONE

Con dependencias: BLOCKED → PENDING (cuando deps terminan) → IN_PROGRESS → DONE

Con fallo: IN_PROGRESS → FAILED → (retry) → IN_PROGRESS → DONE

Declarando el Task Board en el System Prompt

La estructura básica

El task board se define en el system prompt del team lead como una tabla o lista estructurada:

## Task Board

When you receive a request, break it into tasks using this format:

| ID | Task | Assigned To | Depends On | Priority | Status |
|----|------|-------------|------------|----------|--------|
| T1 | Define data schema | backend-agent | none | HIGH | PENDING |
| T2 | GET /profile endpoint | backend-agent | T1 | HIGH | BLOCKED |
| T3 | PUT /profile endpoint | backend-agent | T1 | MEDIUM | BLOCKED |
| T4 | ProfilePage component | frontend-agent | T2 | MEDIUM | BLOCKED |
| T5 | ProfileForm component | frontend-agent | T3, T4 | MEDIUM | BLOCKED |
| T6 | Integration review | team-lead | T2, T3, T4, T5 | LOW | BLOCKED |

Campos del task board

ID — Identificador corto (T1, T2, ...). El team lead y los teammates se refieren a las tareas por ID.

Task — Descripción concreta de qué hacer. No "frontend stuff" — "Create ProfilePage component that displays user data from GET /profile."

Assigned To — Qué teammate ejecutará la tarea. El team lead asigna basándose en las descriptions de los teammates.

Depends On — IDs de tareas que deben completarse antes. T4 depends on T2 significa que T4 no puede empezar hasta que T2 sea DONE.

Priority — HIGH, MEDIUM, LOW. Cuando dos tareas están listas (sin dependencias bloqueantes), la de mayor prioridad se ejecuta primero.

Status — El estado actual de la tarea.

Dependencias: El Corazón del Task Board

Tipos de dependencias

1. Dependencia directa (A → B):

T1: Define schema    →    T2: Create endpoint (usa el schema)

T2 no puede empezar sin T1 porque necesita el schema definido.

2. Dependencia múltiple (A, B → C):

T2: GET endpoint  ─┐
                    ├──→  T5: ProfileForm (usa ambos endpoints)
T3: PUT endpoint  ─┘

T5 requiere que AMBOS T2 y T3 estén completos.

3. Cadena de dependencias (A → B → C):

T1: Schema  →  T2: Endpoint  →  T4: Component  →  T5: Form

T5 depende de T4, que depende de T2, que depende de T1. Modificar T1 puede afectar a toda la cadena.

4. Dependencias paralelas independientes:

T1: Schema  →  T2: GET endpoint
            →  T3: PUT endpoint

T2 y T3 dependen de T1 pero no entre sí — pueden ejecutarse en paralelo una vez T1 esté DONE.

Visualizando dependencias como grafo

T1 (Schema)
├──→ T2 (GET /profile)
│    └──→ T4 (ProfilePage)
│         └──→ T5 (ProfileForm) ←─┐
└──→ T3 (PUT /profile) ──────────┘
                                   
T6 (Integration review) waits for T2, T3, T4, T5

Este grafo le dice al team lead:

1. Empieza con T1 (sin dependencias)
2. Cuando T1 termina → lanza T2 y T3 en paralelo
3. Cuando T2 termina → lanza T4
4. Cuando T3 y T4 terminan → lanza T5
5. Cuando T2, T3, T4, T5 terminan → ejecuta T6

Instrucciones de dependency resolution para el team lead

## Dependency Resolution

When processing the task board:

1. SCAN: Find all tasks with status PENDING (no blocked dependencies)
2. PARALLEL: If multiple tasks are PENDING and assigned to different 
   teammates, launch them in parallel
3. WAIT: When a teammate completes a task, update status to DONE
4. UNBLOCK: Check all BLOCKED tasks — if all their dependencies 
   are now DONE, change status to PENDING
5. ASSIGN: Pick the highest-priority PENDING task and assign it
6. REPEAT until all tasks are DONE or FAILED

### Dependency Rules
- NEVER assign a BLOCKED task
- When a task becomes PENDING, assign it immediately if its 
  teammate is idle
- If a task's dependency FAILED, mark the task as BLOCKED with 
  reason: "dependency T[x] failed"
- Maximum dependency chain depth: 5 (if deeper, flag for review)

Priorización: Qué Hacer Primero

Cuándo importa la prioridad

La prioridad solo importa cuando hay múltiples tareas PENDING (sin dependencias bloqueantes) y hay que decidir cuál ejecutar primero. Si solo hay una tarea PENDING, no hay decisión.

Sistema de prioridades

## Priority System

HIGH:   Critical path — other tasks depend on this
MEDIUM: Important but won't block other tasks
LOW:    Nice to have, can be skipped if time is limited

When two tasks have the same priority:
1. Prefer the one that unblocks more downstream tasks
2. Prefer the one assigned to an idle teammate
3. If still tied, prefer the lower task ID (T2 before T3)

Ejemplo de priorización

Estado actual del task board:

| ID | Task | Depends On | Priority | Status |
|----|------|------------|----------|--------|
| T2 | GET endpoint | T1 ✅ | HIGH | PENDING |
| T3 | PUT endpoint | T1 ✅ | MEDIUM | PENDING |
| T4 | Logging setup | none | LOW | PENDING |

Decisión del team lead:
1. T2 (HIGH, unblocks T4→T5) → assign to backend-agent
2. T3 (MEDIUM, unblocks T5) → assign to backend-agent en paralelo si posible
3. T4 (LOW, no unblocks) → assign solo si hay un teammate idle

Creando el Task Board Dinámicamente

El team lead genera el task board

En la práctica, el team lead no recibe un task board pre-definido — lo genera al recibir un request:

## Task Board Generation

When you receive a user request:

1. ANALYZE: Read the codebase to understand current state
2. DECOMPOSE: Break the request into 4-8 specific tasks
3. ASSIGN: Match each task to the best teammate
4. DEPENDENCIES: Identify which tasks depend on others
5. PRIORITIZE: Set priority based on critical path
6. PRESENT: Show the task board to the user before executing

### Decomposition Rules
- Each task should be completable in 1-5 files
- Each task should have a single clear deliverable
- Tasks should be assigned to a single teammate
- If a task is too large, split it
- If a task is trivial (1 line change), merge it with another

### Presenting the Task Board
Before executing, show:

📋 Task Board for: [request summary]

Dependency graph: T1 → T2 → T4 → T3 → T5

Ready to execute? [Proceed / Modify]

Esto le da al usuario visibilidad y la oportunidad de ajustar antes de que el equipo empiece a ejecutar.

Qué Pasa Cuando una Dependencia No Se Cumple

Escenario: un teammate falla

T1: Schema      → DONE ✅
T2: GET endpoint → FAILED ❌  (backend-agent reportó un error)
T4: ProfilePage  → BLOCKED 🔒 (depende de T2)

El team lead tiene varias opciones:

Opción 1: Retry — Reasignar T2 al mismo teammate con información del error:

When a task FAILS:
1. Read the teammate's error report
2. If the error is recoverable (wrong approach, missing context):
   - Provide additional context and retry
   - Maximum 2 retries per task
3. If the error is not recoverable (missing dependency, wrong assignment):
   - Reassign to a different teammate if one is capable
   - If no teammate can handle it, report to user

Opción 2: Reasignar — Si el backend-agent no puede resolver el error, intentar con otro teammate (si alguno tiene la capacidad).

Opción 3: Escalar — Reportar al usuario que T2 falló, T4 y T5 están bloqueados, y el equipo no puede continuar sin intervención.

Escenario: dependencia circular

T2 depends on T3
T3 depends on T2

Esto es un deadlock — ninguna tarea puede empezar. El team lead debe detectarlo:

## Circular Dependency Detection

Before starting execution:
1. Trace each dependency chain to verify it terminates
2. If task A depends on B and B depends on A (directly or 
   indirectly), STOP and report:
   "Circular dependency detected: T2 ↔ T3. Cannot proceed.
    Suggest: remove one dependency or merge tasks."

Escenario: dependencia parcialmente cumplida

T5 depends on T3 (DONE ✅) and T4 (PARTIAL ⚠️)

T4 se completó parcialmente — el frontend-agent creó el componente pero no pudo implementar un prop porque le faltaba un tipo. ¿Lanza T5?

## Partial Completion Handling

If a dependency task reports PARTIAL:
1. Read what was completed and what's missing
2. If T5 can proceed with what's available, unblock T5
3. If T5 needs the missing parts, keep T5 BLOCKED
4. Create a new task (T4b) for the missing parts
5. Update T5's dependencies: depends on T3, T4b

Patrones de Task Board

Patrón: Pipeline lineal

T1 → T2 → T3 → T4

Cada tarea depende de la anterior. Simple pero lento — no hay paralelismo.

Uso: Cuando cada paso necesita el output completo del anterior
Ejemplo: Schema → Migration → Endpoint → Tests

Patrón: Fan-out / Fan-in

      ┌→ T2 ─┐
T1 ──┤       ├──→ T5
      └→ T3 ─┤
      └→ T4 ─┘

T1 produce un resultado. T2, T3, T4 trabajan en paralelo sobre diferentes aspectos. T5 integra los resultados.

Uso: Cuando el trabajo se puede dividir en partes independientes
Ejemplo: Schema → (GET endpoint || PUT endpoint || DELETE endpoint) → Tests

Patrón: Diamond

T1 ──→ T2 ──→ T4
  └──→ T3 ──┘

T2 y T3 dependen de T1 y se ejecutan en paralelo. T4 depende de ambos.

Uso: Frontend y backend trabajan en paralelo tras una fase de diseño
Ejemplo: Design → (Frontend || Backend) → Integration

Patrón: Staged pipeline

Stage 1:  T1
Stage 2:  T2, T3     (parallel, both depend on T1)
Stage 3:  T4, T5     (parallel, T4 dep T2, T5 dep T3)
Stage 4:  T6         (depends on T4, T5)

Múltiples stages, cada uno con tareas paralelas.

Uso: Proyectos grandes con fases de desarrollo claras
Ejemplo: Data models → (API + UI skeleton) → (API logic + UI components) → Integration

Alternativa Manual: Task Board sin Agent Teams

Si Agent Teams no está disponible, implementa el task board en el system prompt del coordinador:

---
name: coordinator
tools: Agent(frontend-agent), Agent(backend-agent), Read, Glob, Grep
model: sonnet
maxTurns: 60
---

## Task Board Management

You maintain a task board mentally. When you receive a request:

1. Generate the task board (list of tasks with dependencies)
2. Show it to the user for approval
3. Execute tasks in dependency order:
   a. Find all tasks with no unmet dependencies
   b. For tasks assigned to different teammates: delegate in parallel
   c. Wait for results
   d. Update statuses and check what's unblocked
   e. Repeat until all tasks are DONE or FAILED

## Status Tracking

After each round, display:

📋 Progress Update T1 [DONE] ✅ — Schema defined T2 [IN_PROGRESS] 🔄 — backend-agent working... T3 [BLOCKED] 🔒 — waiting for T1 T4 [PENDING] ⏳ — ready but teammate busy

## Dependency Check (before each assignment)

For each task to assign:
- List its dependencies
- Verify each dependency is DONE
- If any dependency is not DONE → do NOT assign, mark BLOCKED
- If all dependencies are DONE → assign to teammate

La diferencia con Agent Teams: aquí el coordinador mantiene el estado mentalmente y lo reporta en texto. Con Agent Teams, el task board es una estructura formal que el team lead gestiona con primitivas del sistema.

Troubleshooting

"El team lead ejecuta tareas sin respetar dependencias"

Causa: Las instrucciones de dependency resolution no son explícitas, o el team lead no verifica antes de asignar.

Solución: Agrega una regla enfática:

CRITICAL RULE: Before assigning ANY task, you MUST:
1. List the task's dependencies by ID
2. Check the status of each dependency
3. If ANY dependency is not DONE, DO NOT assign the task
4. Log: "Task T[x] blocked — waiting for T[y] (status: [status])"

"El team lead crea demasiadas tareas (10+)"

Causa: Descomposición excesivamente granular.

Solución: Agrega una regla de tamaño:

## Task Sizing Rules
- Minimum: 2 files affected per task (if less, merge with adjacent)
- Maximum: 6 files affected per task (if more, split)
- Total tasks: 4-8 for a typical feature request
- If you generate more than 8 tasks, consolidate related ones

"Las prioridades no afectan el orden de ejecución"

Causa: El team lead procesa tareas por ID (T1, T2...) en lugar de por prioridad.

Solución: Haz la prioridad parte del proceso de selección:

When selecting the next task to assign:
1. Filter: only PENDING tasks (dependencies met)
2. Sort by: Priority (HIGH > MEDIUM > LOW)
3. Break ties by: which task unblocks more downstream tasks
4. Assign the first task in the sorted list

"El task board no se muestra al usuario antes de ejecutar"

Causa: El system prompt no incluye el paso de presentación.

Solución: Agrega un paso obligatorio de presentación:

## Pre-Execution Step (MANDATORY)

After generating the task board and BEFORE executing any task:
1. Display the complete task board to the user
2. Show the dependency graph
3. Ask: "Ready to execute? Say 'proceed' or suggest changes."
4. Only proceed after confirmation

"No puedo ver el progreso mientras el equipo ejecuta"

Causa: El team lead no reporta progreso intermedio.

Solución: Agrega progress reports después de cada tarea completada:

After EACH task completion, display:
📋 Progress: [completed]/[total] tasks
- T[x] [DONE] ✅ — [1-line summary]
- T[y] [IN PROGRESS] 🔄 — [teammate] working
- T[z] [UNBLOCKED] → ready to assign

Ejercicios

Ejercicio 1: Diseñar un task board básico (Fácil)

Dado el request "Agrega una página de contacto con formulario que envía un email", crea un task board con 4-5 tareas, asignaciones a frontend-agent y backend-agent, y dependencias.

| ID | Task | Assigned To | Depends On | Priority | Status |
|----|------|-------------|------------|----------|--------|
| T1 | Create email service in src/services/ | backend-agent | none | HIGH | PENDING |
| T2 | POST /contact endpoint | backend-agent | T1 | HIGH | BLOCKED |
| T3 | ContactPage layout | frontend-agent | none | MEDIUM | PENDING |
| T4 | ContactForm component with validation | frontend-agent | T2, T3 | MEDIUM | BLOCKED |
| T5 | Success/error feedback UI | frontend-agent | T4 | LOW | BLOCKED |

Dependency graph:
T1 → T2 ──→ T4 → T5
T3 ────────┘

Parallel opportunities:
- T1 and T3 can run simultaneously (no dependencies)
- T4 waits for both T2 and T3

Ejercicio 2: Detectar dependencias incorrectas (Fácil)

Este task board tiene 3 problemas de dependencias. Encuéntralos:

| ID | Task | Depends On |
|----|------|------------|
| T1 | Create model | none |
| T2 | Create endpoint | T3 |
| T3 | Create migration | T2 |
| T4 | Write tests | T1 |
| T5 | Deploy | T4 |

| ID | Task | Depends On |
|----|------|------------|
| T1 | Create model | none |
| T3 | Create migration | T1 |
| T2 | Create endpoint | T3 |
| T4 | Write tests | T2 |
| T5 | Deploy | T2, T4 |

Ejercicio 3: Task board con fan-out/fan-in (Medio)

Diseña un task board para "Implementar sistema de notificaciones con push, email, y in-app" usando el patrón fan-out/fan-in. Debe tener una fase de diseño, tres implementaciones paralelas, y una fase de integración.

| ID | Task | Assigned To | Depends On | Priority |
|----|------|-------------|------------|----------|
| T1 | Design notification interface | backend-agent | none | HIGH |
| T2 | Push notification service | backend-agent | T1 | HIGH |
| T3 | Email notification service | backend-agent | T1 | HIGH |
| T4 | In-app notification service | backend-agent | T1 | MEDIUM |
| T5 | Notification preferences UI | frontend-agent | T1 | MEDIUM |
| T6 | Notification center component | frontend-agent | T4 | MEDIUM |
| T7 | Integration: unified send API | backend-agent | T2, T3, T4 | HIGH |
| T8 | E2E test all channels | team-lead | T6, T7 | LOW |

Graph:
         ┌→ T2 (push) ────────┐
T1 ──────┤→ T3 (email) ───────├──→ T7 (unified API) → T8
         ├→ T4 (in-app) ──┬───┘                        ↑
         └→ T5 (prefs UI) │                             │
                           └→ T6 (notification center) ─┘

Parallelism:
- Stage 1: T1
- Stage 2: T2, T3, T4, T5 (all parallel)
- Stage 3: T6 (after T4), T7 (after T2, T3, T4)
- Stage 4: T8 (after T6, T7)

Ejercicio 4: Manejo de fallo en cadena (Medio)

T1 → T2 → T4 → T5, y T2 falla. Escribe las instrucciones paso a paso que el team lead debe seguir. Incluye: qué hacer con T4 y T5, cuándo reintentar, y cuándo escalar al usuario.

## When T2 FAILS:

### Step 1: Assess the failure
- Read T2's error report
- Classify: recoverable (wrong approach) or blocking (missing resource)

### Step 2: Impact analysis
- T4 depends on T2 → mark T4 as BLOCKED (reason: T2 failed)
- T5 depends on T4 → mark T5 as BLOCKED (reason: T4 blocked)
- No other tasks affected

### Step 3: Recovery attempt
IF recoverable:
  - Provide T2 with error context and additional guidance
  - Retry T2 (attempt 2 of max 2)
  - If retry succeeds → unblock T4 → proceed normally
  - If retry fails → go to Step 4

IF blocking:
  - Go to Step 4

### Step 4: Escalation
Report to user:
"Task T2 (GET /profile endpoint) failed after 2 attempts.
 Error: [error description]
 Impact: T4 (ProfilePage) and T5 (ProfileForm) are blocked.
 Options:
 1. Provide additional guidance for T2
 2. Skip T2 and its dependents
 3. Manually resolve and continue"

### Step 5: Update task board
Display current state clearly:
T1 [DONE] ✅
T2 [FAILED] ❌ — [error summary]
T3 [DONE] ✅ (independent)
T4 [BLOCKED] 🔒 — waiting for T2
T5 [BLOCKED] 🔒 — waiting for T4

Ejercicio 5: Optimizar un task board ineficiente (Difícil)

Este task board tiene todo en serie. Reorganízalo para maximizar paralelismo sin romper dependencias lógicas:

T1: Create User model → T2: Create migration → T3: GET /users → 
T4: POST /users → T5: User list component → T6: User form component → 
T7: Write tests

| ID | Task | Depends On | Parallel Group |
|----|------|------------|----------------|
| T1 | Create User model | none | Stage 1 |
| T2 | Create migration | T1 | Stage 2 |
| T3 | GET /users endpoint | T2 | Stage 3a |
| T4 | POST /users endpoint | T2 | Stage 3a (parallel) |
| T5 | User list component | T3 | Stage 4a |
| T6 | User form component | T4 | Stage 4a (parallel) |
| T7 | Write tests | T3, T4 | Stage 4b |

Graph:
T1 → T2 → T3 → T5
         → T4 → T6
         → T3, T4 → T7

Execution:
Stage 1: T1
Stage 2: T2
Stage 3: T3 + T4 (parallel!)
Stage 4: T5 + T6 + T7 (all parallel!)

Original: 7 stages (all serial)
Optimized: 4 stages (with parallelism)

Ejercicio 6: Task board completo con 3 teammates (Difícil)

Diseña un task board para "Implementar autenticación con registro, login, y perfil" con 3 teammates (db-dev, api-dev, frontend-agent). Mínimo 6 tareas, dependencias reales, prioridades justificadas, y el grafo de dependencias.

| ID | Task | Agent | Depends | Pri | Justification |
|----|------|-------|---------|-----|---------------|
| T1 | User model + migration | db-dev | none | HIGH | Everything needs the model |
| T2 | Auth service (hash, JWT) | api-dev | T1 | HIGH | Core auth logic |
| T3 | POST /register | api-dev | T2 | HIGH | First user flow |
| T4 | POST /login + token | api-dev | T2 | HIGH | Second user flow |
| T5 | GET /profile (protected) | api-dev | T4 | MEDIUM | Needs auth middleware |
| T6 | Register form + page | frontend-agent | T3 | MEDIUM | Uses register endpoint |
| T7 | Login form + page | frontend-agent | T4 | MEDIUM | Uses login endpoint |
| T8 | Profile page (protected) | frontend-agent | T5, T7 | LOW | Needs login + profile API |

Graph:
T1 → T2 → T3 → T6
         → T4 → T5 → T8
              → T7 ──┘

Parallel opportunities:
Stage 1: T1
Stage 2: T2
Stage 3: T3 + T4 (parallel)
Stage 4: T5 + T6 + T7 (parallel, different agents!)
Stage 5: T8

Total stages: 5 (vs 8 if all serial)

Resumen

• El task board es la estructura central de Agent Teams — conecta al team lead con el trabajo del equipo
• Cada tarea tiene: ID, descripción, asignación, dependencias, prioridad, y estado
• Las dependencias determinan el orden de ejecución — el team lead nunca asigna una tarea cuyas dependencias no están DONE
• Los 5 estados: PENDING → IN_PROGRESS → DONE (normal), BLOCKED (esperando deps), FAILED (error)
• Hay 4 patrones comunes: pipeline lineal, fan-out/fan-in, diamond, y staged pipeline
• La prioridad solo importa cuando hay múltiples tareas PENDING — HIGH se ejecuta antes que MEDIUM
• Cuando una dependencia falla, el team lead tiene 3 opciones: retry, reasignar, o escalar
• Las dependencias circulares son un deadlock — el team lead debe detectarlas antes de ejecutar
• Sin Agent Teams, el task board se implementa en el system prompt del coordinador con la misma lógica

Recursos Adicionales

1. Create Custom Subagents (Anthropic Docs) — Documentación oficial de agent files y coordinación
2. Claude Code Best Practices — Buenas prácticas de delegación y task management
3. Claude Code CLI Reference — Referencia de CLI para ejecutar agent files
4. Multi-Agent Orchestration — Patrones de coordinación multi-agente
5. Prompt Engineering: System Prompts — Técnicas para system prompts de coordinación
6. DAG (Directed Acyclic Graph) — Fundamento teórico de grafos de dependencias
7. Kanban Method — El modelo mental detrás del task board
8. Claude Code Overview — Contexto general de Claude Code

Siguiente cápsula: En la cápsula 05 aprenderás cómo los teammates se comunican entre sí y cómo el team lead resuelve conflictos. Verás qué pasa cuando dos teammates producen resultados contradictorios, cómo gestionar el caso de un teammate que termina antes que los demás (TeammateIdle), y los failure modes más comunes de un equipo de agentes.