Genera pull requests claros y fáciles de revisar a partir de un diff: título convencional, descripción del porqué, pruebas realizadas y checklist de integración continua. Inspirado en los skills virales de creación de PR para agentes de código.
Cuándo usarlo: Abrir pull requests que se revisan rápido y que dejan constancia clara de qué cambió, por qué y cómo comprobarlo.
Herramienta recomendada: Claude
rol: Eres un desarrollador cuidadoso que sabe que un buen pull request ahorra horas de revisión. Escribes para la persona que revisará el cambio sin haber participado en él. contexto: - Repositorio: [NOMBRE DEL REPOSITORIO] - Rama de origen y rama de destino: [RAMA ORIGEN] hacia [RAMA DESTINO] - Ticket o incidencia relacionada: [ID DEL TICKET O "ninguno"] - Convención de títulos del equipo: [POR EJEMPLO, CONVENTIONAL COMMITS: feat, fix, refactor, docs, chore] - Pasos de CI que existen: [POR EJEMPLO: lint, tests unitarios, tests de integración, análisis estático, build] - Diff o lista de commits: [PEGA EL DIFF O LOS MENSAJES DE COMMIT] - Notas adicionales del autor: [CONTEXTO QUE NO SE VE EN EL CÓDIGO] tarea: A partir del diff, prepara el pull request completo siguiendo estos pasos. Paso 1. Entender el cambio - Resume en dos frases qué cambia y por qué. - Detecta si el diff mezcla cambios que no tienen relación entre sí. Si es así, propón cómo dividirlo en varios pull requests y detente. Paso 2. Título - Máximo 72 caracteres. - Sigue la convención indicada, con ámbito si procede: tipo(ámbito): descripción en imperativo. - Sin punto final y sin palabras vacías como "varios cambios" o "arreglos". Paso 3. Descripción Usa exactamente estas secciones: - Qué: lista de cambios principales, agrupados por área. - Por qué: problema que resuelve o necesidad de negocio. - Cómo: decisiones técnicas relevantes y alternativas descartadas. - Cómo probarlo: pasos concretos que puede seguir el revisor, con datos de ejemplo. - Riesgos y reversión: qué podría fallar en producción y cómo deshacer el cambio. - Capturas o ejemplos: indica dónde convendría añadirlos si hay cambios visibles. - Cambios incompatibles: migraciones, variables de entorno nuevas, cambios de API. Si no hay, escribe "Ninguno". Paso 4. Checklist de CI y revisión Genera una lista de casillas con: - Cada paso de CI del proyecto. - Pruebas añadidas o actualizadas. - Documentación actualizada si cambia el comportamiento público. - Migraciones reversibles. - Sin secretos ni datos personales en el diff. - Sin código comentado ni trazas de depuración. Paso 5. Sugerencias para el revisor - Indica en qué archivos o funciones conviene centrar la revisión. - Señala dudas abiertas que el autor quiere que el revisor valide. formato de salida: 1. Bloque con el título final. 2. Bloque con la descripción en Markdown, lista para pegar. 3. Lista de etiquetas sugeridas (por ejemplo: bug, mejora, base de datos). 4. Nota breve si recomiendas dividir el pull request. reglas: - No inventes pruebas que no aparecen en el diff; si faltan, dilo en la checklist. - Escribe en español claro y directo, sin relleno. - Si el diff es demasiado grande para revisarlo bien (más de 400 líneas), adviértelo. Prepara ahora el pull request.