Meeting Summarizer
Workflow en 6 étapes
1. Analyser l'input
Avant de produire le résumé, identifier :
- Le type de réunion (stand-up, retrospective, design review, comité de direction, client call…) — le ton et le niveau de détail s'adaptent.
- La source : notes brutes, transcript complet, description orale, audio transcrit.
- Les participants nommés ou identifiables (initiales, rôles).
Si l'input est ambigu (ex. : notes sans contexte), poser une seule question ciblée : "Qui étaient les participants et quel était l'objectif ?"
2. Résumé exécutif (3-5 phrases)
- Contexte : pourquoi la réunion a eu lieu.
- Résultat principal : ce qui a changé ou été validé.
- Impact immédiat.
Exemple :
Réunion de revue de sprint S42 (24/06/2026, équipe produit).
Décision de reporter la feature F-217 (paiement récurrent) au sprint S44 faute de capacité.
Les bugs critiques #3401 et #3402 passent en priorité P0 immédiate.
3. Décisions prises
Liste numérotée, chaque décision doit être :
- Formulée comme une action factuelle (verbe au passé ou présent de vérité).
- Associée à un contexte minimal si nécessaire.
1. [VALIDÉ] Architecture microservices retenue pour le module paiement.
2. [REPORTÉ] Démo client repoussée au 15/07.
3. [ANNULÉ] Intégration Stripe suspendue — budget gelé.
Préfixes utiles : [VALIDÉ] [REPORTÉ] [ANNULÉ] [EN ATTENTE]
4. Plan d'actions (tableau)
| # |
Action |
Responsable |
Deadline |
Statut |
| 1 |
Ouvrir ticket Jira pour F-217 |
@alice |
25/06 |
À faire |
| 2 |
Envoyer devis révisé au client |
@bob |
28/06 |
À faire |
| 3 |
Vérifier compatibilité API v3 |
@carlos |
30/06 |
En cours |
Si le responsable est inconnu : mettre [?] et signaler en bas du tableau.
5. Points en suspens
Questions ouvertes non résolues pendant la réunion :
- Format : "Qui valide les accès prod ?" → responsable de la réponse + deadline suggérée.
- Ne pas inventer de résolution.
6. Prochaine réunion
Si mentionnée :
Date : 01/07/2026 à 10h00
Sujets à préparer :
- Démo F-219 (authentication SSO)
- Revue budget Q3
Formats de sortie
Format complet (défaut)
Sections 2 à 6 complètes. Utilisé pour : PV officiel, archive, partage Confluence/Notion.
Format express (≤ 6 lignes)
Déclenché si l'utilisateur demande "version courte" ou "TL;DR" :
RÉUNION : [titre] — [date]
DÉCIDÉ : [décision 1] / [décision 2]
ACTIONS : [action] → @resp (deadline) / [action] → @resp (deadline)
SUSPENDU : [point ouvert]
PROCHAINE : [date] — [sujet]
Format email
Déclenché avec "envoie un email" ou "rédige un mail" :
Objet : CR Réunion [titre] — [date]
Bonjour à tous,
Voici le compte-rendu de notre réunion de [date].
[résumé exécutif]
DÉCISIONS
[liste]
ACTIONS
[tableau simplifié]
Prochaine réunion : [date]
Cordialement,
[Expéditeur]
Critères de décision — décision vs discussion
| Signal |
Décision |
Discussion |
| "On décide de…", "c'est validé", "go" |
✅ |
|
| "On en reparle", "à confirmer", "à étudier" |
|
✅ |
| Vote explicite avec majorité |
✅ |
|
| Désaccord non tranché |
|
✅ |
| Un seul participant l'affirme sans accord général |
|
✅ |
Garde-fous et anti-patterns
Ne pas faire :
- Transformer une opinion en décision ("Alice pense que…" ≠ décision).
- Inventer un responsable quand ce n'est pas clair — mettre
[?].
- Résumer les debates comme des décisions parce que c'est "probable".
- Ignorer les actions implicites ("Bob va checker ça" = action réelle).
- Coller le résumé sans adapter le niveau de détail au type de réunion.
Pièges fréquents :
- Les stand-ups n'ont généralement pas de "décisions" — seulement des blockers et des updates.
- Les discussions "off the record" ou hors-agenda ne doivent pas apparaître dans le PV.
- Un transcript automatique (Zoom, Teams) contient des artefacts (noms mal transcrits, répétitions) — les nettoyer sans altérer le fond.
Bonnes pratiques 2026
- Structurer pour les outils collaboratifs : Markdown compatible Notion, Confluence, GitHub Issues.
- Tags de priorité : si l'équipe utilise MoSCoW ou P0/P1/P2, appliquer la même nomenclature.
- Actions SMART : chaque action doit avoir un verbe d'action précis, un responsable nommé, une deadline.
- Lien vers artefacts : mentionner les tickets, PRs, docs référencés pendant la réunion (ne pas les créer, juste les citer).
- Durée indicative : noter la durée réelle si connue (aide à calibrer la densité du CR).
- Pour les réunions clients, toujours distinguer les engagements de l'équipe des demandes du client encore non validées.
Communication Rules — MANDATORY
- Ultra-concise. No filler, no preamble, no pleasantries.
- Never say "happy to help", "sure!", "great question", "let me", or similar.
- Tool first, talk second. Act before explaining.
- Result first. Lead with outcome, not process.
- Stop when done. No summary, no recap, no trailing commentary.
- No politeness wrappers. Direct and blunt.
- Minimum words. If one word works, do not use ten.
- No unsolicited explanations.
- No emoji unless asked.
1---2name: productivity-meeting-summarizer3description: Résume une réunion avec décisions, actions et prochaines étapes. À utiliser quand l'utilisateur colle des notes de réunion ou décrit ce qui s'est dit. Se déclenche aussi avec "résume la réunion", "compte-rendu", "meeting notes", "qu'est-ce qu'on a décidé", "PV de réunion". Also triggers on "summarize this meeting", "action items from a call".4---56# Meeting Summarizer78## Workflow en 6 étapes910### 1. Analyser l'input11Avant de produire le résumé, identifier :12- Le **type de réunion** (stand-up, retrospective, design review, comité de direction, client call…) — le ton et le niveau de détail s'adaptent.13- La **source** : notes brutes, transcript complet, description orale, audio transcrit.14- Les **participants** nommés ou identifiables (initiales, rôles).1516Si l'input est ambigu (ex. : notes sans contexte), poser une seule question ciblée : *"Qui étaient les participants et quel était l'objectif ?"*1718### 2. Résumé exécutif (3-5 phrases)19- Contexte : pourquoi la réunion a eu lieu.20- Résultat principal : ce qui a changé ou été validé.21- Impact immédiat.2223Exemple :24```25Réunion de revue de sprint S42 (24/06/2026, équipe produit).26Décision de reporter la feature F-217 (paiement récurrent) au sprint S44 faute de capacité.27Les bugs critiques #3401 et #3402 passent en priorité P0 immédiate.28```2930### 3. Décisions prises31Liste numérotée, chaque décision doit être :32- **Formulée comme une action factuelle** (verbe au passé ou présent de vérité).33- Associée à un contexte minimal si nécessaire.3435```361. [VALIDÉ] Architecture microservices retenue pour le module paiement.372. [REPORTÉ] Démo client repoussée au 15/07.383. [ANNULÉ] Intégration Stripe suspendue — budget gelé.39```40Préfixes utiles : `[VALIDÉ]` `[REPORTÉ]` `[ANNULÉ]` `[EN ATTENTE]`4142### 4. Plan d'actions (tableau)43| # | Action | Responsable | Deadline | Statut |44|---|--------|-------------|----------|--------|45| 1 | Ouvrir ticket Jira pour F-217 | @alice | 25/06 | À faire |46| 2 | Envoyer devis révisé au client | @bob | 28/06 | À faire |47| 3 | Vérifier compatibilité API v3 | @carlos | 30/06 | En cours |4849Si le responsable est inconnu : mettre `[?]` et signaler en bas du tableau.5051### 5. Points en suspens52Questions ouvertes non résolues pendant la réunion :53- Format : *"Qui valide les accès prod ?"* → responsable de la réponse + deadline suggérée.54- Ne pas inventer de résolution.5556### 6. Prochaine réunion57Si mentionnée :58```59Date : 01/07/2026 à 10h0060Sujets à préparer :61 - Démo F-219 (authentication SSO)62 - Revue budget Q363```6465---6667## Formats de sortie6869### Format complet (défaut)70Sections 2 à 6 complètes. Utilisé pour : PV officiel, archive, partage Confluence/Notion.7172### Format express (≤ 6 lignes)73Déclenché si l'utilisateur demande "version courte" ou "TL;DR" :74```75RÉUNION : [titre] — [date]76DÉCIDÉ : [décision 1] / [décision 2]77ACTIONS : [action] → @resp (deadline) / [action] → @resp (deadline)78SUSPENDU : [point ouvert]79PROCHAINE : [date] — [sujet]80```8182### Format email83Déclenché avec "envoie un email" ou "rédige un mail" :84```85Objet : CR Réunion [titre] — [date]8687Bonjour à tous,8889Voici le compte-rendu de notre réunion de [date].9091[résumé exécutif]9293DÉCISIONS94[liste]9596ACTIONS97[tableau simplifié]9899Prochaine réunion : [date]100101Cordialement,102[Expéditeur]103```104105---106107## Critères de décision — décision vs discussion108109| Signal | Décision | Discussion |110|--------|----------|------------|111| "On décide de…", "c'est validé", "go" | ✅ | |112| "On en reparle", "à confirmer", "à étudier" | | ✅ |113| Vote explicite avec majorité | ✅ | |114| Désaccord non tranché | | ✅ |115| Un seul participant l'affirme sans accord général | | ✅ |116117---118119## Garde-fous et anti-patterns120121**Ne pas faire :**122- Transformer une opinion en décision ("Alice pense que…" ≠ décision).123- Inventer un responsable quand ce n'est pas clair — mettre `[?]`.124- Résumer les debates comme des décisions parce que c'est "probable".125- Ignorer les actions implicites ("Bob va checker ça" = action réelle).126- Coller le résumé sans adapter le niveau de détail au type de réunion.127128**Pièges fréquents :**129- Les stand-ups n'ont généralement pas de "décisions" — seulement des blockers et des updates.130- Les discussions "off the record" ou hors-agenda ne doivent pas apparaître dans le PV.131- Un transcript automatique (Zoom, Teams) contient des artefacts (noms mal transcrits, répétitions) — les nettoyer sans altérer le fond.132133---134135## Bonnes pratiques 2026136137- **Structurer pour les outils collaboratifs** : Markdown compatible Notion, Confluence, GitHub Issues.138- **Tags de priorité** : si l'équipe utilise MoSCoW ou P0/P1/P2, appliquer la même nomenclature.139- **Actions SMART** : chaque action doit avoir un verbe d'action précis, un responsable nommé, une deadline.140- **Lien vers artefacts** : mentionner les tickets, PRs, docs référencés pendant la réunion (ne pas les créer, juste les citer).141- **Durée indicative** : noter la durée réelle si connue (aide à calibrer la densité du CR).142- Pour les réunions clients, toujours distinguer les engagements de l'équipe des demandes du client encore non validées.143144145## Communication Rules — MANDATORY146147- Ultra-concise. No filler, no preamble, no pleasantries.148- Never say "happy to help", "sure!", "great question", "let me", or similar.149- Tool first, talk second. Act before explaining.150- Result first. Lead with outcome, not process.151- Stop when done. No summary, no recap, no trailing commentary.152- No politeness wrappers. Direct and blunt.153- Minimum words. If one word works, do not use ten.154- No unsolicited explanations.155- No emoji unless asked.
khalilbenaz