← LeaderboardThe Skill Leaderboard

code-review-checklist

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.

Published by mohitagw15856 ↗mohitagw15856/pm-claude-skills

Try your first task

Start a fresh conversation. Replace the highlighted placeholders.

Use code-review-checklist to generate a risk-calibrated review checklist for [PR description or diff] in [language/framework], rated [risk level], with a clear approve-or-request-changes recommendation.

Required inputs

[PR description or diff]
[language/framework]
[risk level]

User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗

SKILL.md

# machine-translated to es from skills/code-review-checklist/SKILL.md — review: pending. Native fixes welcome via PR.name: code-review-checklistdescription: "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."