Generador de Notas de Versión
Convierte automáticamente los tickets cerrados de un sprint en notas de versión pulidas y orientadas al usuario.
Escribir notas de versión a partir de tickets en bruto es tedioso: hay que filtrar el trabajo interno, traducir la jerga de los ingenieros al lenguaje del usuario y dar formato de manera consistente. Este skill lo hace todo.
Plantilla de Prompt
/schedule
### Paso 1 — Recopilar tickets completados
Revisa {{TICKET_SOURCES}} en busca de elementos marcados como hechos, enviados, fusionados o cerrados en los últimos {{TIME_WINDOW}}.
Omitir: en progreso, solo internos, correcciones de errores puros sin cambio UX visible, tareas, refactorizaciones,
cualquier cosa etiquetada como "interno", "infra" u "ops".
### Paso 2 — Agrupar por área de producto
Usa las etiquetas de los tickets o los nombres de los proyectos. Fusiona áreas con menos de 2 elementos en el grupo más cercano.
### Paso 3 — Escribir las notas de versión
Para cada área:
**[Etiqueta de Área]**
**[Título]** — 2 a 5 palabras, en tiempo presente, nombre de la funcionalidad, no un mensaje de commit.
Bueno: "Búsqueda más rápida", "Nuevo panel de facturación". Nunca: "añadido", "corregido", "enviado".
[Descripción] — 1 a 3 oraciones dirigidas al usuario. Empieza con qué cambió y por qué es importante.
Usa la estructura "ahora puedes…". Sin viñetas. Sin IDs de tickets, nombres de sprint o nombres de ingenieros.
### Paso 4 — Guardar
Fecha al inicio: Mes DD, AAAA. Entradas agrupadas por área.
Guarda como ReleaseNotes_AAAA-MM-DD.docx en {{OUTPUT_FOLDER}}.
No publiques — guarda solo para revisión. Si no se encuentran tickets, indica qué fuentes revisaste.
Configuración
| Campo | Valor |
|---|---|
| MCPs requeridos | Linear / Jira / GitHub Issues, Google Drive |
| Salida | ReleaseNotes_AAAA-MM-DD.docx → /Producto/NotasDeVersion |
| Programación | Manual antes de cada lanzamiento, o semanal |
Placeholders para completar
{{TICKET_SOURCES}}— ej.Linear,JiraoGitHub Issues{{TIME_WINDOW}}— ej.los últimos 7 días,las últimas 2 semanasoeste sprint{{OUTPUT_FOLDER}}— ej./Producto/NotasDeVersion
Consejos
- Una buena higiene de tickets = mejores notas de versión. Las descripciones que dicen "los usuarios ahora pueden…" producen el mejor resultado.
- Combínalo con
actualizar-base-de-conocimientopara marcar qué artículos de ayuda necesitan actualización después de cada lanzamiento. - Para cambios en API/webhooks, mantén esos tickets con una etiqueta separada: el skill les dará un tono técnico distintivo.