Comando Task: tareas con orden lógico

El comando task de Spec Kit convierte tu plan de trabajo en tareas atómicas ordenadas de forma lógica, listas para ejecutar. Si ya tienes los planos, el plan y el cronograma de tu proyecto, este es el paso donde defines qué se construye primero. Es ideal para quien trabaja con Claude Code y quiere evitar el caos del backlog tradicional.

Piensa en la analogía de la construcción: ya tienes los planos de la casa, el plan de trabajo y el cronograma. Pero los encargados de construir no pueden empezar a pegar ladrillos con eso. Ellos necesitan recibir tarea por tarea. Justo eso resuelve el comando que vamos a ejecutar [00:14].

Cómo preparo Git antes de ejecutar el comando task

Antes de generar las tareas, conviene dejar el proyecto ordenado en su propia rama, tal como venimos haciendo con los comandos anteriores.

Abre la terminal y posiciónate en la raíz del proyecto. El flujo es sencillo:

1. Revisa en qué rama estás con git branch. En este punto estamos en la rama plan.
2. Verifica el estado del proyecto con git status para ver archivos sin trackear.
3. Guarda los cambios con git add y luego git commit con el comentario "Plan del proyecto".
4. Crea la nueva rama con git checkout -b task, que además te posiciona en ella.

Trabajar cada comando en su propia rama te permite trackear los cambios sin mezclar etapas del proyecto [00:44].

¿Para qué sirve el comando task en Spec Kit? Toma el plan de trabajo ya definido y lo atomiza tarea por tarea en un orden lógico. En lugar de una lista suelta, obtienes una secuencia ejecutable con fases claras.

Qué genera Claude Code al ejecutar speckit task

Una vez en la rama, abres Claude Code y ejecutas speckit --task. Lo que hace la herramienta es tomar el plan de trabajo que ya definiste y atomizarlo en tareas concretas [01:20].

Después de unos minutos, el proceso termina y genera un archivo llamado tasks.md con 50 tareas [01:39]. Ese archivo lo encuentras dentro del proyecto, en la carpeta specs, junto a los demás documentos del flujo.

Al abrirlo verás una estructura con información de contexto, pero lo valioso son las tareas en sí y cómo están organizadas.

Por qué las tareas se agrupan por fase y no como lista suelta

Aquí viene lo interesante. Cada tarea no aparece en desorden: está agrupada por fase, entendiendo que hay etapas que deben hacerse antes que otras [02:06].

La fase principal es el setup. Dentro de cada fase encuentras señales muy útiles:

• La etiqueta #p, que indica qué tareas se pueden ejecutar en paralelo.
• La referencia a la historia de usuario a la que pertenece cada tarea.
• Alertas de dependencia, como que ninguna historia de usuario puede comenzar hasta que la fase dos esté completa [02:34].

Estas alertas son las que te salvan de arrancar algo que todavía no tiene su base lista. Ese orden es exactamente lo que marca la diferencia con el enfoque tradicional.

¿Qué diferencia hay entre tasks.md y un backlog tradicional? En el backlog listas tareas a la vía: crea este componente, este del backend, este de la base de datos, sin un orden lógico. Con tasks.md, Spec Kit atomiza el plan y además define la secuencia en que debe ejecutarse cada tarea.

Qué significa etiquetar tareas por historia de usuario

Que cada tarea indique a qué historia de usuario pertenece te da trazabilidad. Sabes por qué existe esa tarea y qué valor entrega al usuario final.

Esto conecta el trabajo técnico con la intención del producto. No estás creando componentes sueltos; estás construyendo piezas que responden a una necesidad concreta y en el momento correcto del proyecto.

¿Qué significa la etiqueta #p en tasks.md? Marca las tareas que puedes ejecutar de forma paralela. Te ayuda a optimizar tiempos al identificar qué trabajo no depende de otro dentro de la misma fase.

El gran aporte es este: Claude Code con Spec Kit toma tu plan, lo atomiza por tareas y te entrega el orden lógico de ejecución. Ese detalle, en un backlog común, muchas veces pasa desapercibido y termina generando bloqueos.

Cuéntanos en los comentarios en qué proyecto estás trabajando y cuáles fueron esas tareas que identificaste en tu archivo tasks.md que, con un backlog, no habrías notado. En la siguiente clase ejecutamos el comando implement.