| name | automation-loop-engine |
| description | Motor de Loop Engineering. Convierte trabajo repetitivo en sistemas: se diseñan UNA vez y se ejecutan N veces con verificación, compuertas humanas y aprendizaje acumulado (REGLAS.md). Tres funciones: (1) INSTALACIÓN — en el primer uso, entrevista de 5 preguntas para personalizar la skill al negocio, herramientas y límites de cada usuario; (2) RADAR — detectar cuándo una tarea se está convirtiendo en loop y preguntar «¿Lo diseñamos o lo disparo?»; (3) FÁBRICA — diseñar el loop (canvas de 9 campos), dispararlo, operarlo y evaluarlo. Usar siempre que el usuario diga "loop", "sistematiza esto", "automatiza este proceso", "línea de producción", "todas las semanas", "para cada cliente", "hazlo en lote", "diseña el sistema", "diseña el loop", "monta el sistema de", "deja de hacerlo a mano", "loop engineering", "convierte esto en un sistema", "configura la skill de loops", o pida repetir una tarea ya hecha 2+ veces en la conversación. Activar proactivamente (modo RADAR) a la 3ª repetición de una misma tarea con estructura similar, aunque el usuario no lo pida.
|
| author | Angel Aparicio (IA Masters Academy) |
| version | 1.0.0 |
| tags | ["loop-engineering","automatizacion","sistemas","operaciones","maker-checker","aprendizaje"] |
| tokens_estimate | 5000 |
Loop Engine — De promptear a diseñar loops
«El punto de apalancamiento se ha movido: ya no está en escribir el prompt perfecto,
está en diseñar el sistema que promptea por ti.»
— Síntesis de Steinberger / Cherny / Osmani (junio 2026).
Identidad
Esta skill convierte CUALQUIER tarea repetitiva (comercial, contenido, informes, soporte,
código, administración) en una línea de producción con seis estaciones:
COLA → DESPACHO → EJECUCIÓN → VERIFICACIÓN → COMPUERTA → REGISTRO
▲ │
└────────────── el aprendizaje vuelve a la cola ───────────┘
Definición operativa: un loop es un objetivo recursivo: se define el propósito y los
criterios de "hecho", y el sistema itera, con verificación y estado persistente, hasta
cumplirlos o hasta entregar el control al humano.
Principio rector, no negociable: Diseña el loop como quien piensa seguir siendo el
ingeniero, no como quien solo pulsa el botón. El loop amplifica el criterio del diseñador:
el bueno y el malo. El usuario no sale del sistema: sube de planta.
MODO INSTALACIÓN — primer uso y personalización
Al activarse esta skill, lo primero SIEMPRE es buscar context/loops-config.md.
- Si existe → leerlo, aplicar esos valores en todos los modos y no preguntar nada de configuración.
- Si NO existe → antes de diseñar o disparar nada, ofrecer la instalación:
Es la primera vez que usamos loop-engine juntos (o no veo tu configuración). Puedo hacerte
5 preguntas rápidas para adaptarla a tu negocio, tus herramientas y tus límites, o
empezar ya con valores genéricos y configurarla más adelante. ¿Qué prefieres?
Si acepta, hacer la entrevista de references/config-guide.md (las 5 preguntas, en una sola
tanda si es posible, máximo dos). Con las respuestas:
- Generar el bloque
# CONFIG · loop-engine relleno (plantilla en la referencia).
- Escribirlo en
context/loops-config.md.
- Añadir una línea en
context/working-memory.md, sección de hilos activos:
loop-engine configurado · ver context/loops-config.md.
- Si nombró un primer loop candidato, ofrecer diseñarlo o dispararlo en ese momento.
Si rechaza la entrevista → usar los defaults genéricos del MODO DISPARO y recordar,
solo una vez al final, que puede configurarla cuando quiera con "configura loop-engine".
Actualizar configuración: si el usuario pide "actualiza mi config de loops", regenerar
context/loops-config.md completo con los cambios y la fecha nueva. Nunca parchear líneas
sueltas ni guardar secretos.
Dónde viven los loops
Cada loop recurrente vive en loops/<nombre-kebab>/:
loop-spec.md — fuente de verdad operativa del loop.REGLAS.md — aprendizaje validado por correcciones del usuario.loop-state.md — estado de items procesados, pendiente y volátil.
Registro central:
loops/_index.md — tabla con nombre, objetivo, disparador, nivel A actual, fecha de creación
y última revisión. La skill lo crea en el primer uso real y lo actualiza al crear o evaluar loops.- Si el radar detecta candidatos y el usuario elige SEGUIR, anotarlos bajo la sección
## Candidatos detectados, con fecha y evidencia.
Plantillas:
loops/_templates/ — antes de diseñar de cero, mira si existe una plantilla parecida.
Incluye 5 plantillas iniciales: loop-contenido-semanal.md, loop-propuestas.md,
loop-triaje-leads.md, loop-informe-cliente.md y loop-revision-semanal.md.
El contenido de loops/ es privado del operador y no se versiona salvo README.md y _templates/.
Los 5 modos operativos
| Modo | Qué hace | Cuándo |
|---|
| RADAR | Detecta que una tarea se está volviendo loop y pregunta | Siempre activo en background, salvo configuración en contra |
| DISEÑO | Entrevista Loop Canvas (9 campos) → loop-spec.md | "Diseñemos el loop de X" |
| DISPARO | Rellena el canvas con la CONFIG (o defaults) → aprueba → construye | "Dispara el loop de X" |
| OPERACIÓN | Ejecuta un lote dentro de Claude o define dónde vive solo | "Corre el loop", "procesa la cola" |
| EVALUACIÓN | Scorecard de 5 métricas + decisiones de autonomía | "Evalúa el loop", revisión semanal |
MODO RADAR — detección proactiva
El radar corre en segundo plano en TODA conversación si la CONFIG dice proactivo. Si dice
bajo demanda, solo se activa cuando el usuario lo pide. Busca 6 señales:
| # | Señal | Qué observar |
|---|
| S1 | Repetición | El usuario pide por 3ª vez una tarea con la misma estructura |
| S2 | Pasos nombrables | El proceso se puede describir en 3–7 pasos con nombre |
| S3 | Entrada/salida estables | El input siempre tiene la misma forma y el output también |
| S4 | Calidad verificable | Existe o puede existir un checklist objetivo de "esto está bien" |
| S5 | Recurrencia futura | Lenguaje tipo "cada semana", "cada cliente", "siempre que llegue..." |
| S6 | Copy-paste entre herramientas | El usuario mueve a mano resultados entre chat, email, CRM, hojas o docs |
Puntuación: S1, S4 y S5 valen 2 puntos; S2, S3 y S6 valen 1 punto (máx. 9).
- Score ≥ 5 → interrumpir con la pregunta estándar.
- Score 3–4 → terminar la tarea actual y mencionar en una línea: "esto es candidato a loop, lo apunto en tu lista".
- Score < 3 → no decir nada.
Radar entre sesiones
Además de las 6 señales en la conversación, si el OS tiene Sinapsis activo:
- Consultar daily summaries recientes en
~/.claude/skills/_daily-summaries/.
- Leer
context/working-memory.md.
- Buscar tareas repetidas entre sesiones con misma estructura o misma cola.
Una repetición detectada ENTRE sesiones cuenta como señal S1 con 2 puntos.
Los candidatos descartados con SEGUIR se anotan en loops/_index.md, sección
## Candidatos detectados, con fecha, evidencia y score. Así el radar no parte de cero
la próxima vez.
Pregunta estándar del radar
Cuando el score ≥ 5, Claude interrumpe UNA sola vez por conversación con exactamente esta estructura:
🔁 Esto huele a loop. [Una frase con la evidencia: "Es la tercera vez que haces X con
la misma estructura: A → B → C."]
¿Cómo seguimos?
- DISEÑAR — Loop Canvas en 10 min: te hago las preguntas y lo dejamos especificado.
- DISPARAR — lo monto yo ahora con tu configuración (o defaults sensatos) y me apruebas la spec.
- SEGUIR — terminamos la tarea a mano y lo apuntamos para luego.
Reglas anti-ruido:
- Máximo UNA interrupción de radar por conversación. Si elige SEGUIR, no volver a preguntar
en esa conversación.
- Si el usuario dice "modo directo" o "sin radar", el radar queda mudo toda la conversación.
- El radar NUNCA interrumpe en mitad de una entrega urgente o una reunión en directo: espera
al final del turno de trabajo.
MODO DISEÑO — el Loop Canvas
Antes de construir nada: leer references/loop-canvas.md (plantilla completa de los 9 campos
- ejemplo rellenado universal) y
references/patrones.md si hay que elegir forma dominante.
Protocolo de entrevista:
- Pre-rellenar TODO lo deducible del contexto y de la CONFIG. Nunca llegar con el canvas vacío.
- Preguntar solo los huecos, en máximo 2 tandas de preguntas.
- Presentar el canvas completo para aprobación.
- Con el canvas aprobado, generar entregables en
loops/<nombre-kebab>/:
loop-spec.md — especificación operativa y fuente de verdad.REGLAS.md — inicializado vacío con secciones por estación.loop-state.md — estado volátil de items.- Actualizar
loops/_index.md.
- Ofrecer una versión visual en HTML del loop solo si el usuario la quiere o la CONFIG lo pide.
Los 9 campos del canvas:
- Objetivo y "hecho" — qué produce el loop y el criterio verificable de terminado.
- Disparador — manual por lote / programado / por evento. En Claude Code/Desktop los loops
programados se materializan como tarea programada de la app (Routines/Scheduled tasks) o con
/loop <intervalo> para polling dentro de una sesión. El loop-spec.md debe decir cuál.
- Cola de entrada — dónde viven los items pendientes y qué hace a un item "listo".
- Estaciones — los 3–7 pasos, en orden, con su input/output.
- Operario por estación — qué skill, agente, herramienta o persona ejecuta cada paso.
- Verificación automática — checklist objetivo que se pasa ANTES de molestar al humano.
- Compuertas humanas — dónde interviene el usuario y con qué nivel A0–A3.
- Condiciones de parada — presupuesto de iteraciones/tiempo, errores que escalan, kill switch.
- Métricas y aprendizaje — qué se mide y dónde se anotan las reglas aprendidas.
MODO DISPARO — construcción directa
Cuando el usuario elige DISPARAR o dice "dispara el loop de X", "móntalo directamente":
- Rellenar el Loop Canvas completo usando
context/loops-config.md y el contexto disponible.
- Presentar la spec compacta (los 9 campos en una tabla) y pedir una aprobación.
- Aprobado → generar los mismos entregables del modo DISEÑO.
- Si hay items reales disponibles, ofrecer correr un lote piloto de 3 items en modo A1
para calibrar antes de subir autonomía.
Defaults genéricos cuando un valor no esté en CONFIG ni contexto:
- Cola: la herramienta donde el usuario ya gestione pendientes, o una lista en el propio chat si es puntual.
- Estado persistente:
loops/<nombre-kebab>/loop-state.md, salvo que el usuario ya tenga hoja/base de datos.
- Verificación: checklist de 5 criterios máximo, binarios, sin ambigüedad.
- Compuerta inicial: A1 siempre. La autonomía se gana, no se regala.
- Parada: máx. 3 iteraciones de autocorrección por item; al 3er fallo, escala.
- Herramientas: solo las que el usuario ya usa o apruebe. Respetar siempre herramientas vetadas.
MODO OPERACIÓN — correr el loop
Dentro de Claude (lotes manuales o demo)
Protocolo de lote, item a item:
PARA CADA item de la cola:
1. TOMAR — leer el item y su contexto
2. EJECUTAR — correr las estaciones con sus operarios
3. VERIFICAR — pasar el checklist; si falla, autocorregir (máx. 3 intentos)
4. COMPUERTA — según nivel A: presentar para aprobación / ejecutar y registrar
5. REGISTRAR — estado del item (aceptado / corregido / escalado) + tiempo
6. APRENDER — si el usuario corrigió algo, convertir la corrección en regla
SIGUIENTE item, aplicando ya las reglas nuevas
Presentación durante el lote: una línea por item con su estado, no paredes de texto.
Al final del lote: mini-scorecard (items, aceptados a la primera, reglas aprendidas).
Loops que viven solos
El loop-spec.md debe indicar dónde vive cada pieza, usando el stack del usuario:
- Disparador programado → tarea programada de la app (Routines/Scheduled tasks),
/loop <intervalo>,
cron, automatización nativa de su herramienta, webhook, email o formulario.
- Cola → gestor de tareas, CRM, hoja de cálculo, bandeja etiquetada de email o base de datos.
- Operarios → skills de Claude, subagentes, plantillas, herramientas externas o pasos humanos.
- Maker/Checker → separar SIEMPRE quien produce de quien verifica. Para loops críticos en Claude
Code, ejecutar la VERIFICACIÓN en un subagente con instrucciones independientes de las del productor.
- Estado → fuera del contexto de conversación, siempre:
loop-state.md, hoja o base de datos.
El agente olvida entre sesiones; el registro no.
Niveles de autonomía A0–A3 (human-in-the-loop)
| Nivel | Quién hace qué | Cuándo usarlo |
|---|
| A0 | El usuario ejecuta, la IA asiste | Tarea nueva, criterio aún no explicitado |
| A1 | La IA propone, el usuario aprueba ANTES de que salga nada | Default de todo loop nuevo |
| A2 | La IA ejecuta, el usuario revisa DESPUÉS (cola de revisión asíncrona) | ≥10 items seguidos aceptados sin tocar en A1 |
| A3 | La IA ejecuta y registra; el usuario audita por muestreo (1 de cada 5–10) | ≥20 items en A2 con first-pass ≥90% y riesgo bajo |
Promoción: se propone subir de nivel cuando se cumplen los umbrales; la decisión es siempre del usuario.
Democión: 2 fallos graves seguidos, o 1 fallo que llegue a un cliente → bajar un nivel inmediatamente.
Compuertas SIEMPRE humanas (nunca A3), sin excepción:
- Todo lo que sale a un cliente o se publica con la marca del usuario.
- Dinero: precios, cobros, presupuestos, pagos.
- Acciones irreversibles: borrar datos, enviar emails masivos, desplegar a producción.
- Compromisos: fechas, alcance, contratos.
- Más las compuertas propias que el usuario haya definido en su CONFIG.
Aprendizaje — toda corrección se convierte en regla
Cada loop tiene un REGLAS.md. Formato:
R-007 · [fecha] · Origen: corrección del usuario en item #23
ANTES: tono formal por defecto en los textos.
AHORA: tono cercano, tuteo, máx. 1 emoji por pieza.
APLICA A: estación 2 (redacción).
Reglas del juego:
- Una corrección repetida 2 veces = regla obligatoria.
- Las reglas se inyectan en las instrucciones del operario de su estación.
- Revisión mensual: reglas contradictorias o muertas se podan.
- Si un loop acumula 15+ reglas en una estación, esa estación necesita rediseño, no más parches.
- Los
loop-spec.md y REGLAS.md quedan indexados por /recuerda: preguntas como
"¿qué reglas aprendimos del loop de propuestas?" deben responderse citando fuente.
Aprendizaje ↔ Sinapsis
Cuando un loop acumule 3+ reglas validadas en REGLAS.md, ofrecer al usuario consolidarlas
como aprendizaje del sistema vía /aprende, que escribe en context/learnings.md. Así
Sinapsis puede promoverlas a instintos.
NUNCA escribir directamente en archivos internos de Sinapsis como _instincts*.json.
MODO EVALUACIÓN — el scorecard
Se evalúa el loop, no cada output. Cinco métricas, revisión semanal de 15 minutos:
| Métrica | Qué mide | Lectura |
|---|
| First-Pass Yield | % de items aceptados sin tocar | <60% → revisar verificación · >90% sostenido → proponer subir nivel A |
| Tasa de retrabajo | % de items con ≥2 ciclos de corrección | Alta → el checklist no captura el criterio real |
| Tiempo de ciclo | De entrar en cola a aceptado | Si no baja vs. hacerlo a mano, el loop no se justifica todavía |
| Tasa de escalación | % de items que escalan al usuario por parada | >20% → la cola admite items que no están "listos" |
| Reglas/semana | Aprendizaje capturado | 0 durante semanas en un loop joven → nadie está anotando |
Decisiones posibles tras cada revisión:
- Subir o bajar autonomía.
- Ajustar checklist.
- Endurecer el criterio de "item listo".
- Partir una estación en dos.
- Matar el loop si no rinde. El canvas queda archivado.
Al evaluar, actualizar loops/_index.md con la última revisión y el nivel A actual.
Los 3 peajes (anti-patrones)
Leer en voz alta antes de cada loop nuevo:
- La verificación sigue siendo tuya. Un loop desatendido también comete errores
desatendidos. "Hecho" es una afirmación del agente, no una prueba.
- Deuda de comprensión. Cuanto mejor el loop, más rápido crece el hueco entre lo que
existe y lo que entiendes. Antídoto: auditoría por muestreo de A3 obligatoria.
- Rendición cognitiva. Dos personas con el mismo loop obtienen resultados opuestos:
una lo usa para ir más rápido en lo que domina; la otra para dejar de pensar.
Referencias de esta skill
references/config-guide.md — entrevista de instalación, plantilla CONFIG y persistencia OS-nativa. Leer SIEMPRE en modo INSTALACIÓN.references/loop-canvas.md — plantilla de los 9 campos + ejemplo rellenado universal. Leer SIEMPRE en modo DISEÑO/DISPARO.references/patrones.md — los 7 patrones de diseño de loops. Leer al elegir la forma del loop.references/demo-playbook.md — guion de la demo en directo "El mismo trabajo, dos veces". Leer cuando el usuario prepare una formación o demo.
