gabrielmoreira Skill Generador de Changelog
Convierte commits git sin procesar, un resumen de diff o notas de versión de desarrolladores en una entrada de changelog pulida — categorizada, orientada al usuario y siguiendo las convenciones de Keep a Changelog.
Entradas Requeridas
Solicita estas si no se proporcionan:
- Commits o notas de versión (pega
git log --oneline, mensajes de commit sin procesar, o una descripción de qué cambió) - Número de versión (ej. 2.4.0, v1.0.0-beta.2)
- Fecha de lanzamiento (o "hoy")
- Audiencia (desarrolladores usando una API / usuarios finales de un producto / equipo interno — afecta el lenguaje)
- Cambios disruptivos (marca estos explícitamente si se conocen)
- Comportamiento de versión anterior (opcional — pega la entrada anterior del changelog o describe qué está cambiando; necesario para entradas "Changed" precisas)
- Alcance (producto completo / paquete específico o módulo — ej. "solo SDK de pagos", "app iOS", "todos los servicios")
Formato de Salida
Sigue el formato de Keep a Changelog:
[X.Y.Z] — YYYY-MM-DD
Cambios Disruptivos ⚠️
[Solo incluye si hay cambios disruptivos]
- [Cambio disruptivo]: [Qué cambió y qué rompe]
- Migración requerida: [Acción específica que el usuario debe tomar]
Agregado
- [Nueva característica o capacidad, escrita desde la perspectiva del usuario]
- [Otra adición]
Cambiado
- [Comportamiento cambiado — qué hacía antes vs. qué hace ahora]
- [Mejora de rendimiento con impacto medible si se conoce]
Corregido
- [Bug corregido — describe qué estaba roto, no la implementación de la corrección]
- [Otra corrección]
Deprecado
- [Cosa deprecada] — usa [reemplazo] en su lugar. Será removida en [versión].
Removido
- [Cosa removida] — fue deprecada en [versión]
Seguridad
- [Corrección de seguridad — describe la clase de vulnerabilidad, no detalles de exploit]
Orientación del skill — no incluyas la siguiente sección en el changelog entregado:
Reglas de Formato Aplicadas
Lenguaje: Escribe para el lector, no para quien hizo el commit. "Agregar soporte de modo oscuro" no "implementar ThemeProvider con variante de paleta oscura".
Cambios disruptivos: Siempre llama la atención sobre estos primero con ⚠️. Incluye una ruta de migración.
Correcciones de bugs: Describe qué estaba roto, no qué fue cambiado. "Corregir crash cuando el usuario no tiene foto de perfil" no "verificar nulidad de URL de avatar antes de renderizar".
Granularidad: Agrupa commits relacionados en una línea. No lijes cada micro-commit por separado.
Tono: Voz activa, modo imperativo. "Agregar", "Corregir", "Remover" — no "Agregado", "Corregido", "Removido".
Secciones vacías: Omite cualquier sección sin entradas. No incluyas bloques vacíos de ### Corregido.
Verificaciones de Calidad
- Los cambios disruptivos están al inicio con instrucciones de migración
- Todas las entradas están en lenguaje orientado al usuario (sin nombres de variables internas o detalles de implementación)
- Los commits relacionados están agrupados en entradas únicas (no listados individualmente)
- El encabezado de versión y fecha es correcto
- Las secciones vacías están omitidas
- Ninguna entrada comienza con verbos en pasado (no "Agregado", "Corregido", "Removido" — usa "Agregar", "Corregir", "Remover")
- Toda entrada de cambio disruptivo incluye una acción de migración específica (no solo "actualiza tu código")
Anti-Patrones
- No incluyas detalles de implementación en entradas del changelog — los usuarios necesitan saber qué cambió para ellos, no cómo fue refactorizado el código internamente
- No listes cada micro-commit como una entrada separada — los commits relacionados deben agruparse en un cambio único orientado al usuario
- No omitas la ruta de migración para cambios disruptivos — una entrada de cambio disruptivo sin una acción de migración específica obliga a los usuarios a leer el código fuente
- No incluyas secciones vacías — una sección "### Corregido" sin entradas señala que la plantilla fue rellenada descuidadamente
- No escribas cambios disruptivos con el mismo tono casual que adiciones menores — los cambios disruptivos deben ser visualmente prominentes y aclarar explícitamente los requisitos de migración
Ejemplos de Uso
- "Escribe un changelog para la versión [X]" + [pega commits]
- "Genera notas de versión a partir de estos commits"
- "Convierte este git log en una entrada de CHANGELOG"
- "Escribe la actualización de CHANGELOG.md para este lanzamiento"
- "¿Qué cambió en este lanzamiento?" + [pega lista de commits]