CommunityRédaction et éditiongithub.com

prodagenx/px-summarize-transcript

Extrayez les décisions, les déclarations matérielles, les actions et les questions ouvertes d'un compte-rendu de réunion (.vtt, copier-coller Teams en .txt ou Markdown .md) avec attribution des intervenants et preuves textuelles horodatées, puis enregistrez le tout sous forme d'un bundle lié avec frontmatter à côté du compte-rendu.

Qu'est-ce que px-summarize-transcript ?

Ce skill transforme un compte-rendu de réunion en un enregistrement structuré, basé sur des preuves, de ce qui a été décidé, des faits importants énoncés et des responsables pour chaque action. Chaque élément cite l'intervenant, l'horodatage (si disponible) et une citation textuelle. Il prend en charge les formats .vtt, le copier-coller depuis Teams (.txt ou .md), et les comptes-rendus Markdown avec horodatage. L'outil attribue des responsables aux actions, suit ce qui a été reporté de la réunion précédente dans une série, et permet de classer les comptes-rendus dans des dossiers de série. Il est conçu pour les assistants IA comme Claude Code, Cursor ou Codex, qui exécutent des scripts Python pour le parsing, la vérification des citations et la finalisation du bundle, tandis que l'IA effectue le raisonnement (extraction des éléments, cartographie des intervenants). Le résultat est un ensemble cohérent de fichiers (index des tours, rapport, sidecar) stocké à côté du compte-rendu source.

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/prodagenx/px-summarize-transcript/tree/HEAD

Installed? Explore more Rédaction et édition skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Que fait px-summarize-transcript ?

Transforme un compte-rendu de réunion en un enregistrement étayé par des preuves de ce qui a été décidé, des faits matériels énoncés et de qui est responsable de chaque prochaine étape. Chaque élément cite l'intervenant, l'horodatage (lorsque le compte-rendu en possède un) et une citation textuelle. Les scripts Python effectuent le travail mécanique : analyse, nommage des fichiers, frontmatter et vérification des citations. Vous effectuez le raisonnement.

Quand l'utiliser

  • Un fichier .vtt, un compte-rendu Teams copié-collé dans un fichier .txt ou .md, un compte-rendu Markdown au format [Intervenant] AAAA-MM-JJ HH:MM:SS, ou des lignes Nom: texte nécessitent l'extraction de décisions et d'actions.
  • Quelqu'un demande qui a dit quelque chose, ce qui a été convenu, ou qui est responsable d'un suivi.
  • Quelqu'un demande ce qui est encore ouvert depuis la réunion précédente dans une série récurrente.
  • Les résultats de la réunion doivent être rapprochés des documents du projet.

Structure du bundle (fixe)

Tous les fichiers se trouvent dans le dossier du compte-rendu et partagent son nom de fichier. Seul le suffixe change. Vous ne pouvez pas les écrire ailleurs. Si l'utilisateur demande un autre dossier, expliquez que le bundle reste avec son compte-rendu. file_transcript.py peut déplacer un bundle entier dans un dossier de série, et ses membres se déplacent toujours ensemble.

FichierRôle
<stem>.vtt / .txt / .mdCompte-rendu source. Les fichiers .md et .txt reçoivent un frontmatter fusionné sur place ; les clés existantes ne sont jamais modifiées.
<stem>.source.md.vtt uniquement : un petit fichier Markdown "sidecar" qui contient le frontmatter du .vtt, car un fichier .vtt doit commencer par WEBVTT et ne peut pas contenir de frontmatter.
<stem>.turns.mdIndex des tours. Créé une fois ; jamais réécrit sauf si vous passez --rebuild.
<stem>.summary.mdRapport. Les réexécutions écrivent <stem>.summary.v2.md, .v3, etc.

Formats et clés : formats d'entrée, spécification du frontmatter.

Procédure

Les scripts se trouvent dans ./scripts/ à côté de ce SKILL.md. Le terminal démarre dans l'espace de travail de l'utilisateur, donc résolvez d'abord le chemin absolu du dossier du skill (les installations personnelles sont généralement ~/.claude/skills/px-summarize-transcript ou ~/.agents/skills/px-summarize-transcript) et définissez-le une fois par terminal :

$S = "<chemin absolu vers ce skill>\scripts"      # PowerShell
S="<chemin absolu vers ce skill>/scripts"          # bash / zsh

Les commandes ci-dessous utilisent PowerShell ("$S\build_turns.py"). En bash, écrivez "$S/build_turns.py". Les scripts utilisent uniquement la bibliothèque standard (Python 3.10+). Mettez les chemins entre guillemets, car les noms de fichiers contiennent souvent des espaces.

Travaillez sur un seul compte-rendu à la fois. Pour un dossier ou "tout ce qui est en attente", voir Plusieurs comptes-rendus.

  1. Classer le compte-rendu (optionnel). Faites-le lorsque l'utilisateur le demande, ou lorsque l'espace de travail conserve les comptes-rendus dans des dossiers de série (par exemple transcripts/<series>/) et que celui-ci n'y est pas encore. --root par défaut est ./transcripts.

    python "$S\file_transcript.py" --list --root "<root>"
    python "$S\file_transcript.py" "<transcript>" --series "<series>" --root "<root>"
    

    Réutilisez une série existante qui correspond à la réunion. Si aucune ne convient, proposez un nom court en kebab-case et confirmez-le avec l'utilisateur avant de le créer. Ensuite, agissez en fonction du status :

    • moved : continuez avec le nouveau chemin source.
    • already-filed : le compte-rendu est déjà dans un dossier sous la racine, ou dans un dossier nommé d'après la série. Rien n'a été déplacé, continuez donc.
    • duplicate : le même compte-rendu existe déjà à duplicate_of. Arrêtez-vous et demandez à l'utilisateur quelle copie traiter. Ne supprimez aucun des deux fichiers.
    • conflict (code de sortie 2) : un fichier différent portant le même nom se trouve déjà dans le dossier de la série. Arrêtez-vous et demandez.
  2. Construire l'index des tours.

    python "$S\build_turns.py" "<transcript>"
    

    Il détecte le format, écrit <stem>.turns.md s'il n'existe pas encore, marque la source (ou le sidecar) et affiche du JSON. Conservez turns_path, turns_status, summary_path, has_timestamps, speakers, meeting_date, meeting_date_source, gaps, previous_meeting_summary et transcription.

    • turns_status: created ou kept : continuez. kept signifie que l'index des tours existant correspond déjà au compte-rendu, donc rien n'a été réécrit.
    • turns_status: source-changed (code de sortie 3) : le compte-rendu a été modifié après la construction de l'index des tours, et les rapports existants citent les anciens identifiants de tour. Arrêtez-vous et demandez à l'utilisateur avant de réexécuter avec --rebuild.
    • Erreur de format non pris en charge (code de sortie 2) : indiquez à l'utilisateur quels formats sont pris en charge et arrêtez-vous.
    • meeting_date est null : écrivez "Non indiqué" sauf si l'utilisateur vous donne la date.
  3. Lire l'intégralité de l'index des tours par grands morceaux jusqu'à la fin. N'extrayez jamais à partir d'une lecture partielle.

  4. Cartographier les intervenants. Créez une ligne par étiquette d'intervenant pour le tableau des Intervenants du rapport : l'étiquette, le nom à afficher, et comment vous l'avez identifié.

    • N'affichez un nom différent qu'avec une preuve : la personne est appelée par son nom, se présente, ou l'étiquette est une faute d'orthographe évidente. Enregistrez la preuve.
    • Une étiquette de périphérique de salle de conférence reste le nom de la salle. Listez les personnes entendues ou interpellées dans cette salle, et n'attribuez pas ses lignes à une seule personne à moins que le compte-rendu ne le rende non ambigu.
    • Les personnes nommées uniquement dans la ligne d'en-tête Transcription : ont assisté à la réunion mais n'ont pas nécessairement pris la parole.
    • Listez les personnes qui sont mentionnées mais ne parlent pas, avec l'endroit où elles ont été mentionnées.
    • Résolvez les prénoms en noms complets uniquement lorsque c'est non ambigu.
  5. Extraire les éléments en utilisant ces tests :

    • Décision : un choix entre des options a été fait ou accepté ("on part sur", "d'accord", "on va faire", ou une proposition sans objection). Statut : Acceptée, Provisoire ou Proposée.
    • Déclaration matérielle : quelque chose qui changerait le périmètre, la conception, le calendrier, le coût ou le risque si c'était faux : faits sur les systèmes, contraintes, dépendances, chiffres, dates, engagements, risques énoncés. Pas de bavardage ou de reformulation. Visez 12 ou moins en fusionnant les déclarations connexes.
    • Action : une tâche future avec un verbe, demandée ou proposée ("je vais", "peux-tu", "nous devons").
    • Question ouverte : soulevée et non résolue avant que la réunion ne passe à autre chose.
  6. Attribuer des responsables à chaque action. Les responsables peuvent être toute personne nommée, y compris les absents.

    • Explicite : nommé et interrogé, n'a pas refusé.
    • Volontaire : l'intervenant a dit "Je vais...".
    • Délégué : attribué à une personne absente ou silencieuse. Mentionnez (non présent) et notez qui l'a attribué.
    • Inféré : découle d'un rôle ou d'une responsabilité énoncée. Écrivez le raisonnement.
    • Non attribué : aucun des cas ci-dessus. N'inventez jamais de responsable.

    Enregistrez les dates d'échéance uniquement si elles ont été mentionnées.

  7. Ajouter des preuves à chaque élément :

    • Avec horodatages : [T042 00:12:31 Intervenant] "citation textuelle".
    • Sans horodatages (has_timestamps: false) : [T042 Intervenant] "citation textuelle".
    • Intervenant est l'étiquette exacte telle qu'elle apparaît dans l'index des tours, même si le tableau des Intervenants affiche un nom différent. Utilisez les noms d'affichage partout ailleurs.
    • Les citations font 25 mots ou moins, copiées exactement, y compris les erreurs de RAP. Utilisez ... pour les omissions. Citez plusieurs tours lorsqu'une décision se forme sur plusieurs tours.
  8. Vérifier ce qui a été reporté (uniquement lorsque previous_meeting_summary est défini). Lisez uniquement les tableaux Actions et Questions ouvertes de ce rapport. Pour chaque élément, décidez à partir de ce compte-rendu s'il est Terminé, En cours, Toujours ouvert, Abandonné ou Non mentionné, et citez le tour qui le montre. Ne marquez jamais un élément comme Terminé sans que quelqu'un le dise.

  9. Écrire le rapport dans summary_path en utilisant le modèle. Écrivez uniquement le corps ; n'ajoutez pas de frontmatter. Remplissez toujours "En un coup d'œil". Ajoutez "Pour " uniquement lorsque l'utilisateur nomme le lecteur, par exemple "pour moi, je suis Dana Ruiz". Ne supposez jamais qui est le lecteur.

  10. Signaler les réserves de transcription : erreurs probables de RAP, noms d'intervenants que vous avez cartographiés par inférence, et chaque entrée dans gaps (le contenu peut manquer). Ne corrigez jamais les citations en silence.

  11. Vérifier les citations et corriger ou supprimer chaque ligne en échec jusqu'à ce qu'elle passe :

    python "$S\verify_quotes.py" "<summary_path>"
    
  12. Finaliser le bundle. Dérivez un titre court du contenu de la réunion et de 3 à 6 balises thématiques (minuscules, kebab-case). transcript et meeting-notes sont ajoutés automatiquement.

    python "$S\finalize_bundle.py" "<transcript>" --summary "<summary_path>" --title "<titre>" --tags "tag-un,tag-deux" --alias "Étiquette dans le transcript=Nom d'affichage" --mentioned "Nom (contexte)" --meeting-date AAAA-MM-JJ
    
    • --alias se répète une fois par étiquette d'intervenant que vous avez cartographiée à l'étape 4. Les participants prennent alors par défaut les noms d'affichage.
    • --mentioned se répète une fois par personne.
    • --attendee "Nom" se répète une fois par personne lorsque vous devez remplacer la liste des participants. --attendees "A, B (salle : C, D)" fonctionne aussi, car les virgules à l'intérieur de () ou [] ne sont pas scindées.
    • Passez --meeting-date uniquement lorsque meeting_date était null et que l'utilisateur vous a donné la date.
  13. Faire un compte-rendu dans le chat brièvement. Ne collez pas les tableaux.

    • Nombres : décisions, déclarations, actions, questions ouvertes et éléments reportés.
    • Les puces "En un coup d'œil".
    • Tout ce qui nécessite une vérification humaine : noms d'intervenants inférés, responsables inférés ou non attribués, lacunes et réserves liées au RAP.
    • Liens vers le rapport et l'index des tours.

Plusieurs comptes-rendus

python "$S\scan.py" "<dossier>" --recursive

Il liste chaque compte-rendu comme new, turns-only, summarized ou not-a-transcript. Montrez à l'utilisateur ceux qui sont en attente (new et turns-only) et confirmez avant de commencer. Traitez-les un par un, la réunion la plus ancienne en premier, afin que chacun puisse trouver la réunion précédente dans sa série. Exécutez la procédure complète et faites un compte-rendu pour chacun avant de passer au suivant.

Documents de projet connexes

Si l'espace de travail contient des documents d'architecture ou de planification connexes (y compris les fichiers de résumé d'autres bundles), remplissez le tableau optionnel "Documents de projet connexes". Notez si chaque élément confirme, contredit ou étend ce que ces documents enregistrent.

Contrôles qualité

  • verify_quotes.py passe sans échec.
  • Le tableau des Intervenants comporte une ligne pour chaque étiquette dans l'index des tours, et chaque cartographie de nom indique sa preuve.
  • Aucun responsable n'est nommé sans preuve explicite, volontaire, déléguée ou inférée expliquée.
  • Les décisions marquées Acceptée montrent un signal d'acceptation, pas seulement une suggestion.
  • Les opinions et spéculations sont étiquetées comme telles.
  • Les responsables qui n'étaient pas à la réunion sont marqués (non présent).
  • Chaque entrée dans gaps apparaît sous Réserves de transcription.
  • Lorsqu'il y a une réunion précédente, chacune de ses actions et questions ouvertes a une ligne Reporté.

Bundles hérités

Pour aligner des bundles plus anciens (par exemple input.txt à côté de <dossier>.turns.md), exécutez python "$S\backfill.py" "<root>" pour un essai à blanc, puis --apply. Exécutez ensuite finalize_bundle.py par bundle avec un titre et des balises. Backfill ne régénère jamais un index de tour existant, donc les citations existantes restent valides.

Skills associés