Redacta una descripción de pull request clara y estructurada a partir de un diff de git, resumen de rama o lista de commits. Úsalo cuando te pidan escribir una descripción de PR, redactar una solicitud de cambios o documentar cambios de código. Produce una descripción con resumen, motivación, cambios realizados, pasos de prueba y orientación para revisores.
Start a fresh conversation. Replace the highlighted placeholders.
Use pr-description-writer to draft a structured PR description from [change summary], covering motivation, test steps, risk level, PR type, target branch, and linked issue.
Required inputs
[change summary]
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/pr-description-writer/SKILL.md — review: pending. Native fixes welcome via PR.name: pr-description-writerdescription: "Redacta una descripción de pull request clara y estructurada a partir de un diff de git, resumen de rama o lista de commits. Úsalo cuando te pidan escribir una descripción de PR, redactar una solicitud de cambios o documentar cambios de código. Produce una descripción con resumen, motivación, cambios realizados, pasos de prueba y orientación para revisores."
Habilidad de Redacción de Descripciones de PR
Redacta descripciones de pull request estructuradas y amigables para revisores a partir de un diff, lista de commits o notas informales. Cubre el qué, por qué y cómo revisar para que los revisores puedan empezar inmediatamente.
Inputs Requeridos
Solicita estos si no se proporcionan:
Qué cambió (pega un git diff, git log --oneline, o describe los cambios en texto plano)
Por qué cambió (el problema que se resuelve o la funcionalidad que se añade)
Cómo probarlo (cualquier paso específico que un revisor necesite para verificar que funciona)
Nivel de riesgo (bajo / medio / alto — afecta cuánta orientación para revisores incluir)
Tipo de PR (feature / bug fix / refactor / dependency upgrade / config change / hotfix)
Rama destino (p. ej. main / develop / release/2.4 — afecta el encuadre de riesgo y la orientación para revisores)
Issue o ticket vinculado (p. ej. JIRA-1234, GitHub #567 — o "ninguno")
Formato de Salida
Título
Un título claro en modo imperativo de menos de 72 caracteres:
[type]: [descripción concisa de qué cambió]
Ejemplos:
feat: añadir rate limiting a la API pública
fix: resolver race condition en expiración de sesión
refactor: extraer lógica de pagos a PaymentService
Resumen
2–3 oraciones que cubran:
Qué hace este PR (el cambio)
Por qué era necesario (el problema u objetivo)
El enfoque adoptado (a alto nivel)
Cambios Realizados
Lista con viñetas de cambios específicos — una viñeta por cambio lógico, no por archivo:
Añadido [X] para manejar [Y]
Refactorizado [A] para reducir [B]
Eliminado [C] ya que fue reemplazado por [D]
Actualizado [E] para corregir [F]
Capturas de Pantalla / Demo
[Si hay cambio de UI: incluye capturas antes/después o una grabación de pantalla]
[Si hay cambio de API: incluye ejemplo de request/response]
[Si no hay cambio visual y sin cambio de contrato de API: omite completamente esta sección — no dejes un marcador vacío]
Cómo Probar
Instrucciones paso a paso que un revisor pueda seguir:
[Paso de configuración si es necesario]
[Acción a realizar]
[Qué verificar]
[Caso extremo a comprobar]
Incluye comandos específicos, datos de prueba o flags de entorno necesarios.
Lista de Verificación de Pruebas
Pruebas unitarias añadidas/actualizadas
Pruebas de integración añadidas/actualizadas
Casos extremos cubiertos
Pruebas manuales completadas
Sin regresiones en pruebas existentes
Notas para Revisores
Señala cualquier cosa que merezca atención adicional:
Áreas de incertidumbre donde una segunda opinión es bienvenida
Trade-offs deliberados realizados (y por qué)
Elementos fuera de alcance notados pero no abordados
Dependencias en otros PRs (vinculalos)
Relacionado
Closes #[número de issue] (si aplica)
Related to #[número de PR/issue]
Verificaciones de Calidad
El título está en modo imperativo y tiene menos de 72 caracteres
El resumen explica qué Y por qué (no solo qué)
La lista de cambios describe cambios lógicos (no cambios archivo por archivo)
El título comienza con un prefijo de tipo válido (feat / fix / refactor / chore / deps / config / hotfix) y tiene menos de 72 caracteres
Los pasos de prueba son reproducibles por alguien no familiarizado con el código
Para PRs de alto riesgo, Notas para Revisores señala al menos un área específica de preocupación o trade-off deliberado; para PRs de bajo riesgo, Notas para Revisores se omite o se reduce a una línea
Anti-Patrones
No escribas una descripción que solo restate qué cambió — explica por qué se hizo el cambio
No omitas los pasos de prueba — los revisores necesitan saber cómo verificar que el cambio funciona
No omitas las notas para revisores en PRs de alto riesgo — señala trade-offs deliberados y áreas que necesitan revisión cuidadosa
No describas detalles de implementación obvios en el diff — añade contexto que el diff no puede proporcionar
No produzcas un solo párrafo — estructura con encabezados para que los revisores puedan navegar a lo que necesitan
Ejemplos de Uso
"Escribe una descripción de PR para estos cambios" + [pega diff o descripción]
"Redacta una solicitud de cambios para [feature]"
"Necesito una descripción de PR — aquí está lo que cambié"