Explicador de PR + cuestionario de comprensión

¿Qué hace Explicador de PR + cuestionario de comprensión?

La codificación asistida por IA facilita aprobar código que nunca entendiste realmente. Esta skill explica un cambio al nivel que necesita un revisor, y luego verifica la comprensión con algunas preguntas precisas — para que "LGTM" signifique algo.

1. Recopilar el cambio

Elige el que aplique:

gh pr view <num> --json title,body,baseRefName,headRefName,files   # GitHub PR
gh pr diff <num>
git diff <base>...<head>                                            # rama
git show <sha>                                                     # commit individual

Lee la descripción del PR y el issue vinculado, si lo hay. Luego lee el código circundante de las funciones modificadas (llamantes, llamados, pruebas) — un diff solo oculta el contexto que importa.

2. Explicar — en este orden

1. Resumen de un párrafo: qué comportamiento cambia para un usuario o llamante. No es una lista de archivos.
2. Por qué: el problema que se resuelve, según la descripción/issue/mensajes de commit. Si la razón no se menciona en ningún lado, dilo — eso es un hallazgo de revisión.
3. Diagrama: un sequenceDiagram o flowchart de Mermaid del nuevo flujo, resaltando lo nuevo/cambiado (usa una nota o la clase :::changed). Mantenlo por debajo de ~15 nodos; diagrama la ruta central, no todo.
4. Recorrido por concepto, no por archivo: agrupa fragmentos relacionados ("la lógica de reintento", "el nuevo flag de configuración"). Para cada uno: qué hace, y cualquier aspecto no obvio (concurrencia, manejo de errores, casos límite, rendimiento).
5. Notas de riesgo: cosas que un revisor debe mirar con más atención — interfaces públicas modificadas, migraciones, pruebas eliminadas, rutas de error ignoradas, código sensible a seguridad, pruebas faltantes para nuevas ramas. Sé específico con archivo:línea.

3. Cuestionario

Haz 3–5 preguntas, una a la vez, esperando la respuesta antes de la siguiente. Las buenas preguntas requieren comprensión, no memoria:

• "¿Qué sucede ahora si <dependencia> expira durante <operación>?"
• "¿Qué llamante existente se ve afectado por el cambio de firma, y cómo?"
• "¿Por qué <línea> debe ir antes de <línea>?"
• "Si revertimos esto después de que la migración se ejecutó, ¿qué se rompe?"

Evita trivialidades ("¿cómo se llama la nueva función?"). Combina: al menos una sobre fallo/comportamiento límite, una sobre por qué se tomó una decisión de diseño.

Después de cada respuesta: di si es correcta, y da la explicación correcta en 1–3 frases con una referencia de código. Si se equivocan en algo importante, sugiere qué parte del diff releer.

4. Conclusión

Puntaje (ej. 4/5) y un veredicto breve: "listo para revisar", o "relee X antes de aprobar". Ofrece redactar comentarios de revisión para cualquier riesgo encontrado.

Alcance según la solicitud

El flujo completo (resumen → por qué → diagrama → recorrido → riesgos → cuestionario) es el valor predeterminado para "guíame a través de esto" o "ayúdame a revisar". Cuando el usuario acota la solicitud, respétala:

• "sin cuestionario" / "salta el cuestionario": pasos 1–2 sin paso 3.
• "solo el resumen y riesgos": el resumen de un párrafo y las notas de riesgo, nada más: sin diagrama, sin recorrido. Ofrece el resto en una línea final.
• "solo el diagrama": el diagrama más un pie de foto de dos frases.

El primer riesgo listado debe ser el que cambia el comportamiento para usuarios o el dinero (como un cobro incorrecto silencioso), no el más interesante técnicamente.