Genera el título y la descripción de un pull request en inglés, basándose únicamente en los cambios de código respecto a master (no en los mensajes de commit). Se invoca con el slash command /pr-description, o cuando el usuario pida explícitamente generar/redactar la descripción, el título o el mensaje de un PR, merge request, o pull request. Actívala siempre que el usuario mencione 'descripción de PR', 'título de PR', 'mensaje de PR', 'PR description', o pida ayuda para documentar un pull request sobre el repositorio actual de Claude Code.
Genera el título y la descripción de un pull request analizando el diff del branch actual contra master. Todo el contenido producido va en inglés.
/pr-descriptionEsta skill se ejecuta desde Claude Code, por lo tanto:
master.git branch, git diff, y la escritura en .git/info/exclude. Nada de git add, commit, push, reset, checkout, merge, etc.git branch --show-current
Guarda el nombre de la rama. Se usará para extraer el ticket-id y, en algunos casos, como prefijo del título.
Busca en el nombre de la rama la primera secuencia de dígitos que aparezca (sin importar qué prefijo de letras la acompañe).
TXW-<numero>.Ejemplos:
feature/TXW-1234-login → ticket-id = 1234bug/ABC-999-fix-auth → ticket-id = 999refactor/5678 → ticket-id = 5678hotfix-login → sin ticket-idupdate-readme → sin ticket-idSe usa archivo temporal en la raíz del repo (no en memoria) para permitir leer el diff por rangos con view y evitar cargar PRs grandes enteros al contexto. Esto ahorra tokens cuando el diff es extenso.
Antes de crearlo, registrar su nombre en .git/info/exclude para que no aparezca como untracked durante el análisis. .git/info/exclude es el mecanismo oficial de git para exclusiones locales no versionadas — no se comparte al hacer push y no contamina el .gitignore del proyecto.
TMP_DIFF="pr-description.diff"
grep -qxF "$TMP_DIFF" .git/info/exclude || echo "$TMP_DIFF" >> .git/info/exclude
git diff master...HEAD > "$TMP_DIFF"
El operador ... calcula el merge-base automáticamente, así que el diff muestra solo lo que esta rama introdujo respecto a master, no cambios que ocurrieron en master después de ramificar.
Si el diff está vacío (archivo de 0 bytes), avisa al usuario que la rama no tiene cambios respecto a master y termina (después de la limpieza del Paso 6).
Lee el archivo temporal por rangos con view según lo necesites. No lo cargues entero si es grande — empieza viendo la lista de archivos modificados (primeras líneas del diff) y luego profundiza en las partes relevantes.
Análisis a realizar:
Clasifica el PR en una sola de estas tres categorías basándote en lo que hacen los cambios:
bug: los cambios arreglan comportamiento incorrecto. Señales: corrección de lógica rota, manejo de casos que antes fallaban o lanzaban excepciones, ajustes de condiciones mal evaluadas, parches a cálculos erróneos, fixes de regresiones.refactor: los cambios no añaden funcionalidad nueva ni arreglan bugs — solo mejoran estructura, legibilidad, organización o rendimiento del código sin cambiar comportamiento observable. Señales: extracción de funciones, renombrado, reorganización de archivos, simplificación de lógica equivalente, eliminación de duplicación.feature: todo lo demás. Funcionalidad nueva, extensiones de comportamiento, nuevas pantallas/endpoints/componentes, mejoras visibles.Si el PR mezcla varios tipos, elige el que mejor represente el trabajo principal del PR. La descripción (no el prefijo) puede aclarar los matices.
Agrupa los cambios por intención. Pregúntate: ¿todos los cambios sirven a un único objetivo coherente, o hay grupos de cambios que podrían describirse como tareas independientes?
Ejemplos:
Si es una sola tarea → descripción en prosa (párrafos). Si son varias tareas → descripción en viñetas, un punto por tarea.
El criterio rector: ¿vería el usuario/reviewer algo nuevo o distinto que le podría extrañar al abrir la app?
Sí amerita sugerir screenshots cuando:
NO amerita screenshot cuando:
aria-*, data-*, id, className sin impacto visual).El umbral no es cuantitativo (líneas cambiadas) sino cualitativo. Un refactor de estilos que no altera la apariencia final no amerita screenshot aunque toque 200 líneas; una sección nueva sí lo amerita aunque sean 40 líneas.
Estructura del título:
<prefijo>: <resumen conciso en inglés>
Prefijo:
<tipo>/TXW-<ticket-id>
<tipo> es feature, bug o refactor según el Paso 4.1.feature/TXW-1234, bug/TXW-999, refactor/TXW-5678.hotfix-login, update-readme.Resumen:
Ejemplos de título completo:
feature/TXW-1234: Add CSV export to user reportsbug/TXW-999: Fix session expiration not redirecting to loginrefactor/TXW-5678: Extract payment validation into dedicated servicehotfix-login: Prevent null reference on empty credentialsTodo en inglés. Basado exclusivamente en los cambios del diff.
Descripción en prosa (uno o dos párrafos breves). Explica:
No uses viñetas en este caso.
Ejemplo:
Adds a CSV export option to the user reports page. Users can now
download filtered report data directly from the toolbar, bypassing
the need to copy rows manually.
The export respects the active filters and date range, and is
generated server-side to handle large datasets without blocking
the UI.
Descripción en viñetas, un punto por tarea. Cada punto debe ser autocontenido y describir esa tarea completa.
Ejemplo:
- Fix session expiration not redirecting to the login page when the
refresh token is invalid.
- Add an export button to the reports toolbar that downloads the
current view as CSV.
- Update the Spanish translation for the "Pending approval" label.
Si en el Paso 4.3 se determinó que hay cambios significativos en UI, añade al final de la descripción (después de la prosa o las viñetas) una línea separadora y una nota breve:
---
**Screenshots:** please attach screenshots of the updated [sección/pantalla afectada] so reviewers can verify the visual changes.
Reemplaza [sección/pantalla afectada] con una mención específica a lo que cambió visualmente (ej: "reports page", "new settings modal", "sidebar navigation").
Si no hay cambios significativos en UI, no se añade esta sección.
Presenta título y descripción en el chat, en un formato claro y fácil de copiar. Usa bloques de código para cada uno, separando título de descripción:
**Title:**
` ` `
<título generado>
` ` `
**Description:**
` ` `
<descripción generada>
` ` `
(Sin espacios entre los backticks — aquí se muestran así solo para documentación.)
No agregues comentarios extra ni explicaciones del análisis, a menos que el usuario pregunte. El output debe ser directo y copy-paste ready.
Después de presentar el output, borra el archivo temporal:
rm -f "$TMP_DIFF"
La línea agregada a .git/info/exclude no hace falta revertirla: apunta a un archivo que ya no existe y no afecta el comportamiento de git. Si se ejecuta la skill de nuevo, el grep -qxF ... || echo ... del Paso 3 evita duplicar la entrada.
git branch --show-current falla): informa al usuario que la skill debe ejecutarse dentro de un repositorio.master: informa al usuario. Esta skill asume que master es la rama base del proyecto.master: informa al usuario que no tiene sentido generar una descripción de PR sobre la rama base.feature/bug/refactor) lo decide el análisis del diff, no el nombre de la rama.