| name | skill-notice |
| description | Redacta en pantalla (sin crear ningún archivo) un texto en formato markdown, listo para copiar y pegar, que explica las novedades, mejoras y correcciones de un plugin o proyecto de FacturaScripts a partir de un rango de commits o de versiones. Activa esta skill siempre que el usuario pida "redacta las novedades", "escribe la noticia de los cambios", "genera el changelog", "qué ha cambiado desde la versión X", "resume los cambios entre la versión X y la Y", "prepara el anuncio de la nueva versión", o cualquier variación en la que se pida comunicar qué se ha hecho en un rango de commits o entre dos versiones.
|
Noticia de cambios (changelog) — Buenas prácticas
El objetivo de esta skill es redactar un texto claro y atractivo que comunique a usuarios y clientes
qué hay de nuevo en una versión: nuevas funcionalidades, mejoras y correcciones de errores. El
texto está pensado para publicarse (en la forja de FacturaScripts, en un changelog, en una nota de
lanzamiento o en redes), por lo que debe ser comprensible para quien usa el ERP, no solo para quien
programa.
Reglas fundamentales
- No crees ningún archivo. El resultado se muestra directamente en el chat, dentro de un
bloque de código markdown, para que el usuario lo copie y lo pegue donde quiera. Nunca escribas
el texto en un fichero del proyecto salvo que el usuario lo pida explícitamente.
- Acota el rango. El usuario indicará el alcance de los cambios, normalmente de una de estas
formas:
- Por versiones: "desde la versión 1.1.0 hasta la 1.2.0".
- Por commits: "desde el commit
abc123 hasta HEAD".
- Por referencia temporal: "los cambios de la última semana", "desde el último release".
Si no indica rango, pregúntale desde qué versión/commit hasta cuál quiere la noticia.
- Redacta orientado al usuario, no al desarrollador. Traduce los cambios técnicos a beneficios
y comportamientos visibles. Por ejemplo, en lugar de "refactor del Calculator", escribe "los
totales de las facturas ahora se recalculan correctamente al cambiar la serie".
Flujo de trabajo
Cuando el usuario pida la noticia de cambios, sigue este orden:
-
Determina el rango de commits. Según lo que indique el usuario:
- Entre dos versiones (si están etiquetadas como tags de git):
git log v1.1.0..v1.2.0 --pretty=format:"%h %s" --no-merges
- Entre dos commits:
git log abc123..def456 --pretty=format:"%h %s" --no-merges
- Desde el último tag hasta ahora:
git log $(git describe --tags --abbrev=0)..HEAD --pretty=format:"%h %s" --no-merges
- Por fecha:
git log --since="2026-06-01" --pretty=format:"%h %s" --no-merges
Si las versiones que da el usuario no son tags de git (por ejemplo, solo aparecen en el
facturascripts.ini del plugin), localiza los commits donde se actualizó el número de versión
en ese archivo y usa esos commits como límites del rango.
-
Revisa el contenido de los commits, no solo los títulos. Cuando un título no sea claro, mira
el cuerpo del commit o el diff (git show <hash>) para entender qué cambió de verdad.
-
Clasifica cada cambio en una de estas categorías (omite las categorías que queden vacías):
- 🚀 Novedades: nuevas funcionalidades o características (commits
feat).
- ✨ Mejoras: optimizaciones, cambios de comportamiento, rendimiento, refactors visibles
(commits
perf, refactor, y feat menores).
- 🐛 Correcciones: errores resueltos (commits
fix).
- 🔧 Otros / mantenimiento: solo si es relevante para el usuario (dependencias, compatibilidad,
documentación destacada). Ignora
chore, style y test puramente internos.
-
Filtra el ruido. No incluyas commits irrelevantes para quien usa el ERP: ajustes de estilo de
código, cambios en tests, merges, retoques internos sin efecto visible. Agrupa cambios repetidos
o relacionados en una sola línea.
-
Redacta el texto en español, en pasado o presente impersonal, con frases breves. Cada punto
empieza en mayúscula, sin punto final, en lenguaje cercano.
-
Muestra el resultado en pantalla dentro de un bloque de código markdown para que se copie tal
cual.
Formato de salida
Devuelve siempre la noticia dentro de un bloque de código markdown como este (adáptalo al nombre del
plugin y a la versión):
## NombreDelPlugin 1.2.0
### 🚀 Novedades
- Nuevo informe de antigüedad de cobros con prioridades de seguimiento
- Posibilidad de filtrar las facturas por fecha de pago
### ✨ Mejoras
- Los totales de los documentos se recalculan automáticamente al cambiar la serie
- Carga más rápida del listado de productos con muchas variantes
### 🐛 Correcciones
- Corregido el cálculo del IVA en el informe trimestral
- Solucionado un error que impedía guardar clientes sin email
Notas sobre el formato
- Usa el nombre real del plugin y el número de versión de destino en el encabezado. Si la
noticia abarca varias versiones, puedes poner un rango (
## NombrePlugin 1.1.0 → 1.2.0) o una
sección por versión.
- Mantén solo las categorías que tengan contenido.
- Si el rango no tiene cambios relevantes para el usuario, indícalo claramente en lugar de inventar
puntos.
- Si el usuario quiere un tono más comercial (para un anuncio) o más escueto (para un changelog
técnico), ajústalo manteniendo siempre la salida en un bloque de código markdown copiable.
