# Pr Description > Genera descripciones de PR detalladas basadas en los cambios del branch actual. Usar cuando se cree un PR, se escriba un PR, o el usuario pida resumir cambios para un pull request. - Skill: `phoebe-wd/pr-description` (Agent Skill) - Install (CLI): `npx skillmds@latest add phoebe-wd/pr-description` - Raw SKILL.md: https://api.skillmd.com/api/skills/phoebe-wd/pr-description/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: Phoebe-WD (https://skillmd.com/u/phoebe-wd) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/phoebe-wd/pr-description --- ## Flujo de ramas del equipo El equipo usa el siguiente modelo de branching: - **feature/***: Ramas creadas desde `develop` o `main/master`. Agrupan varios PBIs relacionados. - **pbi/***: Ramas creadas desde la rama `feature` correspondiente. El PR va de `pbi → feature`. - Si hay varios PBIs en un feature, se mergea el primero y los siguientes PBIs se basan en el feature actualizado. - **bug/*, hotfix/***: Van directo a `main/master/develop`. ## Pasos Al escribir una descripción de PR: 1. Ejecutar `git branch --show-current` para obtener el nombre del branch actual. 2. **Preguntar al usuario:** a. **Plataforma del PR:** ¿Azure DevOps o GitHub? - Si es Azure DevOps: la descripción tiene un **límite de 4000 caracteres**. Ser conciso. - Si es GitHub: sin límite de caracteres. Se puede ser más detallado. b. **Rama base** contra la cual se compararán los cambios. Sugerir la más probable: - Si el branch actual es `pbi/*` → sugerir la rama `feature/*` correspondiente. - Si el branch actual es `feature/*` → sugerir `develop` o `main/master`. - Si el branch actual es `bug/*` o `hotfix/*` → sugerir `main/master/develop`. - Dejar que el usuario confirme o cambie la sugerencia. c. **¿Hay cambios de UI/frontend?** Si sí, pedir al usuario que proporcione screenshots. - En GitHub: se embeben directamente en la descripción con `![descripcion](url)`. - En Azure DevOps: mencionar que se adjuntarán como archivos al PR o incluir como link. 3. Ejecutar `git log --oneline [rama-base]..HEAD` para ver todos los commits del branch. 4. **Si el PR es de feature → develop/main/master** (PR agregado): - Ejecutar `git log --oneline --merges [rama-base]..HEAD` para identificar los merge commits de PBIs. - Ejecutar `git log --oneline [rama-base]..HEAD | grep -iE "pbi|merge"` para extraer los PBIs incluidos. - Listar todos los PBIs/branches que se mergearon en el feature. 5. Ejecutar `git diff [rama-base]...HEAD --stat` para ver el resumen de archivos cambiados. 6. Ejecutar `git diff [rama-base]...HEAD` para ver todos los cambios en detalle. 7. Identificar el número de PBI/ticket del nombre del branch (si existe). 8. **Detectar si hay endpoints nuevos o modificados** (buscar en el diff controllers, rutas HTTP, `[HttpPost]`, `[HttpGet]`, etc.). Si los hay, documentarlos en la sección de Endpoints. ## Formato de salida Generar primero el **título del PR** y luego la descripción, siguiendo este template: ```markdown **Título del PR:** [Título corto y descriptivo, máximo 70 caracteres, en español] # Resumen [1-2 oraciones describiendo el alcance completo del cambio. Ser específico sobre qué se implementó.] --- ## Endpoints ### [N]. [Nombre descriptivo] `[MÉTODO] [ruta/del/endpoint]` -- descripción breve de qué hace. Stack: `FilterVM` -> `Business` -> `Controller`. [Breve explicación del flujo interno: qué datos obtiene, qué valida, qué retorna.] **Request:** \```json { "Campo1": valor_ejemplo, "Campo2": "valor_ejemplo" } \``` | Campo | Tipo | Requerido | Descripción | |-------|------|-----------|-------------| | Campo1 | long | Sí | Descripción del campo | | Campo2 | string | No | Descripción del campo | **Response:** \```json [ { "Propiedad1": "valor_ejemplo", "Propiedad2": 123 } ] \``` --- ## Funcionalidades implementadas ### 1. [Nombre de la funcionalidad] - Detalle específico del comportamiento implementado - Componentes o módulos involucrados - Lógica relevante (cascadas, validaciones, cálculos, etc.) ### 2. [Siguiente funcionalidad] - ... --- ## Cambios de UI [Screenshots proporcionados por el usuario. En GitHub embeber con ![descripcion](url). En Azure DevOps indicar que están adjuntos al PR.] --- ## Archivos modificados - **[Capa/Área]** ([cantidad]): breve descripción del tipo de cambios (ej: "Business (3): nueva lógica de cálculo de bonos") - **[Capa/Área]** ([cantidad]): ... - **Archivos nuevos:** [cantidad] | **Archivos modificados:** [cantidad] --- ## Deuda técnica conocida | Item | Estado | Notas | |------|--------|-------| | [Descripción del item] | [PENDIENTE/BLOQUEADO/EN PROGRESO] | [Contexto adicional] | ``` ### Template para PR agregado (feature → develop/main/master) Cuando el PR es de un feature hacia develop/main/master, usar este template en su lugar: ```markdown **Título del PR:** [Título corto y descriptivo, máximo 70 caracteres, en español] # Resumen [1-2 oraciones describiendo el alcance completo del feature. Ser específico sobre qué se implementó en conjunto.] --- ## PBIs incluidos | PBI | PR | Descripción | |-----|-----|-------------| | #[número] | PR [número] | Breve descripción de lo que implementó ese PBI | | #[número] | PR [número] | ... | --- ## Endpoints ### [N]. [Nombre descriptivo] `[MÉTODO] [ruta/del/endpoint]` -- descripción breve de qué hace. Stack: `FilterVM` -> `Business` -> `Controller`. [Breve explicación del flujo interno.] **Request:** \```json { "Campo1": valor_ejemplo, "Campo2": "valor_ejemplo" } \``` | Campo | Tipo | Requerido | Descripción | |-------|------|-----------|-------------| | Campo1 | long | Sí | Descripción del campo | **Response:** \```json [ { "Propiedad1": "valor_ejemplo", "Propiedad2": 123 } ] \``` --- ## Funcionalidades implementadas ### 1. [Nombre de la funcionalidad] - Detalle específico del comportamiento implementado - Componentes o módulos involucrados - Lógica relevante (cascadas, validaciones, cálculos, etc.) ### 2. [Siguiente funcionalidad] - ... --- ## Cambios de UI [Screenshots proporcionados por el usuario] --- ## Archivos modificados - **[Capa/Área]** ([cantidad]): breve descripción - **Archivos nuevos:** [cantidad] | **Archivos modificados:** [cantidad] --- ## Deuda técnica conocida | Item | Estado | Notas | |------|--------|-------| | [Descripción del item] | [PENDIENTE/BLOQUEADO/EN PROGRESO] | [Contexto adicional] | ``` ## Reglas - **SIEMPRE** generar el título del PR antes de la descripción. El título debe ser corto (máximo 70 caracteres), descriptivo y en español. - Si no hay endpoints nuevos/modificados, omitir la sección "Endpoints" - Si no hay cambios de UI, omitir la sección "Cambios de UI" - Si no hay deuda técnica, omitir esa sección - Agrupar las funcionalidades por área lógica (filtros, UI, backend, etc.) - El idioma de la descripción debe ser español - Si hay archivos de recursos/localización modificados, agruparlos (ej: `SharedResource.*.resx (x4)`) - **Azure DevOps:** La descripción tiene un límite de **4000 caracteres**. Si la descripción excede este límite, comprimir las secciones menos críticas (archivos modificados, deuda técnica). Si aún no cabe, mover los detalles de endpoints a un comentario separado del PR. - **GitHub:** Sin límite de caracteres. Se puede ser más detallado en todas las secciones. - **Archivos modificados:** NO listar cada archivo individual en una tabla. Agrupar por capa/área con cantidad y descripción breve del tipo de cambio. Esto ahorra espacio significativo. - **Endpoints:** Usar JSON de ejemplo con valores realistas, no genéricos. Los valores deben reflejar el dominio del proyecto. ## Formato de entrega - **IMPORTANTE**: La descripción generada DEBE guardarse en un archivo markdown (`.md`) en el directorio raíz del repositorio con el nombre `pr-description.md`. Esto permite al usuario abrir el archivo y copiar el contenido sin problemas de formato. - Usar la herramienta Write para crear el archivo con el contenido completo de la descripción. - Después de crear el archivo, indicar al usuario: "Descripción del PR guardada en `pr-description.md`. Puedes copiar el contenido desde ahí." - El archivo `pr-description.md` NO debe commitearse. Si existe un `.gitignore`, agregar `pr-description.md` si no está incluido. - No incluir explicaciones adicionales después de crear el archivo a menos que el usuario lo pida.