Générateur de Notes de Version
Transformez automatiquement un sprint de tickets fermés en notes de version soignées et orientées utilisateur.
Rédiger des notes de version à partir de tickets bruts est fastidieux : filtrer le travail interne, traduire le langage des développeurs en langage utilisateur, formater de manière cohérente. Ce skill s'occupe de tout.
Modèle d'invite
/schedule
### Étape 1 — Rassembler les tickets terminés
Vérifiez {{SOURCES_DE_TICKETS}} pour les éléments marqués comme faits, livrés, fusionnés ou fermés au cours des {{FENÊTRE_TEMPS}} derniers.
Ignorer : en cours, internes uniquement, corrections de bugs sans changement UX visible, tâches, refactorisations,
tout ce qui est tagué "internal", "infra" ou "ops".
### Étape 2 — Regrouper par domaine produit
Utilisez les labels des tickets ou les noms de projets. Fusionnez les domaines contenant moins de 2 éléments dans le groupe le plus proche.
### Étape 3 — Rédiger les notes de version
Pour chaque domaine :
**[Tag du domaine]**
**[Titre]** — 2 à 5 mots, au présent, nom de la fonctionnalité, pas un message de commit.
Bon : "Résultats de recherche plus rapides", "Nouveau tableau de bord de facturation". Jamais : "ajouté", "corrigé", "livré".
[Description] — 1 à 3 phrases destinées à l'utilisateur. Commencez par ce qui a changé et pourquoi c'est important.
Utilisez la formulation "vous pouvez maintenant…". Pas de puces. Pas d'ID de ticket, de noms de sprint ou de noms de développeurs.
### Étape 4 — Sauvegarder
Date en haut : Mois JJ, AAAA. Entrées regroupées par domaine.
Enregistrer sous ReleaseNotes_AAAA-MM-JJ.docx dans {{DOSSIER_SORTIE}}.
Ne pas publier — sauvegarder uniquement pour relecture. Si aucun ticket trouvé, indiquez les sources que vous avez consultées.
Configuration
| Champ | Valeur |
|---|---|
| MCP requis | Linear / Jira / GitHub Issues, Google Drive |
| Sortie | ReleaseNotes_AAAA-MM-JJ.docx → /Product/ReleaseNotes |
| Planificateur | Manuel avant chaque mise en production, ou hebdomadaire |
Paramètres à renseigner
{{SOURCES_DE_TICKETS}}— p. ex.Linear,JiraouGitHub Issues{{FENÊTRE_TEMPS}}— p. ex.les 7 derniers jours,les 2 dernières semainesouce sprint{{DOSSIER_SORTIE}}— p. ex./Product/ReleaseNotes
Astuces
- Une bonne hygiène des tickets = de meilleures notes de version. Les descriptions qui disent "les utilisateurs peuvent maintenant…" produisent les meilleurs résultats.
- Associez-le à
update-knowledge-basepour signaler quels articles d'aide doivent être mis à jour après chaque mise en production. - Pour les modifications d'API/webhook, conservez ces tickets dans un label séparé — le skill leur donnera une voix technique distincte.