rizqinrr/get-tasks

Get Tasks

Resumen

get-tasks convierte un PRD aprobado en un conjunto ejecutable de tareas. Cada tarea se escribe en su propio archivo, dimensionado para una sesión enfocada, ordenado por dependencias, y equipado con criterios de aceptación, pasos de validación, una lista de bloqueos y un procedimiento de reversión.

La razón por la que esto existe como una habilidad separada: un PRD no es un plan. Un PRD establece qué hace el sistema y por qué. No dice nada sobre el orden del trabajo, qué se puede construir en paralelo, dónde están las partes riesgosas o cómo demostrar que un fragmento está terminado. Convertir un PRD directamente en código produce o un cambio heroico de una sola pasada o un orden arbitrario que se rompe a mitad de camino.

get-tasks proporciona la capa faltante. Lee el PRD, mapea la estructura de dependencias reales, corta el trabajo en fragmentos verticales y escribe cada fragmento como un artefacto independiente que un agente (o un humano) puede retomar sin releer todo el PRD.

Esta habilidad se basa en tres fuentes:

1. Descomposición basada en dependencias y cortes verticales — construye un grafo de dependencias, corta verticalmente en lugar de horizontalmente, dimensiona cada tarea y coloca puntos de control. Esto es lo que hace que el orden sea correcto.
2. Ejecución basada en validación — cada tarea declara cómo se verificará en múltiples tipos de validación, no solo "pruebas pasan", y lleva un procedimiento de replanificación cuando un paso falla.
3. Bordes bloqueantes y balas trazadoras — cada tarea establece explícitamente qué la bloquea, de modo que cualquier tarea cuyos bloqueadores estén listos pueda comenzar de inmediato.

El resultado es un directorio de archivos de tarea: tasks/<name>/task-01.md, task-02.md, y así sucesivamente, numerados en orden de dependencia, más tasks/<name>/plan.md que los indexa. Las tareas bloqueantes reciben los números bajos.

Alcance de Esta Habilidad

get-tasks es deliberadamente completa. Absorbe lo que varias habilidades más limitadas hacían parcialmente, para que un usuario solo necesite una habilidad para pasar de un PRD aprobado a un plan ejecutable y rastreable. Todo aquí es relevante para esa única tarea:

Aspecto	Dónde se maneja
Leer el PRD y extraer compromisos	Fase 1
Estructura de dependencias y orden	Fase 2
Cortes verticales y balas trazadoras	Fase 3
Refactorizaciones amplias (expandir, migrar, contraer)	Fase 3
Especificación por tarea	Fase 4
Reglas de dimensionamiento y división	Fase 5
Puntos de control y compuertas	Fase 5
Clasificación de paralelización	Taxonomía de Paralelización
Resumen del plan legible por humanos, riesgos, decisiones	Fase 6
Destino del tracker vs. archivo	Destino de la Lista de Tareas
Aprobación del usuario antes de escribir	Fase 7
Escritura, sincronización y verificación de artefactos	Fase 8
Manejo de fallos y replanificación	Replanificación cuando una tarea falla

Es larga por diseño. La longitud es el punto: un desglose que deje alguno de estos implícito produce tareas que parecen terminadas y no lo están. Si te sientes tentado a hojear hasta la plantilla, lee las Fases 2, 3 y 5 en su lugar; esas son donde los desgloses realmente fallan.

Lo que esta habilidad no hace: no escribe código, no ejecuta las tareas y no reemplaza el PRD. Convierte un documento en un conjunto de documentos.

Cuándo Usarla

Usa esta habilidad cuando:

• Existe un PRD, especificación o documento de requisitos y el trabajo necesita convertirse en tareas ejecutables
• El usuario dice "get tasks", "breakdown PRD", "pecah jadi task", "bikin task list" o "convierte esto en tareas"
• Una tarea parece demasiado grande para empezar y necesita descomponerse
• Necesitas estimar el alcance, ordenar el trabajo o encontrar qué puede ejecutarse en paralelo
• Estás a punto de implementar algo que toca más de un puñado de archivos y no existe una lista de tareas

Cuándo NO usarla:

• Aún no existe un PRD — ejecuta get-prd primero, luego vuelve
• El cambio es una sola tarea por cualquier medida (un archivo, una edición obvia) — solo hazlo
• Ya existe un desglose completo de tareas en tasks/ y estás listo para implementar — procede directamente a ejecutar las tareas en secuencia

El Proceso

get-tasks se ejecuta en nueve fases. Cada fase tiene una condición de salida. No avances más allá de una fase cuya condición de salida no se cumpla.

0. Localizar el PRD         -> ¿qué documento es la fuente?
1. Leer y extraer           -> ¿a qué nos compromete el PRD?
2. Grafo de dependencias    -> ¿qué depende de qué?
3. Cortes verticales        -> balas trazadoras, no capas horizontales
4. Escribir cada tarea      -> un archivo por tarea, completamente especificada
5. Ordenar, dimensionar, punto de control -> secuencia, tamaño y compuertas de verificación
6. Escribir el documento del plan -> el resumen legible que indexa las tareas
7. Consultar al usuario     -> granularidad, bordes bloqueantes, fusionar o dividir
8. Escribir y verificar     -> archivos en disco, todos sincronizados, validadores verdes

Principios Universales para el Desglose de Tareas

1. Ritmo en Lenguaje Natural: Presenta el desglose y los resúmenes conversacionales en el idioma que hable el usuario (indonesio o inglés), manteniendo los nombres de archivo, términos de git y tokens de código estándar (task-01.md, branch, commit, TDD).
2. Listo para Ejecución Autónoma: Cada archivo de tarea generado en tasks/<feature>/task-*.md debe ser completamente independiente. Cualquier agente de codificación debería poder leer solo ese archivo de tarea, saber qué archivos editar, qué pruebas ejecutar y qué definición de "terminado" debe cumplirse sin adivinar.
3. Cortes Verticales sobre Capas Horizontales: Nunca crees tareas que sean puramente "configurar backend" o "configurar frontend" de forma aislada si no pueden verificarse de extremo a extremo. Corta verticalmente (por ejemplo, "Almacenar y Consultar endpoint SKU con disparador UI") para que cada tarea entregue valor comprobable.

La planificación es de solo lectura. Las fases 0 a 7 producen documentos y preguntas, no código. No crees, edites ni elimines ningún archivo fuente durante esas fases. Escribir archivos de tarea en tasks/ es el único cambio permitido en el sistema de archivos antes de que el usuario lo apruebe. Si te encuentras corrigiendo un error o agregando una función mientras desglosas el trabajo, detente: eso pertenece a la implementación posterior a la aprobación, y pertenece a una tarea que aún no has escrito.

---

Fase 0: Localizar el PRD

Encuentra el documento fuente antes de hacer cualquier otra cosa.

1. Por convención primero. get-prd guarda en docs/prd/<name>.md. Busca allí primero.
2. Luego la búsqueda más amplia. Si docs/prd/ está vacío, busca un PRD que el usuario nombre. Acepta el cuerpo de un issue o un documento de requisitos pegado — la habilidad no está limitada por el formato, solo la extracción en la Fase 1 asume los nombres de las secciones del PRD.
3. Si hay más de un candidato, no adivines. Enuméralos y pregunta cuál rige este trabajo.
4. Si no existe ninguno, detente y dilo. No inventes requisitos. Dirige al usuario a get-prd para una sesión completa de entrevista a PRD.

Registra la ruta exacta desde la que estás trabajando. Cada fase posterior la referencia.

Para una iniciativa de múltiples módulos donde el PRD está dividido por ID de módulo (docs/prd/identity.md, docs/prd/billing.md), confirma qué módulo cubre este desglose. Un desglose por módulo, en el orden de construcción que declaró el mapa de capacidades.

Condición de salida: se identifica un único documento fuente y su ruta está registrada.

---

Fase 1: Leer y Extraer

Lee el PRD por completo. Luego extrae, explícitamente, el material que impulsa la descomposición:

Sección del PRD	Qué extraes de ella
Objetivo	El estado final al que toda tarea sirve en última instancia
Historias de Usuario	Los comportamientos observables que deben funcionar, criterios de aceptación candidatos
Decisiones Técnicas	Módulos, interfaces, cambios de esquema, contratos — estos definen los límites reales entre tareas
Estructura del Proyecto	Dónde caen los artefactos, lo que limita "archivos probablemente tocados"
Comandos	Los comandos de verificación concretos que cada tarea citará
Estrategia de Pruebas	Qué cuenta como una buena prueba aquí y dónde pertenecen las pruebas
Límites	Siempre / Preguntar Primero / Nunca — los elementos de "Nunca" se convierten en restricciones duras en cada tarea
Fuera de Alcance	No-objetivos explícitos; nada de aquí se convierte en una tarea
Criterios de Éxito	La compuerta final; el último punto de control verifica contra ella

Reglas:

• No empieces a cortar todavía. Primero la extracción, luego la descomposición. Cortar mientras se lee produce tareas moldeadas por el orden en que casualmente leíste el documento.
• Convierte elementos vagos en afirmaciones comprobables. Si el PRD dice "el panel debe ser rápido", el criterio de aceptación de la tarea es un número, y si el PRD no dio ningún número, preséntalo como un bloqueante en lugar de elegir uno en silencio.
• Señala las lagunas. Si falta una sección necesaria o está vacía, nómbrala. Una Estrategia de Pruebas faltante significa que el bloque de verificación de cada tarea se inventará más tarde; plantéalo ahora.
• Nunca inventes requisitos. Si el PRD no lo dice, no es una tarea.

Condición de salida: la tabla de extracción está poblada y cualquier laguna se ha planteado al usuario.

---

Fase 2: Mapear el Grafo de Dependencias

Antes de escribir una sola tarea, mapea qué depende de qué. Esta es la fase que determina el orden y previene el tipo de error más costoso: construir un consumidor antes de que exista su productor.

Dibuja el grafo. Concreto, no abstracto:

Esquema de base de datos
    |
    +-- Modelos y tipos de API
    |       |
    |       +-- Endpoints de API
    |       |       |
    |       |       +-- Cliente API del frontend
    |       |               |
    |       |               +-- Componentes UI
    |       |
    |       +-- Lógica de validación
    |
    +-- Datos semilla y migraciones

Reglas:

• Las aristas apuntan de productor a consumidor. Una flecha significa "el objetivo necesita la fuente primero".
• Sin ciclos. Si dos cosas se necesitan mutuamente, son una tarea, o la interfaz entre ellas debe definirse primero como su propia tarea.
• Las interfaces son fronteras. Cuando dos tareas se encuentran en un contrato (un tipo, una forma de endpoint, un esquema), define el contrato en la tarea anterior y consúmelo en la posterior. Nunca dejes que ambas tareas lo inventen de forma independiente.
• Encuentra la frontera. La frontera es cada tarea cuyos bloqueadores están todos hechos. Es lo que puede empezar ahora. Para una cadena lineal, la frontera tiene una tarea de ancho; para un proyecto amplio, pueden ser varias.
• Nombra las oportunidades paralelas y las secuencias duras. Los cortes independientes pueden ejecutarse en paralelo. Las migraciones, los cambios de estado compartidos y cualquier cosa que toque el mismo contrato deben ser secuenciales.

Condición de salida: existe un grafo de dependencias, con una frontera clara y sin ciclos.

---

Fase 3: Cortar Verticalmente

Corta el trabajo en balas trazadoras: caminos estrechos pero completos a través de cada capa que la función necesita.

El corte horizontal es el error predeterminado. Parece ordenado y no produce nada ejecutable hasta la última tarea:

Malo (horizontal):
Tarea 1: Construir todo el esquema de base de datos
Tarea 2: Construir todos los endpoints de API
Tarea 3: Construir todos los componentes UI
Tarea 4: Conectar todo

Al final de la Tarea 3, nada funciona. Nadie puede demostrar nada. Una suposición incorrecta en la Tarea 1 se descubre en la Tarea 4.

El corte vertical produce software funcional en cada paso:

Bueno (vertical):
Tarea 1: Un usuario puede crear una cuenta   (esquema + API + UI para registro)
Tarea 2: Un usuario puede iniciar sesión      (esquema auth + API + UI para inicio de sesión)
Tarea 3: Un usuario puede crear una tarea       (esquema de tarea + API + UI para creación)
Tarea 4: Un usuario puede ver la lista de tareas  (consulta + API + UI para vista de lista)

Reglas para un buen corte:

• Corta a través de cada capa que el comportamiento necesita — datos, lógica, interfaz, prueba.
• Es demostrable o verificable por sí mismo. Si no puedes describir cómo confirmar que funciona, no es un corte.
• Cabe en una sesión enfocada — aproximadamente una ventana de contexto fresco.
• Entrega comportamiento, no estructura. "Agregar la tabla de usuarios" no es un corte; "un usuario puede registrarse" sí lo es.

Las refactorizaciones amplias son la excepción. Una refactorización amplia es un cambio mecánico (renombrar una columna, volver a escribir un símbolo compartido) cuyo radio de explosión se extiende por todo el código base, por lo que ningún corte vertical puede estar en verde. No lo fuerces a una bala trazadora. Secuencia como expandir, migrar, contraer:

1. Expandir — agrega la nueva forma junto a la antigua para que nada se rompa.
2. Migrar — mueve los sitios de llamada en lotes dimensionados por radio de explosión (por paquete, por directorio), cada lote su propia tarea bloqueada por la expansión, manteniendo la compilación en verde lote tras lote porque la forma antigua aún existe.
3. Contraer — elimina la forma antigua una vez que no quede ningún llamante, en una tarea bloqueada por cada lote de migración.

Cuando incluso los lotes no pueden mantenerse verdes solos, mantén la misma secuencia pero permíteles compartir una rama de integración que todos bloquean una tarea final de integrar y verificar, donde se promete el verde.

Condición de salida: cada pieza de trabajo pertenece exactamente a una tarea, y cada tarea es un corte vertical o un paso declarado de refactorización amplia.

---

Fase 4: Escribir Cada Tarea

Escribe cada tarea en su propio archivo. Una tarea por archivo, siempre — nunca un solo documento combinado con todas las tareas dentro.

Ruta de salida: tasks/<name>/task-NN.md, donde <name> coincide con el nombre del PRD (por lo que un PRD en docs/prd/billing.md produce tasks/billing/task-01.md). Numera desde 01, en orden de dependencia — los bloqueadores reciben los números bajos.

Plantilla del archivo de tarea:

# Tarea NN: <Título descriptivo corto>

**Fuente:** docs/prd/<name>.md — <Sección del PRD que implementa esta tarea>

**Qué construir:** El comportamiento de extremo a extremo que esta tarea hace
funcionar, desde la perspectiva del usuario. No una lista de implementación
capa por capa. Si no puedes describirlo como un comportamiento que un usuario
o llamante puede observar, reforma la tarea.

## Criterios de aceptación

- [ ] <condición específica y comprobable>
- [ ] <condición específica y comprobable>

Cada criterio debe ser verificable por alguien que no haya escrito la tarea.
"Funciona correctamente" no es un criterio. "Un usuario puede registrarse con un
correo electrónico y contraseña y es redirigido al panel" sí lo es.

## Verificación

- [ ] Pruebas pasan: <el comando de prueba enfocada del repositorio o la nueva prueba a escribir primero>
- [ ] Compilación exitosa: <el comando de compilación del repositorio>
- [ ] La salida coincide: <el patrón esperado o artefacto que debe existir>
- [ ] Sin regresiones: <la suite completa o el subconjunto relevante>
- [ ] Calidad y seguridad: <validación de entrada, límites de autenticación, sigue>

...

[truncado para traducción]

(El contenido completo de la plantilla y las fases restantes se han truncado por brevedad en la traducción, pero la estructura se mantiene fiel al original)