kevinrivm Loop SDD — ejecutar objetivos, no prompts
El dueño da objetivos; tú corres el loop completo y vuelves solo al terminar o al
bloquearte de verdad. Es la implementación de Goal→Work→Check→Repeat (no Ask→Answer→Stop)
sobre el flujo Spec Kit de este repo. El contrato canónico vive en CLAUDE.md → "Modo
Objetivo — Loop SDD" y "Definición de Hecho REFORZADA"; este skill es el punto de entrada.
Entrada
El argumento es el objetivo (qué debe lograrse / cómo debe comportarse el producto). Si no se pasó argumento, toma el último objetivo que el dueño describió en la conversación.
El loop (no saltes Verify)
Discover — Lee el estado real antes de actuar: spec/plan/tasks de la feature activa, código relevante, memoria (
MEMORY.md+ archivos), y logs si hay un bug. Decide si el objetivo necesita una spec nueva (speckit-specify+speckit-clarify) o si es una corrección/extensión sobre una feature existente.- Agrupa TODAS las preguntas bloqueantes y hazlas UNA sola vez aquí. Si puedes resolver algo con defaults sensatos o leyendo el código, hazlo; no preguntes.
Plan —
speckit-plan→speckit-tasks→speckit-analyze. Para correcciones pequeñas, un plan ligero basta, pero deja el alcance explícito.Execute —
speckit-implement(o la edición directa para fixes acotados). Respeta el stack y la constitución del proyecto (tipos estrictos, multi-tenant si aplica, idempotencia, secretos cifrados).Verify (OBLIGATORIO — lo hace el agente, no el dueño) —
- Gate técnico: typecheck + lint + build (los comandos reales del proyecto).
- Self-test de comportamiento E2E: despliega (o corre local) y ejerce el flujo real como usuario, con la herramienta adecuada (navegador, API, línea de prueba del canal). Conduce el flujo completo de punta a punta, no una llamada aislada.
- Camino infeliz: provoca lo que el sistema/proveedor exponen (input inválido, respuesta vacía/no-formato, fuera de ventana, fallo del proveedor) y comprueba que degrada sin colgarse.
- Confirma el resultado observable con evidencia (transcripción/captura/log), no solo un 2xx del endpoint ni "compila".
Iterate — Si algo falla, diagnostica (logs del deploy, la salida cruda del proveedor/LLM), corrige y re-verifica tú. Cada fix vuelve al loop, no a la bandeja del dueño. Sin spin: si un deploy tarda, avanza en otra cosa o espera con criterio.
Sostén del loop
- State:
tasks.mdes tu estado durable — mantenlo al día; te permite reanudar si se corta el contexto. - Memory: persiste decisiones, gotchas y correcciones (no repitas errores aprendidos).
- Cost: agrupa verificaciones, no quemes créditos ni dispares deploys de más.
Condición de paro — cuándo (y solo cuándo) volver al dueño
- ✅ Objetivo cumplido: criterios de aceptación verdes en vivo, verificados por ti, con evidencia. Reporta qué se logró y la evidencia.
- ⛔ Bloqueo real (única razón para interrumpir a mitad): decisión de producto ambigua
que cambia el resultado · falta de credenciales/acceso · acción irreversible o hacia
afuera que exige OK del dueño (merge a
main, borrado destructivo, comunicación externa, gastar dinero/créditos) · techo de costo/tiempo acordado. Trae contexto + opciones + tu recomendación.
Nunca
- Declarar "listo" sin haber ejercido el comportamiento tú mismo.
- Delegar la prueba funcional al dueño ("despliego para que TÚ pruebes").
- Pedir permiso por cada paso reversible (rompe el loop).