g-ki/agent-skills

Desglose de Tareas

Convierte un diseño en un backlog de incidencias de 1 punto de historia que cualquier ingeniero del equipo pueda tomar, finalizar y fusionar por sí mismo.

Entrada

$ARGUMENTS

• Si se proporciona una ruta, lee ese documento.
• De lo contrario, usa el RFC más reciente o un archivo *.notes.md de una sesión de pensamiento productivo en esta conversación o en el disco. Estos suelen ser archivos locales no rastreados (búscalos en carpetas ignoradas por git como .rfcs/, luego docs/rfcs/, docs/adr/, rfcs/). Si no encuentras ninguno, pregunta qué documento o diseño se debe desglosar.
• Si la fuente tiene vacíos que impiden el corte (sin diseño elegido, sin enfoque de implementación), enuméralos y pregunta antes de inventar respuestas. Los vacíos pequeños pueden convertirse en incidencias de tipo spike.

Qué significa "1 punto de historia" aquí

Una incidencia es de 1 punto cuando todas estas condiciones se cumplen. Si alguna falla, divídela:

1. Una persona, aproximadamente un día o menos, incluyendo pruebas y correcciones de revisión.
2. Un PR revisable con un solo propósito. Un revisor puede entenderlo sin leer otros PR abiertos.
3. Fusionable por sí mismo. La rama principal sigue estable y publicable después de que se integre, lo que generalmente significa que el nuevo comportamiento está detrás de un flag o no está conectado aún.
4. Comprobable. Tiene de 1 a 5 criterios de aceptación que alguien que no sea el autor pueda verificar.
5. Sin incógnitas ocultas. Si el implementador tuviera que investigar antes de saber qué hacer, es un spike, no una historia.

Si el equipo tiene su propia definición de punto, sigue la suya e indícalo al principio de la salida.

Cómo cortar

Lee el código antes de cortar: confirma que los archivos, módulos, esquemas y pruebas que toca cada incidencia realmente existen, y nómbralos en la incidencia. Las incidencias que citan rutas reales se toman; las vagas se quedan en el backlog.

Comienza con un walking skeleton: la rebanada más delgada de extremo a extremo que demuestre que el diseño funciona en producción (a menudo detrás de un flag), luego engrósala. Esto adelanta el riesgo en lugar de descubrir problemas de integración en la última incidencia.

Cuando una incidencia es demasiado grande, estas divisiones suelen funcionar:

• Preparar, luego cambiar. Primero extrae una refactorización pura ("haz el cambio fácil, luego haz el cambio fácil"), con pruebas que fijen el comportamiento actual antes de la refactorización.
• Expandir / migrar / contraer para cambios de esquema y API: agrega la nueva columna o endpoint, realiza el relleno inicial o doble escritura, cambia las lecturas, luego elimina la ruta anterior. Cada fase es su propia incidencia.
• Por capa detrás de un flag: modelo de datos → lógica de servicio → API → UI, cada una fusionable porque el flag está desactivado.
• Ruta de lectura antes que ruta de escritura, y ruta feliz antes que casos extremos y manejo de errores.
• Por variante: una incidencia por proveedor, tipo de archivo o cliente, después de que la primera establezca el patrón.
• Spikes para incógnitas: con límite de tiempo (≤ 1 día), y el resultado es una decisión más incidencias de seguimiento, no código de producción. Dale a cada spike una Pregunta: que tenga respuesta, y un límite de tiempo. Las incidencias que dependen de la decisión se cortan solo hasta donde sea seguro, con una nota de que se refinarán una vez que el spike esté decidido. Pon los spikes temprano: bloquean todo lo que está detrás.

No olvides el trabajo que no es código de funcionalidad: configuración y eliminación de flags de funcionalidad, métricas/alertas/dashboards, actualizaciones de runbook o documentación, rellenos de datos, pasos de implementación gradual y limpieza de la ruta anterior. Estos son generalmente donde los proyectos "casi terminados" se estancan.

No dividas por dividir: una incidencia que solo tiene sentido fusionada junto con otra debería ser una sola incidencia, o el par debería cortarse nuevamente por una costura diferente.

Salida

1. Escribe el backlog usando templates/tasks.md en <rfc-name>.tasks.md junto al RFC fuente. Al igual que el RFC, es un archivo de trabajo local, no rastreado por defecto; si su carpeta no está en git-ignore, agrégalo a .git/info/exclude. Numera las incidencias T-01, T-02, … para que las dependencias puedan referenciarlas, establece cada estado como open, y completa el slug del proyecto usado para los nombres de rama. Mantén los nombres de los campos exactamente como en la plantilla, ya que /implement-task y /deliver-project los leen.
2. Agrupa las incidencias en hitos que coincidan con las fases del RFC, cada uno terminando en algo demostrable o publicable.
3. Incluye el panorama de dependencias: qué incidencias pueden ejecutarse en paralelo y la ruta crítica. Un gráfico pequeño de Mermaid funciona bien cuando hay más de ~8 incidencias.
4. En el chat, da un resumen breve: recuento de incidencias por hito, cuántas pueden comenzar de inmediato, la ruta crítica, los spikes y cualquier incidencia de la que no estés seguro de que sea realmente de 1 punto. Pide al usuario que marque las incidencias que parezcan demasiado grandes, demasiado pequeñas o mal ordenadas, y revisa.
5. Publica en el sistema de seguimiento del equipo. Asume que el equipo usa uno (Linear, Jira, GitHub Issues, …). Una vez que el usuario esté satisfecho con el desglose, ofrece publicarlo a través del sistema de seguimiento conectado; si no hay ninguno conectado, indica qué conector ayudaría y ofrece un CSV con las columnas ID, Título, Descripción, Criterios de Aceptación, Puntos de Historia, Hito, Depende De, Etiquetas como alternativa. Publica solo después de que el usuario confirme, ya que es visible para todo el equipo. Para cada incidencia, crea un issue con el título, una descripción independiente (contexto, alcance, archivos, fuera de alcance, criterios de aceptación), estimación 1, el hito y relaciones de bloqueado-por para sus dependencias donde el sistema lo soporte. Luego escribe la clave y el enlace de cada issue en el campo Tracker: del archivo local.
6. Señala el siguiente paso: /implement-task <id-de-incidencia> para una sola incidencia, /spike-task <id-de-incidencia> para un spike, o /deliver-project <archivo-de-tareas> para ejecutar todo el backlog con un equipo de agentes.

Si el RFC fuente tiene una sección de plan de ejecución, actualízala para enlazar al archivo de tareas en lugar de duplicar la lista.

Refinamiento después de un spike

Cuando se recibe el registro de decisión de un spike decidido (estado decided), actualiza el backlog en lugar de empezar de nuevo:

1. Aplica los cambios aprobados del backlog del registro: agrega incidencias (continúa la numeración T-NN, nunca reutilices IDs), cambia el alcance, los criterios o las dependencias de las incidencias afectadas, y marca las incidencias eliminadas como canceled con el motivo, en lugar de eliminarlas.
2. Vuelve a verificar cada incidencia cambiada o nueva con la prueba de 1 punto, y actualiza el resumen, el gráfico de dependencias y la ruta crítica.
3. Actualiza las secciones del RFC que enumera el registro.
4. Sincroniza el sistema de seguimiento: crea los nuevos issues, actualiza los modificados y cancela los eliminados, escribiendo las nuevas claves en el archivo de tareas. Si el usuario aprobó la decisión y sus cambios en el backlog juntos, esa aprobación cubre esta sincronización; de lo contrario, confirma primero.
5. Establece el spike como done y resume qué cambió en unas pocas líneas.