Menu
Crear releases con versionado semantico, notas y artefactos
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
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
| name | release |
| description | Crear releases con versionado semantico, notas y artefactos |
| disable-model-invocation | true |
Este skill gestiona el proceso completo de creacion de una release en GitHub, desde la determinacion de la version correcta segun versionado semantico hasta la publicacion con notas de cambios y artefactos adjuntos.
Una buena release no es solo un tag en el repositorio: es el punto de comunicacion con los usuarios y el equipo sobre que ha cambiado, que se ha corregido y que deben tener en cuenta al actualizar.
Determinar la version siguiente. Analizar los commits desde la ultima release para decidir el incremento de version segun semver (MAJOR.MINOR.PATCH):
En caso de duda, consultar con el usuario. Un cambio que parece menor puede tener implicaciones de compatibilidad.
Generar el changelog. Revisar los commits y PRs mergeadas desde la ultima release. Clasificar los cambios en las siguientes categorias:
Cada entrada debe ser comprensible para un usuario final, no solo para desarrolladores. Evitar mensajes tipo "refactorizar modulo X"; en su lugar, explicar el efecto visible.
Actualizar ficheros de version. Si el proyecto tiene ficheros que contienen la version (package.json, pyproject.toml, Cargo.toml, version.txt), actualizarlos con el nuevo numero.
Crear el tag. Crear un tag anotado con el formato vMAJOR.MINOR.PATCH:
git tag -a v1.2.0 -m "Release v1.2.0"
git push origin v1.2.0
Crear la release en GitHub. Usar gh release create con las notas generadas:
gh release create v1.2.0 --title "v1.2.0" --notes-file RELEASE_NOTES.md
Si hay artefactos que adjuntar (binarios compilados, paquetes, ficheros de distribucion), incluirlos como assets de la release.
Adjuntar artefactos si procede. Para proyectos que generan binarios o paquetes distribuibles:
gh release upload v1.2.0 dist/app-linux-amd64 dist/app-darwin-arm64
Verificar que los artefactos son accesibles y descargables desde la pagina de la release.
Verificar la release. Comprobar que la release aparece correctamente en GitHub, que las notas se renderizan bien, que los artefactos estan disponibles y que el tag apunta al commit correcto.