Hogar

Skill

Documentación

release-notes

phuryn/pm-skills

Convierte los tickets técnicos, los documentos de requisitos de producto (PRD) o los registros de cambios en notas de lanzamiento bien elaboradas y dirigidas a los usuarios, organizadas por categorías.

...Expandir todo

Tiempo actualizado 29 de septiembre de 2026

# markdown # changelog # linear # jira # release notes # product documentation

Generador de notas de lanzamiento

Convierte los tickets técnicos, los documentos de requisitos de producto (PRD) o los registros de cambios internos en notas de lanzamiento pulidas y dirigidas a los usuarios.

Contexto

Estás redactando notas de lanzamiento para $ARGUMENTS.

Si el usuario proporciona archivos (exportaciones de JIRA, tickets de Linear, PRD, registros de Git o registros de cambios internos), léelos primero. Si mencionan una URL del producto, utiliza un buscador web para conocer el producto y el público objetivo.

Instrucciones

Recopila el material en bruto: lee todos los tickets, registros de cambios o descripciones proporcionados. Extrae:
- Qué ha cambiado (funcionalidad, mejora o corrección)
- A quién afecta (qué segmento de usuarios)
- Por qué es importante (el beneficio para el usuario)
Clasifica los cambios:
- Nuevas funciones: Capacidades totalmente nuevas
- Mejoras: optimizaciones de las funciones existentes
- Correcciones de errores: problemas resueltos
- Cambios importantes: cualquier cosa que requiera la intervención del usuario (migraciones, cambios en la API)
- Funcionalidades obsoletas: Funcionalidades que se van a retirar
Redacta cada entrada siguiendo estos principios:
- Empieza por el beneficio para el usuario, no por el cambio técnico
- Utiliza un lenguaje sencillo: evita la jerga, los nombres en clave internos o los números de ticket
- Limita cada entrada a entre 1 y 3 frases
- Incluye imágenes o capturas de pantalla si el usuario las proporciona
Ejemplos de transformaciones:
- Técnicas: «Se ha implementado una capa de almacenamiento en caché Redis para los puntos finales de la API del panel de control»
- Orientado al usuario: «Ahora los paneles de control se cargan hasta tres veces más rápido, por lo que pasarás menos tiempo esperando y más tiempo analizando».
- Técnico: «Se ha corregido una condición de carrera en el flujo de pago simultáneo».
- Para el usuario: «Se ha solucionado un problema por el que algunos pedidos podían fallar durante los periodos de mucho tráfico».

Estructura de las notas de la versión:

# [Nombre del producto] — [Versión / Fecha]

## Nuevas funciones
- **[Nombre de la función]**: [Descripción de 1-2 frases sobre qué hace y por qué es importante]

## Mejoras
- **[Área]**: [Qué ha mejorado y cómo ayuda]

## Correcciones de errores
- Se ha corregido [descripción del problema en términos de usuario]

## Cambios importantes (si los hay)
- **Acción requerida**: [Lo que deben hacer los usuarios]

Adapta el tono para que se ajuste al estilo del producto: profesional para B2B, cercano para el consumidor y orientado a desarrolladores para las API.

Guárdalo como documento Markdown. Si el usuario prefiere HTML u otro formato, conviértelo según corresponda.

Ver en GitHub

---
name: release-notes
description: Transform technical tickets, PRDs, or changelogs into polished, user-facing release notes organized by category.
---

## Release Notes Generator

Transform technical tickets, PRDs, or internal changelogs into polished, user-facing release notes.

### Context

You are writing release notes for **$ARGUMENTS**.

If the user provides files (JIRA exports, Linear tickets, PRDs, Git logs, or internal changelogs), read them first. If they mention a product URL, use web search to understand the product and audience.

### Instructions

1. **Gather raw material**: Read all provided tickets, changelogs, or descriptions. Extract:
   - What changed (feature, improvement, or fix)
   - Who it affects (which user segment)
   - Why it matters (the user benefit)

2. **Categorize changes**:
   - **New Features**: Entirely new capabilities
   - **Improvements**: Enhancements to existing features
   - **Bug Fixes**: Issues resolved
   - **Breaking Changes**: Anything that requires user action (migrations, API changes)
   - **Deprecations**: Features being sunset

3. **Write each entry** following these principles:
   - Lead with the user benefit, not the technical change
   - Use plain language — avoid jargon, internal codenames, or ticket numbers
   - Keep each entry to 1-3 sentences
   - Include visuals or screenshots if the user provides them

   **Example transformations**:
   - Technical: "Implemented Redis caching layer for dashboard API endpoints"
   - User-facing: "Dashboards now load up to 3× faster, so you spend less time waiting and more time analyzing."

   - Technical: "Fixed race condition in concurrent checkout flow"
   - User-facing: "Fixed an issue where some orders could fail during high-traffic periods."

4. **Structure the release notes**:

   ```
   # [Product Name] — [Version / Date]

   ## New Features
   - **[Feature name]**: [1-2 sentence description of what it does and why it matters]

   ## Improvements
   - **[Area]**: [What got better and how it helps]

   ## Bug Fixes
   - Fixed [issue description in user terms]

   ## Breaking Changes (if any)
   - **Action required**: [What users need to do]
   ```

5. **Adjust tone** to match the product's voice — professional for B2B, friendly for consumer, developer-focused for APIs.

Save as a markdown document. If the user wants HTML or another format, convert accordingly.