--- name: mohitagw15856/code-review-checklist source: https://app.decimal.ai/s/mohitagw15856-code-review-checklist@3/SKILL.md source_sha256: e735885b84c8 --- # 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]"