La habilidad /to-tickets

Fuente: The /to-tickets Skill — traducción comunitaria no oficial al español.

Qué hace

to-tickets toma un plan, una spec, o la conversación en la que estás, y la divide en un conjunto de tickets en tu gestor de pendientes. Cada ticket declara sus aristas de bloqueo: los otros tickets que tienen que terminar antes de que pueda empezar.

Cada ticket es una bala trazadora: un camino estrecho pero completo a través de cada capa del cambio (esquema, API, UI, pruebas) que se puede demostrar por sí solo en cuanto aterriza. Esa es la restricción que la hace comportarse distinto de la forma obvia de dividir el trabajo, que es cortar una capa a la vez e integrar al final. También dimensiona cada ticket para que quepa en una sola ventana de contexto nueva, porque lo que recogerá el ticket es una sesión que nunca ha visto tu spec.

Cuándo usarla

La invocas escribiendo /to-tickets. El agente no la usará por su cuenta.

Dónde estás	Qué ejecutar
Tienes un issue de spec y la construcción abarca varias sesiones	`/to-tickets`, o `/to-tickets #<spec_issue>`
El plan solo está en la conversación, nunca se redactó	`/to-tickets` lee el hilo directamente, no necesita spec
Todo el cambio cabe en una ventana de contexto	implement, sáltate los tickets
Nada está decidido aún	grill-with-docs, luego to-spec
Un mapa de wayfinder se ha despejado	to-spec primero, para colapsar el mapa, luego `/to-tickets`

Los tickets que produce to-tickets están listos para agentes por construcción. No ejecutes triaje sobre ellos. El triaje es para trabajo que llegó de otra persona.

Requisitos previos

to-tickets publica en un gestor, así que setup-matt-pocock-skills debe haber configurado uno para este repositorio, junto con el vocabulario de etiquetas de triaje. Valen ambos tipos: un gestor real como GitHub o Linear, o archivos Markdown locales bajo .scratch/, que funciona sin configuración.

Balas trazadoras, no capas

Un recorte horizontal publica una capa del cambio. Nada funciona hasta que cada capa ha aterrizado, y los criterios de aceptación de cada ticket tienen que alcanzar trabajo que posee otro ticket. Un recorte vertical (la bala trazadora) publica un camino fino a través de todas las capas a la vez, así que es verificable solo y posee todo lo que califica.

Esta es la regla que la gente rompe más a menudo, y las consecuencias están bien documentadas. Un equipo ejecutó una pila de 26 tickets cortada por capas (corpus, productor, agregador, selector) y obtuvo unas veinte ejecuciones de agente por ticket cerrado, unas tres cuartas partes de ellas retrabajo. Su propia autopsia rastreó cada clase de fallo al corte horizontal en lugar de a las implementaciones.

Dos cosas ocurren antes de que nada se publique. to-tickets busca prefactorización (el principio “facilita el cambio, luego haz el cambio fácil”) y ordena ese trabajo primero. Luego presenta el desglose como lista numerada y te interroga sobre él: si la granularidad está bien, si las aristas de bloqueo son reales, si algo debería fusionarse o dividirse. Nada llega al gestor hasta que lo apruebas, y ese interrogatorio es el lugar para oponerte.

Aristas de bloqueo

Las aristas son el sentido del artefacto. Se leen de dos formas según el gestor:

Gestor	Dónde viven las aristas	Cómo las trabajas
Markdown local	Texto en un archivo por ticket bajo `.scratch/<feature>/issues/<NN>-<slug>.md`, numerados con bloqueadores primero	De arriba a abajo, a mano
Un gestor real (GitHub, Linear)	Enlaces nativos de bloqueo, o sub-issues donde el gestor los tiene	Cualquier ticket cuyos bloqueadores estén hechos está en la frontera y se puede tomar

Las aristas viven en el ticket de cualquier forma. El medio solo decide si algo puede actuar sobre ellas en paralelo. to-tickets produce el artefacto; ejecutarlo (una sesión a la vez, o una flota) es tu trabajo, no el de la habilidad.

La excepción del refactor amplio

Una forma rompe la regla de la bala trazadora. Un refactor amplio es un solo cambio mecánico (renombrar una columna, reescribir un símbolo compartido) cuyo radio de impacto se abre en abanico por toda la base de código, así que una edición rompe miles de llamadas y ningún recorte vertical puede aterrizar en verde.

to-tickets lo secuencia como expandir–contraer en su lugar:

Expandir: añade la nueva forma junto a la vieja, para que nada se rompa.
Migrar: mueve las llamadas en lotes dimensionados por radio de impacto (por paquete, por directorio), un ticket por lote, cada uno bloqueado por la expansión. CI sigue en verde porque la forma vieja aún existe.
Contraer: borra la forma vieja una vez que no queda ninguna llamada, en un ticket bloqueado por cada lote de migración.

Donde ni los lotes pueden mantenerse en verde solos, comparten una rama de integración y todos bloquean un ticket final de integrar-y-verificar. El verde solo se promete allí.

Preguntas comunes

Produjo doce tickets para un cambio de tres líneas. La sobredescomposición es la fricción más reportada de esta habilidad, y es consistente entre practicantes: el modelo usa unidades atómicas por defecto y pierde la agrupación que las haría significativas. El paso de interrogatorio existe justo para esto: pídele que fusione, y lo hará. La respuesta más profunda es que los tickets tienen un suelo: si todo el cambio cabe en una ventana de contexto, no necesitas esta habilidad. Ve directo a implement.

Los tickets salieron uno por capa: todo el esquema en uno, toda la API en otro. Este es el fallo contra el que está escrita la regla del recorte vertical, y la habilidad aún lo produce a veces. Atrápalo en el paso de interrogatorio preguntando una cosa por ticket: ¿qué puedo demostrar cuando esto esté hecho? Un ticket sin respuesta es un recorte horizontal. Alguna gente añade una línea de “ruta de demostración” a cada ticket por esto, y cuenta que empuja al modelo hacia la descomposición vertical.

En GitHub los tickets no se crearon como sub-issues del issue de spec. Conocido y sin corregir. Se ha reportado en una docena de ejecuciones y varios modelos, con más detalle en el issue #554, y es peor en Codex que en Claude. gh lo soporta nativamente desde v2.94: gh issue create --parent <n>, y gh issue edit <parent> --add-sub-issue <n> después del hecho. Hasta que la plantilla del gestor prefiera eso, conectar tú mismo los enlaces padre tras una ejecución es el movimiento confiable.

“Blocked by” se escribió en el cuerpo del issue en lugar de un enlace real de bloqueo. La misma clase de problema, reportada en el issue #513, donde el agente llegó a afirmar que GitHub no tiene ninguna relación nativa de bloqueo. Sí la tiene: gh issue create --blocked-by 12,15. Como los bloqueadores se publican primero, sus números siempre están disponibles al crear. El texto del cuerpo está pensado como alternativa para gestores sin arista nativa, no como predeterminado.

¿A dónde van los tickets locales? Las notas de v1.1 decían un tickets.md en la raíz. Lo decían, y eso era un error: un solo archivo compartido también tenía carreras cuando agentes paralelos escribían en él. El modo local ahora escribe un archivo por ticket bajo .scratch/<feature-slug>/issues/<NN>-<slug>.md, en orden de dependencia, igualando el diseño que la plantilla del gestor local ya describía. El prefijo NN es un ID de ticket real, así que /implement 03 funciona en lugar de reescribir un título largo.

Siguió truncándose cuando intentaba leer mi spec. Una spec muy grande puede superar lo que un issue del gestor sirve limpio, y no hay copia local a la que recurrir, así que el agente quema llamadas de herramienta recuperando fragmentos y nunca llega al final. No hagas clear ni compact entre /to-spec y /to-tickets. Ejecútalos en la misma ventana de contexto y la spec nunca tiene que recuperarse.

Los criterios de aceptación no calificaban nada: algunos pasaban antes de hacer ningún trabajo. La plantilla pide criterios y no dice nada sobre si pueden fallar, así que esto ocurre. Tres formas se repiten: un criterio ya verdadero en el commit base, un criterio que solo puede satisfacerse con trabajo que posee otro ticket, y uno que reformula la petición en lugar de derivar del artefacto. El recorte vertical evita la mayor parte (un recorte que entrega comportamiento que antes no existía está en rojo en el commit base por construcción), pero vale la pena revisar a mano. Para cada criterio, nombra la observación que lo mostraría falso, y confirma que falla en el commit desde el que parte quien implementa.

Los tickets están publicados. ¿Cómo los ejecuto? La habilidad se detiene en el artefacto, y no hay modo de despacho automático. El despacho es manual: mira el tablero, cuenta los tickets sin bloqueadores abiertos, y abre esa cantidad de sesiones de agente. Un ticket por contexto nuevo, limpiado entre ellos. Ten en cuenta que implement no cierra ni marca el ticket de forma confiable cuando termina, ni en GitHub ni en Markdown local, así que el estado del ticket lo actualizas tú.

Funciona si

Cada ticket tiene respuesta a “¿qué puedo demostrar cuando esto esté hecho?”, y la respuesta es comportamiento, no una capa.
La lista vuelve a ti numerada, con una línea “Blocked by” en cada una, antes de que nada se publique.
El ticket de arriba no tiene bloqueadores y puede empezarse de inmediato.
Nada en el cuerpo de un ticket es una ruta de archivo o un número de línea, salvo un fragmento que produjo un prototipo.
Cada ticket se lee como algo que una sesión nueva podría terminar sin ti en la sala.
La prefactorización, donde encontró alguna, está al frente del orden en lugar de mezclada en tickets de funcionalidad.

Dónde encaja

to-tickets es un paso en la cadena principal de construcción:

grill-with-docs → to-spec → to-tickets → implement → code-review

Aguas arriba está to-spec, que le entrega una spec acordada contra la que cortar; mantén ambas en una ventana de contexto ininterrumpida. Aguas abajo está implement, que construye un ticket por sesión nueva, conduciendo tdd para las pruebas y cerrando con code-review. Cuando no sepas qué habilidad o flujo encaja, ask-matt te dirige.