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)

1. 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.

1. Plan — speckit-plan → speckit-tasks → speckit-analyze. Para correcciones

pequeñas, un plan ligero basta, pero deja el alcance explícito.

1. 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).

1. 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".

1. 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.md es 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).