Skills de spec y plan en el plugin de Claude Code: la misma spec para todo el equipo

Hola, bienvenido. En esta lección vamos a crear las skills spec y plan del plugin team, cada una con las plantillas del equipo, y a usarlas con la primera feature de helpdesk que necesita spec: la asignación de tickets a los agentes de soporte, con el historial de sus estados. Al terminar tendremos la spec, el plan y 3 tareas en el repo, y el plugin en la versión 1.8.0.

En la lección anterior vimos que la asignación de tickets tiene 3 de las 5 señales que llevan a una spec: una regla de negocio nueva, 2 actores y un diseño que el equipo tiene que acordar. En el equipo de Marta, las specs ya existían, pero cada una salía con otra estructura. Las de Marta empezaban por el contexto y terminaban en criterios de aceptación. Las de Jorge eran una lista de tareas sin decir qué se quería conseguir. Y Aitor no sabía dónde guardarlas, así que acababan en la descripción de la pull request. Revisar una spec era leer un formato distinto cada vez, y el plan dependía de quién lo escribiera.

Spec-Driven Development, el desarrollo guiado por especificación, tiene su propio curso en la plataforma, Spec-Driven Development en Laravel con IA↗ (se abre en una pestaña nueva), y la lección Spec-Driven Development con Claude Code: una feature de principio a fin↗ (se abre en una pestaña nueva) del curso de Claude Code recorre el ciclo una vez. Aquí vamos a convertir esa forma de trabajar en 2 skills del plugin, para que la spec, el plan y las tareas salgan con la misma estructura en todo el equipo y en todos los repos.

spec escribe la spec de una feature a partir de una entrevista. Claude te pregunta lo que hay que decidir antes de programar, como quién hace qué, qué reglas hay, qué queda fuera y cómo se comprueba, y escribe las respuestas con la plantilla del equipo. Cada spec tiene su carpeta en .claude/specs/, con un número de 3 cifras y un nombre corto, como 001-asignacion-tickets. La spec dice qué hace la feature y cómo se sabe que funciona, nunca qué clases o archivos se crean.

plan parte de una spec ya revisada. Claude lee la spec y el código del repo, propone el plan en la conversación y, cuando lo confirmas, lo escribe en plan.md y parte la feature en tareas, una por archivo en tasks/. Cada tarea tiene su objetivo, sus piezas, los criterios de aceptación que cubre, cómo se cierra y el commit que propone. Así queda la carpeta de una spec con su plan y sus tareas:

Ninguna de las 2 skills escribe código. El código lo escribirá task, tarea a tarea, en la siguiente lección.

Las plantillas viven en la carpeta de cada skill, en templates/, y no en el repo. Una plantilla del equipo es parte de cómo se trabaja, y cambia con una versión del plugin, como cualquier otra pieza. Si mañana el equipo decide que toda spec lleva un apartado de riesgos, se añade a la plantilla, se publica una versión y todas las specs nuevas lo tienen.