--- # machine-translated to es from skills/code-review-checklist/SKILL.md — review: pending. Native fixes welcome via PR. name: code-review-checklist description: "Genera un checklist de revisión de código personalizado para cualquier pull request basado en el lenguaje, tipo de cambio y nivel de riesgo. Úsalo cuando te pidan revisar código, verificar un PR, revisar un pull request o generar un checklist de revisión de código. Produce un checklist enfocado con verificaciones específicas del lenguaje, profundidad apropiada al nivel de riesgo y una recomendación clara de aprobar o solicitar cambios." --- # Habilidad de Checklist de Revisión de Código Produce un checklist de revisión de código personalizado para un pull request específico — escalado al lenguaje, tipo de cambio y nivel de riesgo. No es una plantilla genérica. > **¿No es exactamente esto?** Usa `code-review-guide` cuando quieras realizar la revisión en sí con criterio senior, no solo un checklist. ## Entradas Requeridas Trabaja con lo que se proporciona. Si falta alguna de estas, aún así produce el resultado completo: completa cada vacío con una suposición razonable marcada *(supuesto, confirma)* y lista esas suposiciones al final. Haz una pregunta solo cuando el tema central mismo falte (no hay nada sobre qué escribir). - **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** (bajo / medio / alto / crítico) - **Descripción del PR** (pega la descripción o enlaza al PR) - **Código o diff** (opcional — pega archivos clave modificados o un `git diff`; mejora significativamente la especificidad del checklist) - **Contexto del autor** (nuevo en el equipo / experimentado / colaborador externo) ## Formato de Salida --- # Revisión de Código: [Título o Referencia del PR] ### 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 / Análisis profundo] **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. Verificaciones de Corrección Verificaciones de corrección específicas del lenguaje — elige basándote en el lenguaje indicado: **Para TypeScript/JavaScript:** - Las definiciones de tipo coinciden con el uso real - Sin `any` implícito en código que no sea de prueba - Async/await utilizado consistentemente; sin promesas sin manejar - Manejo explícito de null/undefined **Para Python:** - Type hints presentes en funciones públicas - Manejo de excepciones específico (sin except desnudo) - Los recursos se cierran (context managers, bloques with) **Para Go:** - Los errores se manejan o se ignoran explícitamente con un comentario - La propagación de contexto es correcta - Los tiempos de vida de las goroutines están acotados [Incluye solo la sección que coincida con el lenguaje indicado] ### 3. Verificaciones Específicas del Tipo de Cambio **Para corrección de bugs:** - Existe una prueba que habría detectado este bug - La corrección aborda la causa raíz, no el síntoma - Se verificaron rutas de código relacionadas para el mismo problema **Para features:** - Se cumplen los criterios de aceptación - Se manejan casos extremos (vacío, grande, concurrente) - Las rutas de error se prueban, no solo el caso de éxito - Se agregó telemetría/logging para debugging **Para refactors:** - El comportamiento no cambia (las pruebas aún pasan) - Sin scope creep — solo refactor - La complejidad se reduce, no solo se mueve **Para actualizaciones de dependencias:** - Se revisaron los cambios de ruptura - Se verificaron los avisos de seguridad - Se verificó la compatibilidad de licencias [Incluye solo la sección que coincida con el tipo de cambio indicado] ### 4. Verificaciones Apropiadas al Nivel de Riesgo **Riesgo bajo:** corrección básica, convenciones de estilo, cobertura de pruebas **Riesgo medio:** arriba + plan de reversión, actualizaciones de monitoreo, consideraciones de rendimiento **Riesgo alto:** arriba + implicaciones de seguridad, seguridad de migración de datos, feature flag/despliegue gradual **Riesgo crítico:** arriba + plan de validación en staging, plan de respuesta ante incidentes, checklist de verificación posterior al despliegue ### 5. Adecuación de Pruebas - Las pruebas unitarias cubren la lógica nueva - Las pruebas de integración cubren los cambios de contrato - Se prueban casos extremos - Se prueban modos de fallo - 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 dignos de discusión pero no bloqueantes para merge] ### 7. Trampas Comunes para Este Tipo de Cambio Basándote en el tipo de cambio y lenguaje, señala 2-3 cosas que los revisores típicamente pasan por alto para esta combinación. --- ## Materiales Más Profundos Esta habilidad viene con archivos de apoyo — úsalos cuando estén disponibles: - **`references/review-depth-calibration.md`** — Calibrando la Profundidad de Revisión: No Todos los PR Merecen los Mismos Ojos. Aplícalo mientras produces el resultado; contiene la calibración y decisiones de criterio que el resumen del método anterior comprime. - **`templates/review-record.md`** — una versión para rellenar del resultado con los gates de calidad en línea. Ofrécela cuando el usuario quiera trabajar el documento por sí mismo en lugar de tenerlo generado. ## Rúbrica de Puntuación (0–40) Puntúa cualquier resultado de esta habilidad antes de entregarlo; 32+ es calidad de envío. | Dimensión | 0 | 5 | 10 | |---|---|---|---| | **Especificidad del lenguaje** | Las verificaciones podrían aplicarse a cualquier lenguaje — intercambiar un nombre de lenguaje no cambiaría nada | Se elige el bloque de lenguaje correcto, pero las verificaciones repiten la plantilla en lugar de los constructos de este PR | Cada verificación de corrección nombra un constructo que realmente está en el diff (goroutines, cadenas de promesas, context managers) | | **Calibración de profundidad-riesgo** | Misma profundidad independientemente del nivel de riesgo indicado | La profundidad se escala aproximadamente, pero los extras de alto riesgo (plan de reversión, despliegue por fases, monitoreo) faltan o son tokenistas | La profundidad coincide exactamente con el riesgo indicado y la estimación de tiempo de revisión sigue la guía de tamaño de diff | | **Nitidez del marco de decisión** | "Aprobar si se ve bien" — sin condiciones nombradas | Se enumeran bloqueadores pero no son verificables; un revisor no puede decir cuándo están satisfechos | Cada condición de aprobación/bloqueo/comentario es verificable contra una prueba, bandera, métrica o artefacto específico | | **Especificidad de trampa** | Trampas ausentes o genéricas ("cuidado con los bugs") | Las trampas coinciden con el lenguaje *o* el tipo de cambio, pero no con la combinación | 2–3 trampas que solo tienen sentido para esta combinación exacta de lenguaje + tipo de cambio | ## Verificaciones de Calidad - [ ] El checklist está personalizado al lenguaje indicado (no genérico) - [ ] Se incluye la sección específica del tipo de cambio - [ ] La profundidad apropiada al riesgo coincide con el nivel de riesgo indicado - [ ] El marco de decisión incluye al menos una condición de bloqueo nombrada y una condición de comentario no bloqueante nombrada - [ ] Las trampas comunes son específicas de la combinación lenguaje + tipo de cambio indicada (no consejos genéricos como "cuidado con los bugs") ## Antipatrones - [ ] No generes un checklist genérico que ignore el lenguaje indicado — un checklist de Python y uno de Go tienen preocupaciones de corrección fundamentalmente diferentes - [ ] No trates "se ve bien" como un resultado válido de revisión — el checklist existe para surfacear preocupaciones específicas, no para validar una lectura superficial - [ ] No delimites una revisión de "riesgo alto" igual que una de "riesgo bajo" — la profundidad debe escalar con el nivel de riesgo indicado - [ ] No señales cada preferencia estilística como un problema de bloqueo — distingue entre problemas de corrección bloqueantes y comentarios no bloqueantes - [ ] No omitas la sección "trampas comunes" para la combinación de lenguaje y tipo de cambio indicada — aquí es donde vive el conocimiento más valioso ## Ejemplos de Uso - "Genera un checklist de revisión de código para [descripción del PR]" - "¿Qué debo verificar en este pull request?" - "Dame un checklist de revisión de código para un [lenguaje] [tipo de cambio]" - "Checklist de revisión para un PR de riesgo alto en [lenguaje]" ## Frases Desencadenantes de Ejemplo - "Revisa código." - "Verifica un PR." - "Revisa un pull request." - "Genera un checklist de revisión de código."