¿Qué hace notas-de-lanzamiento?
Convierte el historial de Git en notas de lanzamiento que un humano querría leer.
Qué hace
- Diferencia commits entre dos referencias (etiquetas, ramas o
HEAD) - Agrupa cambios por tipo: funcionalidades, correcciones, cambios disruptivos, tareas menores
- Detecta cambios disruptivos a partir de marcadores
!de commits convencionales y pies de páginaBREAKING CHANGE: - Redacta una sección de aspectos destacados (los 3-5 cambios que realmente importan a los usuarios)
- Genera Markdown listo para GitHub Releases
Uso
# Notas para el próximo lanzamiento (última etiqueta -> HEAD)
git log $(git describe --tags --abbrev=0)..HEAD --oneline
# Entre dos etiquetas
git log v1.2.0..v1.3.0 --pretty=format:'%h %s %b'
Luego pídele al agente: "redacta notas de lanzamiento para v1.3.0 a partir de estos commits."
O con GitHub CLI, directamente en un borrador de release:
# Crear la etiqueta, luego redactar notas de lanzamiento a partir del diff
git tag v1.3.0 && git push origin v1.3.0
gh release create v1.3.0 --generate-notes --draft
# luego refina las notas generadas con esta skill
Proceso
1. Recopilar los commits
git log <etiqueta-anterior>..<nueva-etiqueta> --pretty=format:'%h|%s|%b|%an' --no-merges
Incluye los commits de fusión por separado si el repositorio usa un flujo basado en merges; el título de la fusión suele resumir mejor el PR que los commits individuales.
2. Clasificar cada commit
| Prefijo / señal | Sección |
|---|---|
feat, feat! | Funcionalidades |
fix | Correcciones de errores |
! o BREAKING CHANGE: | ⚠️ Cambios disruptivos (también listados en su propia sección) |
perf | Rendimiento |
docs, chore, ci, refactor, test | Agrupados bajo "Otros cambios" u omitidos |
Commits sin prefijos convencionales: clasificar por el contenido del mensaje. Ante la duda, poner en "Otros cambios" en lugar de eliminarlos silenciosamente.
3. Redactar aspectos destacados
Elegir los 3-5 cambios que más importan a los usuarios del software:
- Nuevas capacidades que notarán
- Cambios disruptivos en los que deben actuar
- Correcciones de problemas ampliamente reportados
Redactar cada uno como una oración sencilla. Sin adjetivos de marketing.
4. Escribir las notas
## v1.3.0
**Aspectos destacados**
- ...
- ...
### ⚠️ Cambios disruptivos
- ...
### Funcionalidades
- ...
### Correcciones de errores
- ...
### Otros cambios
- ...
**Changelog completo:** <etiqueta-anterior>...<nueva-etiqueta>
5. Verificaciones antes de publicar
- Cada cambio disruptivo aparece en la sección ⚠️ con una pista de migración
- No hay tareas internas presentadas como cambios para el usuario
- Nombres de colaboradores acreditados si la convención del repositorio lo hace
- El número de versión coincide con la etiqueta
Convenciones
- Seguir el estilo de notas de lanzamiento existente del repositorio si lo tiene: la consistencia supera a cualquier plantilla.
- Si el repositorio usa
gh release --generate-notes, usar su salida como borrador inicial y refinar: obtiene la lista correcta pero los aspectos destacados equivocados. - Nunca inventar cambios que no estén en el rango de commits. Cuando el rango sea ambiguo, preguntar qué referencias comparar en lugar de adivinar.