From alfred-dev
Guides creating complete GitHub pull requests with git status checks, descriptive titles, structured markdown descriptions, labels, issue links, and reviewers using gh CLI. Useful for team code reviews.
npx claudepluginhub 686f6c61/alfred-dev --plugin alfred-devThis skill uses the workspace's default tool permissions.
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.
Creates GitHub pull requests from branch changes using git analysis and gh CLI, with conventional commit titles and standardized templated descriptions including summary, changes, testing, and checklists.
Creates GitHub pull requests from conversation context and git changes with standardized markdown formatting, testing notes, related issues, and tags from docs/git-msg-tags.md.
Creates GitHub pull requests with formatted descriptions, labels, issue references, draft mode, reviewers, and base branch selection from pushed branches. Use for 'create PR' or 'submit for review'.
Share bugs, ideas, or general feedback.
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.