| 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
-
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.
-
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é"?
-
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.
-
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?
-
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?
-
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)?
-
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%.
-
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.
