Habilidad de Lista de Verificación de Revisión de Código

Produce una lista de verificación de revisión de código personalizada para una solicitud de cambios específica — escalada al lenguaje, tipo de cambio y nivel de riesgo. No es una plantilla genérica.

Entradas Requeridas

Solicita al usuario estos datos si no los proporciona:

• Lenguaje y framework (p. ej. TypeScript + React / Python + FastAPI / Go)
• Tipo de cambio (feature / bug fix / refactor / dependency upgrade / security patch / performance)
• Nivel de riesgo (low / medium / high / critical)
• Descripción del PR (pega la descripción o un enlace al PR)
• Código o diff (opcional — pega archivos clave modificados o un git diff; mejora significativamente la especificidad de la lista)
• Contexto del autor (developer junior / experimentado / contributor externo)

Formato de Salida

Revisión de Código: [Título del PR o Referencia]

1. Descripción General del PR

Evaluación del alcance: [Pequeño / Medio / Grande / Demasiado grande — debería dividirse] Profundidad de revisión recomendada: [Rápida / Estándar / Profunda] Tiempo estimado de revisión: [p. ej. 20–30 min — usa aproximadamente 5 min por cada 50 líneas de diff como guía]

2. Comprobaciones de Corrección

Comprobaciones de corrección específicas del lenguaje — elige según el lenguaje indicado:

Para TypeScript/JavaScript:

• Las definiciones de tipos coinciden con el uso real
• No hay any implícito en código de no-prueba
• async/await se usa consistentemente; no hay promesas sin manejar
• El manejo de null/undefined es explícito

Para Python:

• Type hints presentes en funciones públicas
• El manejo de excepciones es específico (sin except desnudo)
• Los recursos se cierran (context managers, with blocks)

Para Go:

• Los errores se manejan o se ignoran explícitamente con un comentario
• La propagación de Context es correcta
• Los tiempos de vida de goroutine están limitados

[Incluye solo la sección que coincida con el lenguaje indicado]

3. Comprobaciones Específicas del Tipo de Cambio

Para bug fixes:

• Existe una prueba que hubiera detectado este bug
• El fix aborda la causa raíz, no el síntoma
• Rutas de código relacionadas verificadas para el mismo problema

Para features:

• Criterios de aceptación cumplidos
• Casos límite manejados (vacío, grande, concurrente)
• Rutas de error probadas, no solo el camino feliz
• Telemetría/logging añadido para depuración

Para refactors:

• Comportamiento sin cambios (las pruebas siguen pasando)
• Sin scope creep — solo refactor
• Complejidad reducida, no solo movida

Para dependency upgrades:

• Breaking changes revisados
• Security advisories verificados
• Compatibilidad de licencia verificada

[Incluye solo la sección que coincida con el tipo de cambio indicado]

4. Comprobaciones Apropiadas al Nivel de Riesgo

Low risk: corrección básica, convenciones de estilo, cobertura de pruebas Medium risk: anterior + plan de rollback, actualizaciones de monitoreo, consideraciones de rendimiento High risk: anterior + implicaciones de seguridad, seguridad de migración de datos, feature flag/rollout gradual Critical risk: anterior + plan de validación en staging, plan de respuesta ante incidentes, checklist de verificación post-despliegue

5. Adecuación de Pruebas

• Las pruebas unitarias cubren la lógica nueva
• Las pruebas de integración cubren los cambios de contrato
• Casos límite probados
• Modos de fallo probados
• Pruebas de rendimiento si es sensible al rendimiento

6. Marco de Decisión de Revisión

Aprobar si: [2-3 condiciones específicas basadas en este PR] Solicitar cambios si: [Bloqueadores específicos] Comentar (no bloqueante) si: [Elementos que valen la pena discutir pero no bloquean la fusión]

7. Trampas Comunes para Este Tipo de Cambio

Basado en el tipo de cambio e idioma, señala 2-3 cosas que los revisores típicamente pasan por alto para esta combinación.

Comprobaciones de Calidad

• La lista está personalizada al lenguaje indicado (no genérica)
• La sección específica del tipo de cambio está incluida
• La profundidad apropiada al riesgo coincide con el nivel de riesgo indicado
• El marco de decisión incluye al menos una condición bloqueante nombrada y una condición de comentario no bloqueante nombrada
• Las trampas comunes son específicas de la combinación lenguaje + tipo de cambio (no consejos genéricos como "cuidado con los bugs")

Anti-Patrones

• No generes una lista genérica que ignore el lenguaje indicado — una lista de Python y una de Go tienen preocupaciones de corrección fundamentalmente diferentes
• No trates "se ve bien" como un resultado válido de revisión — la lista existe para identificar preocupaciones específicas, no para validar una lectura superficial
• No hagas un scope de una revisión "high risk" igual que una revisión "low risk" — la profundidad debe escalar con el nivel de riesgo indicado
• No marques cada preferencia estilística como un problema bloqueante — distingue entre problemas bloqueantes de corrección y comentarios no bloqueantes
• No omitas la sección "trampas comunes" para la combinación lenguaje + tipo de cambio indicada — aquí es donde vive el conocimiento más valioso

Ejemplos de Uso

• "Genera una lista de verificación de revisión de código para [descripción del PR]"
• "¿Qué debo verificar en esta solicitud de cambios?"
• "Dame una lista de verificación de revisión de código para un [lenguaje] [tipo de cambio]"
• "Lista de verificación de revisión para un PR de alto riesgo en [lenguaje]"