Redactor de Descripciones de PR
Lee el diff de la rama actual y escribe una descripción completa para un pull request de GitHub. Crea o actualiza el PR con un solo comando.
Estilo de Redacción
Aplica a todas las descripciones de PR generadas:
- Voz activa. "Añade X" no "X ha sido añadido."
- Tiempo presente para el resumen ("Añade capa de caché"), tiempo pasado para el contexto ("El enfoque anterior provocaba N solicitudes por renderizado")
- Frases cortas, una idea por viñeta
- Sin guiones largos — usa una coma o un punto en su lugar
- Sin relleno: "este PR", "este commit", "según la discusión"
- Lo específico supera a lo general: "reduce la latencia p95 de 800 ms a 90 ms" es mejor que "mejora el rendimiento"
Paso 1: Verificar Configuración
Confirma que gh está autenticado:
gh auth status
Si no está autenticado: gh auth login y sigue las instrucciones.
Confirma que el directorio actual es un repositorio git con una rama activa:
git branch --show-current
Si HEAD está desprendido o no hay rama, detente y pregunta al usuario qué rama quiere describir.
Paso 2: Recopilar Contexto del Diff
Ejecuta los tres comandos para construir el contexto:
Resumen de archivos (qué cambió):
git diff main...HEAD --stat
Mensajes de commit (por qué cambió):
git log main...HEAD --oneline
Diff completo (cómo cambió):
Usa primero origin/main (siempre actualizado), luego main local, luego master:
if git rev-parse origin/main &>/dev/null 2>&1; then
BASE=origin/main
elif git rev-parse main &>/dev/null 2>&1; then
BASE=main
else
BASE=master
fi
git diff $BASE...HEAD
Si el diff es muy grande (más de 500 líneas), lee solo el resumen --stat y los mensajes de commit. También lee las primeras 200 líneas del diff para comprender los cambios principales sin procesar toda la salida.
Además, verifica si existe un PR y lee su título/cuerpo actual:
gh pr view --json title,body,baseRefName 2>/dev/null
Paso 3: Leer la Guía de Formato
Lee references/pr-format-guide.md completo antes de escribir nada. Interioriza:
- Secciones requeridas y su orden
- Cómo escribir cada sección
- Qué incluir vs. omitir
- El formato de la sección de pruebas
Paso 4: Generar la Descripción
Escribe la descripción del PR usando el formato de references/pr-format-guide.md.
Reglas:
- Cada viñeta de la sección Cambios debe corresponder a algo del diff
- No inventes pasos de prueba que no estén implícitos en los cambios de código
- Si una sección no tiene contenido relevante, omítela por completo (no escribas "N/A" ni la dejes vacía)
- Sección de capturas de pantalla: inclúyela solo si hay cambios visibles en la interfaz de usuario en el diff
- Si los mensajes de commit explican el "por qué", usa ese contexto en el Resumen
Punto de control de calidad: Antes de presentar, verifica:
- Resumen de 1 a 2 frases, voz activa, sin relleno
- Cada viñeta de cambio es específica y corresponde al diff
- Sin métricas ni resultados inventados
- Los pasos de prueba son accionables (alguien podría seguirlos)
- Sin guiones largos en ninguna línea
Paso 5: Crear o Actualizar el PR
Presenta la descripción al usuario y pregunta: "¿Listo para crear el PR, actualizar el existente o solo mostrar la salida?"
Crear un nuevo PR:
Pasa el cuerpo por stdin para manejar comillas invertidas, comillas y saltos de línea de forma segura:
gh pr create --title "TITULO_AQUI" --body-file - << 'EOF'
CUERPO_AQUI
EOF
Sugiere un título basado en los mensajes de commit y el resumen del diff. El título debe estar en modo imperativo y tener menos de 72 caracteres: "Añade caché Redis para búsquedas de sesión de usuario" no "Añadido caché".
Actualizar un PR existente:
gh pr edit --body-file - << 'EOF'
CUERPO_AQUI
EOF
Solo mostrar salida: Presenta el título y el cuerpo en un bloque de código para copiar y pegar manualmente.
Después de crear o actualizar, confirma: "Descripción del PR actualizada. Véala en: [URL]"