Implementar las tareas de la spec con la skill task y cerrar la feature con la skill cierre

Hola, bienvenido. Con esta lección termina el bloque de spec, plan y tareas. Vamos a enseñar a la skill task a trabajar con la ruta de una tarea, a implementar con ella la primera tarea de la asignación de tickets y a crear la última skill del bloque, cierre, que comprueba la feature contra su spec. Todo eso será la versión 1.9.0 del plugin, la última del curso.

En la lección anterior dejamos la spec de la asignación de tickets con su plan y 3 tareas. Falta implementarla, y ahí vuelven las diferencias del día a día. Si cada persona pide su tarea a Claude con sus palabras, cada tarea sale implementada de una forma: una con el test primero, otra sin pasar la QA, otra con un commit que no dice qué tarea cierra. Y al terminar la última tarea, nadie comprueba que la feature cumple la spec, criterio a criterio. Se da por hecha porque los tests pasan, aunque un criterio se haya quedado sin test.

Para que cada tarea se implemente siempre igual no hace falta una skill nueva. Una tarea de la spec es trabajo como el de la lección 25, con el plan ya hecho y revisado, así que la misma task puede hacerla con el mismo ciclo. Para comprobar al final que la feature cumple la spec, vamos a crear cierre.

Con una descripción libre, task decide si hace falta spec y propone un plan. Con la ruta de una tarea, las 2 cosas ya están resueltas: la spec existe y la tarea trae sus piezas, sus criterios de aceptación y su commit propuesto. Así que task lee la tarea, la spec y el plan, y pasa directamente a la implementación, la QA y el commit.

Queda una pregunta: cómo sabe task si la tarea ya está hecha. La tarea no tiene una casilla que marcar, y no la necesita, porque el estado de la feature ya está en git. Cada tarea tiene un commit propuesto que no se repite en la feature. Si ese commit está en git log, la tarea está hecha, y si no, está pendiente. Una casilla hay que acordarse de marcarla, y puede decir que una tarea está hecha aunque su código no haya llegado a la rama. Un commit, en cambio, solo está en el historial si el código está.

Vamos a crear la rama de esta versión, en la pestaña claude-plugins:

Vamos a cambiar claude-plugins/plugins/team/skills/task/SKILL.md:

Son 4 cambios. La descripción y la pista del argumento dicen que la skill acepta también la ruta de una tarea. allowed-tools permite git log, con el que la skill busca en todo el historial el commit propuesto de la tarea, por antiguo que sea. Esa aprobación solo dura el turno en que invocas la skill, y basta, porque la búsqueda es lo primero que hace, antes de que confirmes nada. Y solo cubre un git log que vaya solo: si Claude lo combina con un cd o con otros comandos en la misma línea, te pedirá permiso. Por eso la skill le pide lanzar la búsqueda como un comando aparte. El apartado nuevo, "Si la tarea es de una spec", es el que cambia el recorrido: lee la tarea con su spec y su plan, comprueba en los commits si ya está hecha y se salta las señales de spec y el paso del plan. Y el commit, en una tarea de una spec, es el que propone la tarea.

Para un fix o una feature acotada no cambia nada: las señales de spec y el ciclo son los de la lección 25.