mattpocock/to-tickets

A Tickets

Divide un plan, especificación o conversación en un conjunto de tickets: cortes verticales tipo bala trazadora, cada uno declarando los tickets que lo bloquean.

El vocabulario del tracker de incidencias y de las etiquetas de triaje deberían haberte sido proporcionados. Si no es así, dile al usuario que ejecute /setup-matt-pocock-skills.

Proceso

1. Recopilar contexto

Trabaja a partir de lo que ya esté en el contexto de la conversación. Si el usuario pasa una referencia (ruta de especificación, número de incidencia o URL) como argumento, recupérala y lee su cuerpo completo y comentarios.

2. Explorar el código base (opcional)

Si aún no has explorado el código base, hazlo para entender el estado actual del código. Los títulos y descripciones de los tickets deben usar el glosario de dominio del proyecto y respetar los ADR en el área que tocan.

Busca oportunidades de prefactorizar el código para facilitar la implementación. "Haz que el cambio sea fácil, luego haz el cambio fácil".

3. Redactar cortes verticales

Divide el trabajo en tickets de bala trazadora.

• Cada corte atraviesa un camino estrecho pero COMPLETO a través de todas las capas (esquema, API, UI, tests): vertical, NO un corte horizontal de una sola capa
• Un corte completado es demostrable o verificable por sí mismo
• Cada corte está dimensionado para caber en una única ventana de contexto nueva
• Cualquier prefactorización debe hacerse primero

Asigna a cada ticket sus aristas de bloqueo: los otros tickets que deben completarse antes de que pueda comenzar. Un ticket sin bloqueadores puede comenzar inmediatamente.

Los refactors amplios son la excepción al corte vertical. Un refactor amplio es un cambio mecánico (renombrar una columna, cambiar el tipo de un símbolo compartido) cuyo radio de explosión se extiende por todo el código base, de modo que una sola edición rompe miles de puntos de llamada a la vez y ningún corte vertical puede pasar en verde. No lo fuerces a una bala trazadora; secuencialo como expandir–contraer. Primero expande: añade la nueva forma junto a la antigua para que nada se rompa. Luego migra los puntos de llamada en lotes según el radio de explosión (por paquete, por directorio), cada lote con su propio ticket bloqueado por la expansión, manteniendo CI verde lote a lote porque la forma antigua aún existe. Finalmente contrae: elimina la forma antigua una vez que no quede ningún llamante, en un ticket bloqueado por cada lote de migración. Cuando ni siquiera los lotes pueden mantenerse verdes solos, mantén la secuencia pero permíteles compartir una rama de integración que todos bloqueen para un ticket final de integrar-y-verificar; el verde se promete solo allí.

4. Preguntar al usuario

Presenta el desglose propuesto como una lista numerada. Para cada ticket, muestra:

• Título: nombre descriptivo corto
• Bloqueado por: qué otros tickets (si los hay) deben completarse primero
• Qué entrega: el comportamiento de extremo a extremo que este ticket hace funcionar

Pregunta al usuario:

• ¿La granularidad parece correcta? (demasiado gruesa / demasiado fina)
• ¿Las aristas de bloqueo son correctas: cada ticket solo depende de tickets que realmente lo condicionan?
• ¿Algún ticket debería fusionarse o dividirse más?

Itera hasta que el usuario apruebe el desglose.

5. Publicar los tickets en el tracker configurado

Publica los tickets aprobados. Cómo depende del tracker que /setup-matt-pocock-skills haya configurado; los tickets son los mismos en ambos casos, solo cambia la forma de las aristas de bloqueo:

• Archivos locales → escribe un archivo por ticket en .scratch/<feature-slug>/issues/<NN>-<slug>.md, numerados desde 01 en orden de dependencias (los bloqueadores primero). Cada archivo "Bloqueado por" lista los números/títulos de los que depende. Usa la plantilla de archivo por ticket a continuación: un ticket por archivo, nunca un único archivo combinado.
• Un tracker de incidencias real (GitHub, Linear, …) → publica una incidencia por ticket en orden de dependencia (bloqueadores primero) para que las aristas de bloqueo de cada ticket puedan hacer referencia a identificadores reales. Usa la relación nativa de bloqueo / sub-incidencia de la plataforma si la tiene; en caso contrario, establece que "Bloqueado por" de cada ticket se refiera a las incidencias bloqueadoras. Aplica la etiqueta de triaje ready-for-agent a menos que se indique lo contrario; los tickets son agarrables por agentes por construcción.

Trabaja la frontera: cualquier ticket cuyos bloqueadores estén todos completados. Para una cadena puramente lineal, eso significa de arriba a abajo.

NO cierres ni modifiques ninguna incidencia padre.

: <Título del ticket>

Qué construir: el comportamiento de extremo a extremo que este ticket hace funcionar, desde la perspectiva del usuario, no una lista de implementación capa por capa.

Bloqueado por: los números/títulos de los tickets que condicionan este, o "Ninguno (puede comenzar inmediatamente)".

Estado: ready-for-agent

• Criterio de aceptación 1
• Criterio de aceptación 2

Padre

Una referencia a la incidencia padre en el tracker (si la fuente era una incidencia existente, de lo contrario omitir esta sección).

Qué construir

El comportamiento de extremo a extremo que este ticket hace funcionar, desde la perspectiva del usuario, no capa por capa.

Criterios de aceptación

• Criterio 1
• Criterio 2

Bloqueado por

• Una referencia a cada ticket bloqueador, o "Ninguno (puede comenzar inmediatamente)".

En cualquier forma, evita rutas de archivo o fragmentos de código específicos: se vuelven obsoletos rápidamente. Excepción: si un prototipo produjo un fragmento que codifica una decisión con mayor precisión que el texto (máquina de estados, reducer, esquema, forma de tipo), inclúyelo y anota brevemente que provino de un prototipo. Recorta las partes ricas en decisión, no un demo funcional, solo las partes importantes.