103kaz/claude-code-loops

review-loop

Ejecuta el ciclo de desarrollo sobre la rama actual: verificar, revisar el diff, corregir y repetir hasta que una ronda no encuentre nada. El alcance es solo el diff, no todo el código base. Este skill no hace push ni abre un pull request; esas acciones quedan para el usuario.

Pasos

1. Ejecuta .claude/verify.sh. Si falla, arréglalo primero. Si el archivo no existe, dile al usuario y señala a /code-loops:init-verify, luego continúa sin verificación e indícalo en el informe.
2. Determina el diff. Primera ronda: la rama contra su base (git diff origin/HEAD...HEAD, más git diff HEAD para cambios no commiteados, más los archivos no rastreados de git status --short, que lees directamente). Si origin/HEAD no está configurado, prueba origin/main o origin/master; si ninguno existe, pregúntale al usuario por la base. Si el diff está vacío (por ejemplo, estás en la rama base), informa que no hay nada que revisar y detente. Si los cambios no commiteados no están relacionados con el trabajo de la rama, no los corrijas; menciónalos en el informe. Siguientes rondas: solo lo que cambiaste en la ronda anterior.
3. Revisa el diff.
   • Si cambia código, usa el skill code-review con esfuerzo medio. Si ese skill no está disponible, lee el diff tú mismo en busca de errores: resultados incorrectos, rutas de error faltantes y llamadas que el cambio rompe.
   • Si cambia solo documentación (.md y similares), usa /code-loops:doc-code-consistency en el diff.
4. Corrige los hallazgos. No hagas commit; déjaselo al usuario. Después de cada corrección, vuelve al paso 1. Repite hasta que una ronda no encuentre nada. Un hallazgo que decidas no corregir recibe una razón de una línea. Si tres rondas seguidas siguen encontrando hallazgos (un fallo de verify.sh cuenta), detente e informa lo que queda en lugar de continuar.
5. Si el diff cambió código que la documentación describe, ejecuta /code-loops:doc-code-consistency en el diff una vez al final y corrige lo que encuentre.
6. Ofrece una revisión independiente, una sola vez, a menos que el diff sea solo documentación. Pregúntale al usuario (AskUserQuestion) si ejecutarla, con una nota de una línea sobre si este diff parece valer la pena (tamaño, áreas riesgosas); el valor predeterminado es no. Si acepta, inicia un subagente que vea solo el diff, no cómo se construyó. Usa un tipo de agente de solo lectura si existe (por ejemplo, Explore); de lo contrario, indícale que no edite archivos. Haz que busque las entradas, estados y ordenamientos que rompen el cambio, y reporte cada uno con evidencia archivo:línea; si existe .claude/review/checklist.md, haz que también lo verifique contra eso. Corrige lo que encuentre, luego ejecuta los pasos 1 y 3 solo en esas correcciones. Si los subagentes no están disponibles, omite este paso e indícalo en el informe.
7. Informa en unas pocas líneas: "Resultado: sin hallazgos", o "Resultado: hallazgos mantenidos" con cada hallazgo y su razón. Agrega si verify.sh pasó, cuántas rondas tomó y si se realizó una revisión independiente.

Mantén cada ronda silenciosa: lee el diff, no el repositorio, y no repitas los hallazgos de una ronda anterior.