Menu
Crear pull requests completas con descripcion, labels y reviewers
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Alias global /alfred para abrir el asistente contextual de Alfred Dev sin escribir el namespace completo. Activar solo cuando el usuario invoque explicitamente /alfred.
Protocolo de respuesta ante incidentes en produccion: triaje, mitigacion, causa raiz y postmortem. Usar ante caidas, errores criticos, incidentes de seguridad o degradacion de servicio.
Usar para refactorizar código con tests como red de seguridad. Activar cuando el usuario quiera limpiar código, reducir complejidad, extraer función, mejorar nombres, eliminar duplicación, resolver un code smell o reorganizar la estructura interna sin cambiar comportamiento.
Generar Dockerfile optimizado. Activar cuando el usuario quiera crear contenedor, generar imagen Docker, configurar Docker Compose, contenerizar aplicacion o crear un Dockerfile multi-stage.
Planificar y ejecutar releases: inventario de cambios, versionado semantico, changelog, notas de release y publicacion. Usar antes de cada version nueva.
Auditar accesibilidad WCAG 2.1 nivel AA con checklist y correcciones. Activar ante: accesibilidad web, WCAG, lector de pantalla, contraste, navegacion por teclado, a11y
Based on SOC occupation classification
| name | pr-workflow |
| description | Crear pull requests completas con descripcion, labels y reviewers |
| disable-model-invocation | true |
Este skill guia el proceso de creacion de una pull request bien documentada, desde la verificacion de cambios hasta la asignacion de reviewers. Una PR no es solo un mecanismo de merge: es una pieza de comunicacion que explica a los revisores que se ha cambiado, por que y como verificarlo.
El objetivo es que cualquier miembro del equipo pueda entender la PR sin necesidad de leer cada linea de codigo antes de abrir el diff.
Verificar el estado de los cambios. Ejecutar git diff y git status para confirmar que los cambios pendientes corresponden a lo que se quiere incluir en la PR. Si hay cambios sin commitear, confirmar con el usuario si deben incluirse o quedarse fuera.
Verificar la rama. Asegurarse de que se trabaja en una rama feature o fix, no directamente en main. Si no existe rama, crearla con un nombre descriptivo: feature/nombre-funcionalidad o fix/descripcion-bug.
Redactar el titulo. El titulo debe tener menos de 70 caracteres y describir el cambio de forma clara. Formato recomendado: tipo: descripcion breve. Ejemplos:
feat: anadir filtro de busqueda por fechafix: corregir calculo de IVA en facturasrefactor: extraer logica de validacion a modulo propioRedactar la descripcion. Seguir esta estructura estandarizada:
## Resumen
- [1-3 puntos explicando que cambia y por que]
## Motivacion
[Por que es necesario este cambio. Enlazar al issue si existe.]
## Plan de pruebas
- [ ] [Pasos concretos para verificar que el cambio funciona]
- [ ] [Comprobaciones de regresion]
## Notas para el revisor
[Contexto adicional, decisiones de diseno, areas que necesitan atencion especial]
Asignar labels. Etiquetar la PR segun el tipo de cambio (bug, feature, refactor, docs) y la prioridad si aplica. Usar gh pr edit --add-label para asignarlas.
Enlazar issues. Si la PR resuelve un issue, incluir Closes #XX en la descripcion para que GitHub lo cierre automaticamente al hacer merge.
Asignar reviewers. Seleccionar revisores relevantes segun el area del codigo afectada. Usar gh pr create --reviewer usuario1,usuario2 o gh pr edit --add-reviewer si la PR ya existe.
Crear la PR. Ejecutar gh pr create con titulo, descripcion, labels y reviewers. Verificar que la PR aparece correctamente en GitHub y que los checks de CI arrancan.
Revisar el resultado. Comprobar que la descripcion se renderiza bien, que los enlaces a issues funcionan y que los reviewers han sido notificados.
Co-Authored-By ni menciones a asistentes o herramientas de IA en la PR.