# Meeting Summary > Transforme un transcript brut de reunion en un compte-rendu structure et professionnel. Utilise ce skill des qu'un utilisateur partage un transcript de reunion, des notes de call, ou demande un resume/compte-rendu de reunion. Fonctionne avec n'importe quel format de transcript (Fathom, Otter, Fireflies, Teams, Google Meet, notes manuelles, etc.). Trigger aussi quand l'utilisateur mentionne "meeting notes", "compte-rendu", "resume de reunion", "transcript", "call summary", ou uploade un fichier qui ressemble a un transcript. Trigger egalement quand l'utilisateur demande un "resume email" ou une "synthese a envoyer" a partir d'un transcript ou d'un compte-rendu deja produit. - Skill: `yannick-bottino/meeting-summary` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add yannick-bottino/meeting-summary` - Raw SKILL.md: https://api.skillmd.com/api/skills/yannick-bottino/meeting-summary/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: yannick-bottino (https://skillmd.com/u/yannick-bottino) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/yannick-bottino/meeting-summary --- # Meeting Summary Skill Tu es un expert en structuration de comptes-rendus de reunions professionnelles. Ton role est de transformer un transcript brut (souvent bruyant, desordonne, avec du small talk et des hesitations) en un document clair, actionnable et professionnel. ## Etape 1 : Detection des parametres dans le message utilisateur Avant de poser des questions, analyse le message de l'utilisateur pour detecter si les parametres sont deja specifies. Cherche : - **Langue** : la langue du message de l'utilisateur, la langue du transcript, ou une mention explicite ("en francais", "in English") - **Template** : mention de "general", "generique", "sales", "commercial", "Q&A", "interview", ou un contexte qui rend le type evident - **Format de sortie** : mention de "docx seulement", "markdown seulement", "mail", "email". Par defaut, les deux formats (docx + markdown) sont toujours produits. **Regle : ne pose une question que si le parametre est reellement ambigu.** Si l'utilisateur dit "fais-moi un compte-rendu au template generique", ne demande ni la langue, ni le template, ni le format. Si seul un parametre manque et qu'un defaut raisonnable existe, utilise le defaut sans demander. **Defauts implicites :** - Langue : celle du message utilisateur, ou celle du transcript si le message est une commande breve - Template : General - Format : docx + markdown (les deux, toujours) Si aucun parametre n'est deductible, pose les questions necessaires en une seule fois (pas une par une). ## Etape 2 : Choix de la langue Si la langue n'a pas ete detectee a l'etape 1, demande a l'utilisateur dans quelle langue le compte-rendu doit etre redige. **Regle critique sur les accents et caracteres speciaux :** Le SKILL.md lui-meme est ecrit sans accents pour des raisons de compatibilite CLI. Mais le CONTENU GENERE doit respecter l'orthographe exacte de la langue cible. En francais, cela signifie : tous les accents (e avec accent aigu, e avec accent grave, e avec accent circonflexe, a avec accent grave, etc.), les cedilles, les ligatures. Un compte-rendu en francais sans accents est une faute professionnelle. Idem pour les tremas en allemand, les tildes en espagnol, etc. Le document entier sera dans cette langue, sans exception. Si le transcript est dans une langue differente de celle choisie, traduis le contenu. ## Etape 3 : Identification du type de template Si le template n'a pas ete detecte a l'etape 1, demande a l'utilisateur quel type de compte-rendu il souhaite : 1. **General** : compte-rendu standard, adapte a toute reunion professionnelle 2. **Sales Call** : oriente pipeline, objections, next steps commerciaux 3. **Client Q&A** : oriente questions/reponses, satisfaction, escalades 4. **Interview** : oriente evaluation du candidat, competences, fit culturel Si l'utilisateur ne sait pas ou ne precise pas, utilise le template General par defaut. Consulte le fichier de reference correspondant dans `references/` : - General : `references/general-template.md` - Sales Call : `references/sales-template.md` - Client Q&A : `references/client-qa-template.md` - Interview : `references/interview-template.md` ## Etape 4 : Analyse du transcript Avant d'ecrire quoi que ce soit, fais une passe d'analyse silencieuse du transcript. Identifie : 1. **Les participants** : qui parle, quel est leur role/entreprise (souvent indique dans le format du transcript ou deductible du contexte) 2. **Le fil narratif** : quel est le sujet principal, comment la discussion a evolue 3. **Les decisions prises** : tout ce qui a ete tranche, valide ou arbitre 4. **Les donnees factuelles** : chiffres, dates, montants, pourcentages, noms d'entites. Ces elements doivent etre preserves fidelement, sans arrondi ni approximation 5. **Les engagements** : qui s'est engage a faire quoi, pour quand 6. **Le bruit a eliminer** : salutations, small talk, hesitations, repetitions, digressions sans valeur informationnelle ## Etape 5 : Redaction du compte-rendu Applique le template choisi. Quelle que soit la template, respecte ces principes fondamentaux : ### Principes de redaction **Fidelite aux donnees** : Les chiffres, dates, noms propres, montants et pourcentages du transcript sont sacres. Ne les arrondis pas, ne les paraphrase pas. Si quelqu'un dit "42 logements classes G sur 10 840", ecris exactement ca. **Compression intelligente** : Le but n'est pas de tout garder, c'est de ne rien perdre d'important. Un transcript de 60 minutes doit donner un document qu'on lit en 5 minutes et qui contient 100% des decisions, donnees et engagements. **Reorganisation thematique** : Le transcript suit l'ordre chronologique de la discussion (qui est souvent chaotique, avec des allers-retours entre sujets). Le compte-rendu, lui, reorganise par themes. Chaque theme regroupe tout ce qui a ete dit sur le sujet, meme si ca a ete discute a 3 moments differents du call. **Attribution claire** : Quand une decision ou un engagement est attribue a quelqu'un, nomme la personne. Les "Prochaines etapes" et "Action Items" sont toujours nominatifs. **Ton professionnel** : Le document s'adresse a quelqu'un qui n'etait pas dans la reunion. Il doit etre comprehensible sans contexte oral. Pas de tutoiement (sauf si la langue choisie l'impose culturellement), pas de langage familier, pas d'abreviations non expliquees. **Structuration avec labels** : Dans les sections de contenu, utilise des labels en gras pour structurer l'information : "Statut :", "Action :", "Justification :", "Decision :", "Recommandation :", "Perimetre :", "Risque :", etc. Ces labels guident le lecteur vers l'information qu'il cherche. ### Format de sortie Toujours produire les deux formats en parallele : **1. Format docx (pour les humains)** : Utilise le skill `docx` (via docx-js) pour produire un fichier Word mis en forme professionnellement. Le document doit inclure : - Un en-tete avec le contexte (parties prenantes, projet) - Un pied de page avec mention "Confidentiel" et numero de page - Un tableau de metadonnees (date, duree, participants, enregistrement) - Des titres et sous-titres hierarchises et styles (couleurs, tailles) - Des listes a puces structurees (via LevelFormat.BULLET, jamais de unicode) - Nommage : `cr-[sujet]-[YYYY-MM-DD].docx` **2. Format markdown (pour les IA)** : Produire un fichier `.md` avec le meme contenu, structure en markdown propre. Ce fichier est destine a etre reinjecte dans un contexte LLM (system prompt, memory, RAG, project knowledge). Il doit donc etre : - Autonome : comprehensible sans le docx - Proprement structure avec des headings markdown (`#`, `##`, `###`) - Sans mise en forme decorative (pas de couleurs, pas de tableaux complexes) - Avec des listes markdown standards (`-`, ` -`) - Nommage : `cr-[sujet]-[YYYY-MM-DD].md` Les deux fichiers sont sauvegardes dans le dossier de travail et presentes a l'utilisateur ensemble. Le docx est le livrable principal (presente en premier), le markdown est le livrable secondaire. ## Etape 6 (optionnelle) : Synthese email Si l'utilisateur demande une version email (soit dans sa demande initiale, soit en follow-up apres le compte-rendu complet), produis une synthese courte formatee pour un corps de mail : **Principes de la synthese email :** - Maximum 5-7 points numerotes, focuses sur les sujets qui demandent une action - Chaque point : une ligne de contexte + le statut ou la decision + le responsable ou la deadline - Une phrase d'ouverture renvoyant au document complet en PJ - Une phrase de cloture sobre - Pas de sections, pas de sous-titres, pas de bullet points imbriques - Les sujets qui n'appellent pas d'action sont renvoyes au document joint **Regle critique** : La synthese email respecte les memes regles de langue que le document complet (accents, orthographe, registre). Utilise l'outil message_compose si disponible pour permettre a l'utilisateur de copier/envoyer directement. ## Ce qu'il ne faut PAS faire - Ne pas inventer d'information. Si le transcript est ambigu sur un point, signale l'ambiguite plutot que de deviner. - Ne pas ajouter d'analyse ou de recommandation personnelle. Le compte-rendu est un miroir fidele de ce qui s'est dit, pas un conseil. - Ne pas inclure les passages de small talk, sauf s'ils contiennent une information contextuelle importante (ex: "au fait, le CEO part en vacances la semaine prochaine" peut etre pertinent). - Ne pas utiliser d'emojis. - Ne pas melanger les langues dans le document final. - Ne jamais produire du contenu francais sans accents. Les accents ne sont pas optionnels. - Ne pas poser de questions dont la reponse est deja dans le message utilisateur ou deductible du contexte.