Revisa un cambio de código con otro modelo en hasta 3 rondas: un revisor lee el cambio y un rompedor intenta romperlo con pruebas. Mantén cada corrección lo más pequeña posible para resolver su hallazgo y responde con evidencia cuando un hallazgo sea incorrecto.
1. Instruir al revisor y al rompedor
El revisor y el rompedor son el modelo más nuevo, en orchestrator_capabilities, de la familia que el usuario nombró (sol, opus, …), con el esfuerzo que nombró; no configures ninguna otra opción de modelo. Un proveedor solo (gpt, claude) no nombra una familia. Si falta la familia o el esfuerzo, pregúntalo y no hagas nada más hasta que respondan.
Fija la base: la que pase el invocador; de lo contrario, git merge-base HEAD <remote>/<default-branch>, donde el control remoto es aquel en el que se fusiona el cambio (upstream en un fork), o HEAD cuando el cambio solo está sin commit. Ejecuta las comprobaciones que cubren el cambio, a través de la skill de verificación del repositorio si existe (.agents/skills/verify/), y corrige cualquier fallo antes de la ronda 1. Registra la revisión en la que se ejecutaron, incluidos los cambios sin commit.
Cada ronda comienza como una delegate_task nueva. Las respuestas contradictorias y las rondas posteriores van en la nueva instrucción, nunca en un mensaje de seguimiento a un revisor finalizado. Un tiempo de espera o error no es aprobación: reinicia el agente que falló, una vez.
Cuando el diff cambia solo comentarios, documentación o formato, no ejecutes el bucle y dilo en el mensaje final. En la ronda 1, inicia al revisor y al rompedor en paralelo, el rompedor con isolation: "worktree". Omite al rompedor cuando el diff no cambia código que se ejecuta. En una ejecución ligera (el nivel see-it-through pasa), no inicies un rompedor en la ronda 1; una vez que el revisor responda, inicia uno limitado a las condiciones en su línea "No verificado" que una prueba podría resolver, si las hay.
Ambas instrucciones comienzan con este encabezado:
Repositorio: <ruta absoluta> Base: <sha> Fuera del alcance: <alcance>
Estándares: <los archivos de reglas del repositorio, como AGENTS.md o CONTRIBUTING.md; o ninguno>
Configuración: <lo que cada shell debe ejecutar primero, como un script de herramientas fijadas, y lo que necesita un checkout nuevo, como una instalación; o ninguno>
Comprobaciones: <resultados> Ejecutando ahora: <comprobaciones aún en progreso; o ninguna>
Solicitud: <la solicitud o instrucción del usuario, palabra por palabra, o su ruta absoluta>
Enfoque: <el enfoque aprobado, o su ruta absoluta; o ninguno>. Sus afirmaciones son del autor: verifica aquellas de las que dependa el diff.
Aceptación: <el commit o parche que contiene las comprobaciones de aceptación escritas antes del cambio; o ninguno>
Diff: git diff <base>; también lee los archivos no rastreados de git status --short.
Condiciones: antes de leer el diff, escribe condiciones de aceptación a partir de la Solicitud: lo que el usuario debería ver u obtener en caso de éxito, fallo, cancelación y reintento; después de un fallo parcial (lo que queda en memoria, en disco y en pantalla); en una repetición, o un intento anterior que finaliza después de uno más reciente; cuando una espera retorna después de que el usuario haya seguido adelante; en cada superficie que muestre el resultado, incluidos los datos en caché; y una salida de cada estado que pueda dejar el cambio. Escribe una solo donde el código cambiado alcanza ese caso: en la ruta prevista, a través de cada otro invocador del código cambiado, y a través de cada otro escritor del estado en el que el cambio ahora confía (busca ambos).
Instrucción para el revisor, después del encabezado:
Solo revisar: lee y rastrea. No edites, hagas commit, hagas push, comentes, inicies subagentes, ni escribas o ejecutes pruebas o compilaciones.
Escribe las condiciones de aceptación como dice Condiciones, luego cómo harías el cambio dentro del Enfoque. Comienza tu respuesta final con ambas, palabra por palabra; la línea VEREDICTO las sigue.
Encuentra problemas con el cambio, rastreando cada condición a través del código hasta lo que el usuario ve u obtiene. Tu enfoque es un hallazgo solo donde cumple una condición que el diff falla, o cumple cada condición con menos código.
Por cada error que encuentres, nombra su clase y busca el mismo error en el resto del diff y sus invocadores, incluido un caso hermano que el cambio maneje de manera diferente; informa un hallazgo por clase, enumerando cada ubicación.
Verifica el cambio contra los archivos de Estándares; etiqueta esos hallazgos [estándares] y omite lo que los linters y las comprobaciones de tipo exigen.
Marca como nits código o guardas que ninguna condición necesita, código nuevo que el repositorio o la plataforma ya proporciona, y código que se aparta de los Estándares o las convenciones del código circundante; no estilo que simplemente prefieras.
Verifica si el cambio introduce propiedad competidora del estado, una decisión tomada en dos lugares, una obligación que los invocadores deben recordar, o un límite que los invocadores pueden eludir; etiqueta esos [estructura], nombrando el código y su consecuencia, y califícalos según las definiciones a continuación. Un diseño diferente sin tal consecuencia es un nit; un rediseño más grande es un hallazgo solo con por qué la corrección más pequeña no puede arreglarlo.
Una edición a una comprobación en Aceptación que impide que pruebe lo que prometió es un should.
bloqueador = el caso previsto es incorrecto. should = un problema que este cambio causa y que una acción o entrada admitida puede alcanzar: una acción del usuario, archivos en disco, un fallo de E/S, archivos que el usuario creó, mostrado ejecutándolo o rastreado a través del código, incluso a través de invocadores que el diff no tocó. Una prueba que el cambio agrega y que puede pasar sin el comportamiento que prueba es un should.
nit = estilo, pequeña mejora de rendimiento, pulido. preexistente = el mismo fallo ocurre en la base, mostrado por una prueba o un rastro, y el cambio ni lo hace más fácil de alcanzar ni contradice una afirmación que hace.
VEREDICTO: APPROVE o CHANGES, luego una línea por hallazgo:
S1 [bloqueador|should|nit|preexistente] <archivo>:<línea> <afirmación>. Corrección: <la corrección más pequeña>
luego Verificado: una línea por condición: <archivo>:<línea> y qué establece esa línea.
luego No verificado: lo que no pudiste confirmar, y por qué; o ninguno.
Instrucción para el rompedor, después del encabezado:
Rompe este cambio. No hagas commit, push, comentes ni inicies subagentes.
Trabaja solo en tu propio checkout, el directorio de trabajo en el que comenzaste, que es una copia de HEAD de <repo>. Primero trae la parte sin commit del cambio: git -C <repo> diff HEAD | git apply, luego copia los archivos no rastreados listados por git -C <repo> status --short. Nunca cambies archivos en <repo> o la configuración del usuario, y no ejecutes nada que haga push, publique o notifique; los cachés del gestor de paquetes están bien. Salta las ejecuciones E2E y cualquier cosa listada en Ejecutando ahora; compila solo lo que tus pruebas necesiten.
Escribe las condiciones de aceptación como dice Condiciones. Para cada una, escribe y ejecuta la prueba más pequeña que fallaría si la condición se rompiera, afirmando lo que el usuario ve u obtiene.
Para cada prueba por debajo de E2E que el cambio agrega como prueba, deshaz la guarda que debería atrapar, o rompe su condición previa, ejecútala, luego restaura el código.
NO PUDE PROBAR es solo para una condición que este nivel no puede alcanzar, como una que necesite E2E. Una cola lenta o tu propia configuración rota no lo es: agrupa tus pruebas en un solo trabajo, espéralo sin cancelarlo y arregla tu configuración.
Antes de responder, escribe un parche de tus pruebas que pasan y que cubren una condición que ninguna prueba existente cubre en <ruta de guardado>, y elimina todo lo demás que hayas agregado.
Responde, una línea por condición: B1 SOSTIENE <condición> — <comando>; B2 ROMPE <condición> — <comando> y la salida que falla; o B3 NO PUDE PROBAR <condición> — por qué. Luego una línea por prueba de demostración: P1 FALLA <prueba> con <guarda> deshecha; o P2 SIGUE PASANDO <prueba> con <guarda> deshecha. Luego: Guardado: <ruta de guardado> y la condición que cubre cada prueba; o ninguno.
Elige <ruta de guardado>: una ruta absoluta fuera de ambos checkouts.
2. Responder a los hallazgos
Califica cada hallazgo tú mismo según las definiciones de la instrucción del revisor, cualquiera que sea la etiqueta que tenga. Trata cada línea ROMPE y SIGUE PASANDO como un hallazgo.
- De acuerdo: reprodúcelo primero, con una prueba que falle en el código actual cuando una significativa sea práctica, de lo contrario una reproducción directa (comando y salida) con sus límites anotados; verifica una afirmación sobre hechos, como lo que CI ejecuta o lo que hace la base, contra su fuente. Luego busca en los casos hermanos e invocadores del código cambiado más de la clase del hallazgo, y aplica la corrección más pequeña a cada instancia que el cambio introdujo o expuso; enumera las preexistentes no relacionadas como seguimientos. Muestra que la prueba pasa (para un hallazgo SIGUE PASANDO, que la prueba corregida falla con la guarda deshecha) y conserva la prueba. Prefiere eliminar o reducir código sobre un nuevo bloqueo, caché, auxiliar u opción.
- En desacuerdo: di por qué, con evidencia (una prueba o salida de comando). Una razón leída solo del código, como "eso no puede pasar", deja el hallazgo en disputa, no descartado o degradado.
- Nit: en código que el diff agrega, cambia o mueve, aplícalo cuando su corrección elimina código, reutiliza lo que el repositorio o la plataforma proporciona, o alinea el código con los Estándares o el código circundante, manteniendo todas las comprobaciones pasando y sin intercambiar claridad por longitud. Rechaza en una línea un nit que agrega una ruta, caso, opción o capa de compatibilidad, uno cuya corrección cambia lo que el usuario ve u obtiene, y uno que es solo cuestión de gusto.
- Preexistente o fuera del alcance: recházalo en una línea.
Haz commit de cada prueba en el parche del rompedor, o nombra la prueba existente que cubre su condición.
Nunca estés de acuerdo solo para terminar el bucle. Vuelve a ejecutar las comprobaciones y git diff --shortstat <base>; elimina lo que la revisión agregó fuera de las pruebas que ningún hallazgo aceptado necesita, manteniendo la corrección correcta más pequeña incluso cuando crece el código.
3. Siguiente ronda
Inicia una solo cuando un bloqueador o should esté abierto, o el código de comportamiento haya cambiado. Envía el encabezado con su línea Condiciones reemplazada por las condiciones del revisor de la ronda 1, la instrucción del revisor sin su línea de condiciones y bosquejo, cada id anterior marcado como corregido, disputado (con la evidencia) o rechazado (con la razón), y los fragmentos cambiados desde la última ronda. Dile al revisor que revise solo los ids abiertos y esos fragmentos, que escriba nuevas condiciones para el comportamiento que esos fragmentos cambian y sus invocadores, que marque cada id anterior como resuelto o aún abierto, y que numere los nuevos hallazgos después del último id. Cuando una corrección cambió el comportamiento, el orden o la propiedad, como mover una escritura después de una espera, también inicia un rompedor con el mismo encabezado, indicándole que escriba y pruebe condiciones solo para esos fragmentos y sus invocadores.
4. Finalizar
Termina cuando no haya ningún bloqueador o should abierto y el último cambio fuera de pruebas, comentarios y formato haya pasado por una ronda; APPROVE termina el bucle temprano en el código que revisó. Envía un rompedor nuevo ante cualquier NO PUDE PROBAR cuya causa se pueda arreglar; enumera uno que necesite E2E para el autor. Si un bloqueador o should todavía está en disputa después de la ronda 3, ejecuta la ronda de disputa en ronda-de-disputa.md; un hallazgo que deje INCONCLUSO termina el bucle finalizado con disputas no resueltas, no aprobado. Los nits rechazados y los hallazgos preexistentes permanecen rechazados.
Mensaje final: rondas ejecutadas, los modelos, qué cambiaron los hallazgos, cada comportamiento, prueba, afirmación o pulido etiquetado, tamaño del diff antes y después, cualquier hallazgo descartado porque una prueba o salida mostró que era incorrecto, y cada nit o hallazgo preexistente rechazado con su razón. Agrega lo que el rompedor probó, qué rompió, cuáles de esos también encontró el revisor, y cada condición que ninguna prueba comprometida cubre. Si se ejecutó una ronda de disputa, da cada resultado. Enumera cada riesgo no confirmado en lenguaje sencillo. Si evals/results.jsonl existe y el modelo revisor difiere del último en él, dilo y ofrece una ejecución de la suite de regresión (evals/README.md).