Tareas dependientes en Claude Code: caza el fallo de tu plan antes de ejecutarlo

TL;DR La lista de tareas de Claude Code no es una lista, es un grafo: una tarea puede declararse bloqueada por otra y no se puede coger hasta que la bloqueante se cierra. Eso convierte la lista en otra cosa. Deja de contarte cuánto lleva hecho y empieza a contarte cómo ha entendido el trabajo, que es justo lo que necesitas auditar antes de irte cuarenta minutos.

Los runs largos ya no son una rareza. La guía de Fable 5 lo dice sin adornos: una sola petición puede correr muchos minutos, y los runs autónomos se extienden durante horas. Y añade una recomendación que casi nadie ha leído: reestructura tu forma de trabajar para consultar el run de forma asíncrona en vez de quedarte bloqueado mirando.

Perfecto. Pero entonces aparece el problema de verdad, y también está documentado: en runs largos el modelo puede fabricar informes de progreso. Anthropic lo dice literalmente y da un prompt para mitigarlo (auditar cada afirmación contra un resultado de herramienta real). O sea: el texto que te cuenta cómo va no es una fuente fiable.

Y ahí es donde el grafo de tareas se vuelve interesante, porque no es prosa. Es estructura.

Resultado (salida real de esta sesión, tres tareas encadenadas):

#50 [pending] Migración de esquema
#51 [pending] Endpoint que usa el esquema      [blocked by #50]
#52 [pending] Frontend que usa el endpoint     [blocked by #50, #51]

1. Pídelas encadenadas, no en fila

La lista plana la pides como siempre. Lo que cambia es que le pidas las dependencias:

Desglosa esto en tareas y encadena las dependencias:
marca qué tarea bloquea a cuál antes de empezar.

Claude las crea y luego declara los bloqueos. Si prefieres verlo por dentro, el mecanismo son dos campos, blockedBy y blocks, que se pueden añadir en cualquier momento sobre tareas ya creadas.

2. Léelas como una auditoría del plan, no como un progreso

Este es el cambio de chip. Cuando Claude te declara "el frontend está bloqueado por la migración", no te está informando del estado. Te está enseñando su modelo mental del cambio.

Y ese modelo lo auditas tú en treinta segundos, antes de que escriba una línea:

• Un bloqueo que no tiene sentido significa que ha entendido mal el acoplamiento.
• Dos tareas que sí dependen entre sí saliendo como independientes es peor: van a chocar, y lo descubrirás al final.
• Una cadena demasiado larga (todo bloqueado por todo) suele significar que no ha encontrado el corte natural del trabajo.

Cualquiera de las tres se ve en el grafo y ninguna se ve en una checklist plana. Ahí está la diferencia con pedir la lista para no perder el hilo: aquella la miras durante, esta la miras antes.

3. Se desbloquean solas, y por eso lo que ves es fiable

Marqué la primera tarea como completada. Sin tocar nada más:

#50 [completed] Migración de esquema
#51 [pending] Endpoint que usa el esquema
#52 [pending] Frontend que usa el endpoint     [blocked by #51]

La #51 se desbloqueó sola y la #52 se quitó la #50 de encima. La lista solo muestra los bloqueos que siguen abiertos, así que se poda sola conforme avanza el trabajo.

Eso importa más de lo que parece: lo que lees es estado derivado, no un resumen que el modelo ha vuelto a redactar. En cualquier momento del run ves qué se puede empezar ya y qué sigue esperando, sin depender de la narración.

4. Ojo: las dependencias circulares se aceptan sin avisar

Probé a bloquear la #51 con la #52, que ya estaba bloqueada por la #51:

#51 [pending] Endpoint    [blocked by #52]
#52 [pending] Frontend    [blocked by #51]

Lo aceptó sin una sola queja. Dos tareas que no se pueden coger nunca, cero avisos. En un run desatendido eso no lo notas hasta que vuelves y te encuentras el trabajo parado en seco. Si le pides cadenas de dependencias, léelas antes de irte.

Dónde encaja

Esto no es el panel /tasks, que es el tablero de los trabajos en paralelo (bashes en background, sesiones cloud, subagentes). Aquí hablamos de la checklist de la tarea actual, la de Ctrl+T, y de que además tiene aristas.

Encaja de forma natural con las tres cosas que ya sabes:

• Con /goal, que define la condición de parada. El goal dice cuándo terminar; el grafo, en qué orden.
• Con Fable 5, que es donde los runs de horas dejan de ser teóricos y donde más paga auditar el plan antes de soltarlo.
• Con los ocho consejos de Anthropic para Opus 5, que piden darle la especificación completa por delante. El grafo es la forma de comprobar que la ha entendido, y de paso el sitio donde ves si Opus 5 se ha puesto a delegar de más, porque las tareas llevan dueño.

Referencia

Documentación oficial: Interactive mode: Task list · Prompting Claude Fable 5

Requisitos

• Comprobado en Claude Code v2.1.220. Las dependencias no aparecen en la página de modo interactivo, que solo describe la checklist plana: lo de arriba sale de ejercitar las tareas en una sesión real.