Code Review

---
name: code-review
description: "Usar para revisar código con foco en calidad, legibilidad y errores lógicos. También: revisar código, buscar errores, calidad del código, revisión de PR, pull request review."
---

# Revisión de código

## Resumen

Este skill ejecuta una revisión de código exhaustiva centrada en calidad, legibilidad, mantenibilidad y corrección lógica. La revisión no es un trámite burocrático sino una herramienta para mejorar el código y compartir conocimiento dentro del equipo.

Si las herramientas del toolkit `pr-review-toolkit` están disponibles, este skill las coordina para cubrir múltiples perspectivas: calidad general, fallos silenciosos y oportunidades de simplificación.

## Proceso

1. **Entender el contexto del cambio.** Antes de revisar línea por línea, entender el propósito del cambio. Leer la descripción del PR, el issue asociado o preguntar al usuario. Un cambio que parece incorrecto puede ser correcto si se entiende el contexto.

2. **Revisar la legibilidad.** El código se lee muchas más veces de las que se escribe:

   - Los nombres de variables, funciones y clases son descriptivos?
   - La estructura del código es clara sin necesidad de comentarios explicativos?
   - Las funciones son cortas y con responsabilidad única?
   - Los comentarios explican el "por qué", no el "qué"?

3. **Buscar errores lógicos.** Los bugs más peligrosos son los que no producen error:

   - Condiciones invertidas o incompletas.
   - Off-by-one errors en bucles e índices.
   - Variables no inicializadas o reutilizadas incorrectamente.
   - Race conditions en código asíncrono.
   - Falta de manejo de null/undefined/None.

4. **Verificar manejo de errores.** Los errores silenciosos son los peores:

   - Los catch/except vacíos se usan sin justificación?
   - Los errores se propagan correctamente o se tragan?
   - El usuario recibe información útil cuando algo falla?
   - Los errores se registran para depuración posterior?

5. **Evaluar la complejidad.** El código simple es más fácil de mantener y menos propenso a bugs:

   - Hay condicionales anidados profundamente que se podrían simplificar?
   - Hay duplicación que se podría abstraer?
   - Las abstracciones existentes son justificadas o son sobreingeniería?

6. **Verificar cobertura de edge cases.** Para cada función o flujo crítico:

   - Qué pasa con inputs vacíos?
   - Qué pasa con valores extremos (muy grandes, muy pequeños, negativos)?
   - Qué pasa con tipos inesperados?
   - Qué pasa bajo condiciones de error (red, disco, permisos)?

7. **Delegar en herramientas especializadas si están disponibles.** Si `pr-review-toolkit` está disponible:

   - `code-reviewer`: revisión general de calidad y adherencia a convenciones.
   - `silent-failure-hunter`: detección de fallos silenciosos y manejo inadecuado de errores.
   - `code-simplifier`: oportunidades de simplificación sin alterar funcionalidad.

   Umbral de confianza: solo reportar hallazgos con confianza >= 80%.

8. **Documentar hallazgos.** Cada hallazgo debe incluir: ubicación en el código, descripción del problema, impacto potencial y sugerencia de corrección.

## Criterios de éxito

- Se han revisado legibilidad, errores lógicos, manejo de errores, complejidad y edge cases.
- Los hallazgos incluyen ubicación, descripción, impacto y sugerencia de corrección.
- Solo se reportan hallazgos con confianza >= 80%.
- El tono de la revisión es constructivo y orientado a mejorar el código.
- Se distingue entre problemas que bloquean y sugerencias de mejora.

## Clarificación

Este skill guía la revisión de código. Para responder a los comentarios de una review recibida, usar `desarrollo/code-review-response`.

## Qué NO hacer

- No centrarse solo en el estilo (formateo, nombres, convenciones). Revisar la lógica primero; los problemas de estilo son los menos importantes.
- No aprobar sin haber entendido el contexto del cambio. Si no se entiende por qué se hizo un cambio, preguntar antes de opinar.
- No reportar hallazgos sin justificación. Cada comentario debe explicar el problema, el riesgo y la alternativa sugerida.
- No convertir la revisión en una lista de preferencias personales. Ceñirse a problemas objetivos de calidad, no a gustos.