Review Loop

Ciclo iterativo de trabajo-revisión en una sola sesión. Tú haces el trabajo, generas un subagente revisor que lo critique, revisas según la retroalimentación y repites hasta alcanzar el umbral de calidad.

Principio fundamental: Los primeros borradores nunca son definitivos. La crítica iterativa produce mejores resultados que un único pase.

Nota sobre la plataforma: Este skill funciona mejor con agentes que permiten generar subagentes. En plataformas sin esa capacidad, simula el paso de revisión abriendo un nuevo contexto de chat, pegando solo el producto del trabajo (sin razonamiento previo) y pidiéndole que lo puntúe del 1 al 10 con retroalimentación específica.

Inicio rápido

Di: "implementa X, usa review-loop" o "ejecuta review-loop en el archivo que acabo de escribir"
El agente hace el trabajo (o lee el trabajo existente)
Un subagente crítico separado lo puntúa del 1 al 10 con retroalimentación específica
El agente revisa y repite hasta que la puntuación sea >= 8 (umbral de calidad por defecto)
Se entrega un resumen del ciclo con el resultado final

Cuándo usarlo

El usuario dice "usa review-loop", "pule esto", "itera sobre esto", "/review-loop"
Implementaciones complejas donde la calidad importa más que la velocidad
Documentos de diseño, especificaciones o redacción técnica
Código que necesita ser robusto (seguridad, pipelines de datos, lógica financiera)
Cuando el usuario quiere crítica adversarial integrada en el proceso

Cuándo NO usarlo

Arreglos simples, ediciones rápidas, cambios de una línea
Tareas donde las pruebas son el umbral de calidad (usa TDD + CI en su lugar)
Cuando el usuario solo quiere que se haga rápido
Trabajo exploratorio/de prueba donde el objetivo es aprender, no entregar
Tareas sin criterios de aceptación claros — defínelos primero, luego usa review-loop

Valores por defecto

Configuración	Por defecto
Mínimo de ciclos	2
Máximo de ciclos	4
Umbral de calidad	8/10
Modelo trabajador	(tu modelo actual)
Modelo revisor	(tu modelo actual o alternativa rápida/equilibrada)

Selección de modelos

La tarea del revisor evalúa lógica y restricciones. La tarea del trabajador escribe y modifica código. Elige las capacidades del subagente según corresponda.

REGLAS CRÍTICA: El revisor debe ser SIEMPRE IGUAL o MÁS POTENTE que el trabajador. Si el revisor es más débil, no podrá criticar adecuadamente la lógica compleja ni detectar regresiones sutiles.

Complejidad de la tarea	Capacidad del trabajador	Capacidad del revisor	Justificación
Simple/mecánica (CRUD, formateo, boilerplate)	Rápido / Ligero	Equilibrado	El trabajador ligero es rápido, el revisor equilibrado detecta problemas fácilmente
Estándar (funcionalidades, refactorizaciones, documentación)	Equilibrado	Equilibrado	Buena combinación de coste, velocidad y calidad
Compleja (varios archivos, integración, diseño)	Equilibrado	Avanzado / Razonamiento	El revisor avanzado detecta problemas arquitectónicos sutiles, el trabajador equilibrado puede implementarlos
Muy compleja (seguridad, finanzas cuantitativas, sistemas distribuidos)	Avanzado / Razonamiento	Avanzado / Razonamiento	Ambos necesitan contexto completo y capacidad de razonamiento. El revisor DEBE igualar la potencia del trabajador.

La regla de oro: El trabajador debe ser lo suficientemente inteligente para ACTUAR según la retroalimentación del revisor. Si el revisor dice "arregla la condición de carrera con un semáforo basado en canales" y el trabajador no puede razonar sobre concurrencia, el ciclo no convergerá.

Señal de escalada: Si la puntuación no mejora después de 2 ciclos consecutivos con la misma retroalimentación, el modelo del trabajador es demasiado débil. Escala:

Opción A: Pide al usuario que cambie a un modelo más capaz
Opción B: Reduce temporalmente el umbral de calidad y notifica la diferencia al usuario
Opción C: Divide la tarea en subtareas más pequeñas y ejecuta review-loop en cada una

Comportamiento por defecto: Dado que tú (el agente principal) ERES el trabajador, genera un subagente revisor que iguale o supere tu capacidad actual según la tarea:

La mayoría de tareas → Revisor Estándar/Equilibrado
Tareas especializadas/difíciles → Revisor Avanzado/Razonamiento
Comprobaciones rápidas → Revisor Rápido/Ligero (solo si tú también actúas como trabajador ligero)

Anulaciones del usuario

Los usuarios pueden anular cualquier valor por defecto en su solicitud. Analízalos de forma natural:

"implementa X con review-loop, umbral de calidad 9, usa modelo avanzado para revisión, máximo 5 ciclos"
"pule esto, mínimo 2 ciclos, umbral en 8"
"ejecuta review-loop con revisor rápido, máximo 2 ciclos"
"usa review-loop, revisor de razonamiento, umbral de calidad 9, mínimo 3 máximo 6"

Reglas de análisis:

"umbral de calidad N" o "umbral N" → quality_gate = N
"revisor [modelo]" o "revisa con [modelo]" → anulación del modelo revisor
"máximo N ciclos" → max_loops = N
"mínimo N ciclos" → min_loops = N
Si el usuario no especifica, usa los valores por defecto
Si el usuario dice "exhaustivo" o "estricto" → interpretar como quality_gate 8, min_loops 2
Si el usuario dice "rápido" o "rápido" → interpretar como max_loops 2, quality_gate 6

El proceso

flowchart TD
    A[Haz el trabajo] --> B[Genera subagente revisor]
    B --> C{¿Mínimo de ciclos cumplido?}
    C -- no, siempre continuar --> E[Revisa según retroalimentación]
    C -- sí --> D{¿Puntuación >= umbral de calidad?}
    D -- sí --> F[Pulido final]
    D -- no --> G{¿Máximo de ciclos alcanzado?}
    G -- sí, parar de todas formas --> F
    G -- no --> E
    E --> B
    F --> H([Hecho])

Paso a paso

Paso 1: Haz el trabajo

Completa la tarea como lo harías normalmente. Escribe el código, crea la especificación, implementa la funcionalidad. No te contengas: produce tu mejor primer intento.

Paso 2: Genera subagente revisor

Usa la herramienta Agente para despachar un revisor. El revisor debe:

Ser un subagente separado (contexto nuevo, sin anclaje a tu razonamiento)
Recibir solo el producto del trabajo (archivos, diferencias) — no tu proceso de pensamiento
Puntuar del 1 al 10 con retroalimentación específica y procesable
Usar un modelo equilibrado/estándar por defecto (o un modelo de razonamiento avanzado para tareas complejas/especializadas)

Plantilla del prompt del revisor:

Eres un revisor crítico. Puntúa el siguiente trabajo del 1 al 10 y proporciona retroalimentación específica y procesable.

## Qué se hizo
{breve descripción de la tarea}

## Criterios de revisión
{criterios específicos de la tarea — lo que importa para ESTA tarea}

Ejemplos de criterios bien redactados:
  Para un endpoint de API REST:
    - Códigos de estado HTTP correctos
    - Validación de entrada presente en todos los parámetros
    - Autenticación aplicada; sin acceso no autenticado
    - Sin patrones de consulta N+1

  Para un documento de diseño:
    - El enunciado del problema no es ambiguo
    - Alternativas consideradas con sus ventajas y desventajas
    - Sin ambigüedades sobre la complejidad de la implementación
    - Las métricas de éxito son medibles

  Para un pipeline de datos:
    - Idempotente — seguro de re-ejecutar
    - Los cambios de esquema se manejan correctamente
    - Modos de fallo documentados
    - Manejo de PII (información de identificación personal) abordado

## Instrucciones
1. Lee el trabajo con atención
2. Puntúa del 1 al 10 donde:
   - 1-3: Fundamentalmente roto o faltan requisitos importantes
   - 4-6: Funciona pero tiene problemas significativos
   - 7-8: Bueno, solo problemas menores
   - 9-10: Excelente, listo para enviar
3. Enumera problemas específicos con referencias archivo:línea cuando sea aplicable
4. Para cada problema, explica POR QUÉ importa y QUÉ arreglar
5. No seas cortés — sé honesto y directo
6. Indica tu puntuación claramente como "Puntuación: N/10"

## Archivos a revisar
{pega el contenido de los archivos o enumera las rutas de los archivos con extractos relevantes}

Paso 3: Analiza la retroalimentación

De la respuesta del revisor, extrae:

Puntuación (el número)
Problemas (categorizados como Críticos / Importantes / Menores)
Arreglos específicos (qué cambiar)

Informa al usuario:

Ciclo {N}/{máx}: Puntuación {X}/10
- {resumen de los puntos clave de retroalimentación}

Paso 4: Verifica condiciones de parada

En este orden:

Si ciclos completados < min_loops → continuar (siempre)
Si puntuación >= umbral de calidad → parar, ir a pulido final
Si ciclos completados >= max_loops → parar, ir a pulido final
En caso contrario → revisar y repetir el ciclo

Paso 5: Revisa

Aborda la retroalimentación del revisor. Arregla problemas Críticos e Importantes. Los problemas Menores son opcionales. Luego vuelve al Paso 2.

Importante: Cada revisión debe ser específica. No reescribas todo: arregla lo que el revisor señaló. Mantén una lista mental de TODA la retroalimentación anterior para evitar regresiones.

Paso 6: Pulido final

Una vez que el ciclo termina (umbral de calidad cumplido o se alcanzaron los ciclos máximos):

Aborda cualquier problema menor restante si es trivial
Verifica que el resultado final sea coherente (sin artefactos de los ciclos de revisión)
Informa al usuario de la puntuación final y el número de ciclos

Adaptación de los criterios del revisor según el tipo de tarea

Tipo de tarea	El revisor debe centrarse en
Código	Corrección, casos extremos, manejo de errores, legibilidad, sin problemas de seguridad
Especificación/Diseño	Completitud, viabilidad, sin ambigüedades, capacidad de implementación
Refactorización	Sin cambios de comportamiento, sin regresiones, más limpio que antes
Redacción	Claridad, estructura, apropiado para la audiencia, sin relleno
Corrección de errores	Causa raíz abordada, existe prueba de regresión, sin efectos secundarios
Infraestructura / IaC	Idempotencia, mínimo privilegio, sin secretos codificados, seguridad al eliminar
Migración de base de datos	Reversibilidad, estrategia de índices, riesgo de pérdida de datos, rendimiento a escala
Diseño de API	Compatibilidad hacia atrás, autenticación, versionado, contrato de errores
Suite de pruebas	Cobertura de casos extremos, sin interdependencia de pruebas, aserciones significativas

Dos modos de operación

Modo A: "Hacer y revisar" (ciclo completo)

El usuario da una tarea + dice que use review-loop. Tú haces el trabajo Y ejecutas el ciclo de revisión.

Usuario: "Implementa la capa de caché. Usa review-loop, umbral de calidad 8."

Tú:
1. Implementas la capa de caché
2. Generas revisor → Puntuación 6, retroalimentación: falta desalojo, no hay TTL
3. Revisas: añades desalojo + TTL
4. Generas revisor → Puntuación 8, retroalimentación: problema menor de nombres
5. Pulido final, hecho

Modo B: "Revisar existente" (solo revisión)

El usuario ya hizo el trabajo o tú ya lo hiciste. Solo ejecuta el ciclo de revisión sobre lo que existe.

Usuario: "Ejecuta review-loop en el módulo de autenticación que acabo de escribir"

Tú:
1. Lees el módulo de autenticación
2. Generas revisor → Puntuación 5, retroalimentación: inyección SQL, sin limitación de velocidad
3. Arreglas: parametrizas consultas, añades limitador de velocidad
4. Generas revisor → Puntuación 8, aprobado
5. Hecho

Señales de alarma

Nunca:

Auto-revisarse en lugar de generar un subagente (sesgo de anclaje)
Saltarse un ciclo de revisión porque "la retroalimentación es incorrecta" sin justificación
Inflar tu propia puntuación ("Creo que esto es en realidad un 9")
Continuar más allá de max_loops sin el consentimiento del usuario
Generar el revisor con todo tu razonamiento/historial (debe revisar el TRABAJO, no tu intención)

Si el revisor se equivoca:

Contraargumenta con evidencia (muestra código/pruebas que refuten la retroalimentación)
Omite ese punto específico en la revisión
Anótalo en tu informe al usuario
No reduzcas el estándar de calidad para compensar

Formato de informe de ejemplo

--- Review Loop: {nombre de la tarea} ---

Ciclo 1/4: Puntuación 6/10
  Revisor: Falta validación de entrada, no hay manejo de errores para tiempo de espera de red,
            función demasiado larga (80 líneas).
  Acción: Arreglando los tres problemas.

Ciclo 2/4: Puntuación 8/10
  Revisor: Limpio. Menor: el nombre de variable `d` podría ser más descriptivo.
  Acción: Umbral de calidad cumplido (8 >= 8). Pulido final.

Resultado: 8/10 en 2 ciclos. Hecho.

Limitaciones conocidas

El subagente revisor no tiene memoria de ciclos anteriores: incluye explícitamente el contexto de retroalimentación anterior en cada prompt del revisor para evitar repetir problemas ya resueltos
Es posible la inflación de puntuación si los criterios del prompt del revisor son demasiado vagos: invierte tiempo en redactar criterios específicos y medibles
Este skill no reemplaza la revisión de código humana para código crítico para la seguridad o sensible al cumplimiento normativo; trata el resultado como un primer filtro sólido
No se garantiza la convergencia del ciclo si la tarea está insuficientemente especificada: define criterios de aceptación claros antes de empezar

Coste y velocidad

Cada ciclo = 1 llamada al subagente revisor
Presupuesta aproximadamente 1-2 veces el tiempo de un único pase de implementación para un ciclo completo de 3 iteraciones
Esto es barato en comparación con enviar código con errores, especificaciones vagas o desencadenar un ciclo de revisión tardío
Usa tu modelo estándar/por defecto para la mayoría de las revisiones; solo actualiza a modelos de razonamiento avanzados para dominios especializados (auditorías de seguridad, sistemas distribuidos, finanzas cuantitativas)

Licencia

MIT — libre de usar, adaptar y redistribuir con cualquier herramienta o plataforma de IA. Se agradece la atribución. Las contribuciones son bienvenidas.

review-loop

¿Qué es review-loop?

Preguntar en tu IA favorita

Documentación