JulienLerosty/claude-code-team-kit

Revisar una solicitud de extracción

1. Obtén el diff. Para un número de PR usa gh pr diff <número>; de lo contrario, git diff origin/main...HEAD. También lee la descripción del PR si existe (gh pr view <número>).
2. Lee los archivos modificados completos cuando el diff por sí solo no sea claro. No revises código que no hayas leído.
3. Verifica, en este orden:
   • Corrección: condiciones incorrectas, off-by-one, errores no manejados, condiciones de carrera, entradas nulas/vacías.
   • Pruebas: ¿cada cambio de comportamiento está cubierto? ¿Fallarían las pruebas sin el cambio?
   • Seguridad: entrada no confiable que llegue a shell, SQL, rutas de archivo o HTML; secretos en el diff.
   • Compatibilidad: interfaces públicas cambiadas, migraciones, configuración o variables de entorno.
   • Legibilidad: solo problemas que ralentizarían al próximo mantenedor. Omite preferencias de estilo puras que el linter ya cubre.
4. Ejecuta npm test si existen pruebas y reporta el resultado honestamente.

Formato de salida

## Resumen
Una o dos oraciones sobre lo que hace el PR y tu veredicto general (aprobar / solicitar cambios / comentar).

## Debe corregirse
- `ruta/archivo.js:42` Qué está mal, por qué es importante, sugerencia de corrección.

## Debería considerarse
- `ruta/archivo.js:90` ...

## Opcional
- ...

Omite una sección si está vacía. Cita archivo:línea para cada hallazgo. No inventes problemas: si el cambio está bien, dilo en el resumen. No publiques comentarios en GitHub a menos que el usuario lo solicite.