Maison

Skill

Documentation

release-notes

phuryn/pm-skills

Transformez les tickets techniques, les spécifications produit (PRD) ou les journaux de modifications en notes de mise à jour soignées, destinées aux utilisateurs et classées par catégorie.

...Développer tout

Heure mise à jour 29 septembre 2026

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

Générateur de notes de mise à jour

Transformez vos tickets techniques, vos spécifications de produit (PRD) ou vos journaux de modifications internes en notes de mise à jour soignées et destinées aux utilisateurs.

Contexte

Vous rédigez des notes de mise à jour pour $ARGUMENTS.

Si l'utilisateur fournit des fichiers (exportations JIRA, tickets Linear, cahiers des charges, journaux Git ou journaux de modifications internes), consultez-les d'abord. S'ils mentionnent l'URL d'un produit, effectuez une recherche sur Internet pour comprendre le produit et son public cible.

Instructions

Rassemblez les informations brutes: lisez tous les tickets, journaux de modifications ou descriptions fournis. Extrayez :
- Ce qui a changé (fonctionnalité, amélioration ou correction)
- Qui est concerné (quel segment d’utilisateurs)
- Pourquoi c'est important (l'avantage pour l'utilisateur)
Classez les changements par catégorie:
- Nouvelles fonctionnalités: des capacités entièrement nouvelles
- Améliorations: optimisations des fonctionnalités existantes
- Corrections de bogues: problèmes résolus
- Changements majeurs: tout ce qui nécessite une action de la part de l'utilisateur (migrations, modifications de l'API)
- Fonctionnalités obsolètes: fonctionnalités en voie de suppression
Rédigez chaque entrée en respectant ces principes :
- Commencez par présenter l'avantage pour l'utilisateur, et non le changement technique
- Utilisez un langage simple — évitez le jargon, les noms de code internes ou les numéros de ticket
- Limitez chaque entrée à 1 à 3 phrases
- Ajoutez des illustrations ou des captures d’écran si l’utilisateur en fournit
Exemples de reformulations:
- Technique : « Mise en place d’une couche de mise en cache Redis pour les points de terminaison de l’API du tableau de bord »
- Pour l'utilisateur : « Les tableaux de bord se chargent désormais jusqu’à trois fois plus vite : vous passez ainsi moins de temps à attendre et plus de temps à analyser. »
- Technique : « Correction d'une condition de concurrence dans le processus de paiement simultané »
- Pour l'utilisateur : « Correction d'un problème pouvant entraîner l'échec de certaines commandes pendant les périodes de fort trafic. »

Structure des notes de mise à jour:

# [Nom du produit] — [Version / Date]

## Nouvelles fonctionnalités
- **[Nom de la fonctionnalité]** : [Description en 1 à 2 phrases de son fonctionnement et de son intérêt]

## Améliorations
- **[Domaine]** : [Ce qui a été amélioré et en quoi cela aide]

## Corrections de bogues
- Correction de [description du problème en termes simples]

## Changements majeurs (le cas échéant)
- **Action requise** : [Ce que les utilisateurs doivent faire]

Adaptez le ton à celui du produit : professionnel pour le B2B, convivial pour les particuliers, axé sur les développeurs pour les API.

Enregistrez le document au format Markdown. Si l’utilisateur souhaite un fichier HTML ou un autre format, convertissez-le en conséquence.

Voir sur 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.