Comptes rendus de réunion
Traitez une transcription et générez un compte rendu structuré et auditable. Les comptes rendus deviennent des faits : trois semaines plus tard, quelqu'un citera ce document comme preuve de ce qui a été convenu. Par conséquent, tout ce que vous enregistrez est traçable jusqu'à la transcription, et tout ce que vous présumez reste visiblement séparé de ce qui a été explicitement énoncé. Enregistrer, c'est certifier ; votre analyse ne doit jamais se faire passer pour le discours d'un participant.
Ce workflow est une synthèse sans entretien : la réunion a déjà eu lieu. Les questions laissées ouvertes sont adressées à leurs destinataires via des questionnaires, et le contenu des exigences est acheminé vers /requirements-discovery.
Transcription : $ARGUMENTS
Limite de provenance
Basé sur requirements-rigor, la provenance prend ici trois formes :
[STATED: speaker, "short paraphrase"](pt-BR :[DITO: falante, "paráfrase curta"]) : énoncé dans la transcription. Chaque action, décision et priorité porte l'identité de son auteur et une paraphrase de 5 à 15 mots. Une paraphrase honnête suffit pour l'audit.[ASSUMED: base](pt-BR :[PRESUMIDO: base]) : votre analyse inférée à partir de schémas conversationnels : silence après une proposition, "ok" ambigu, tâche impliquée par une décision que personne n'a explicitement assumée. Les éléments présumés n'entrent jamais dans les Décisions, le Tableau des Actions ou le JSON ; ils figurent dans les sections de présomption, avec l'extrait et la personne qui doit confirmer.[TO BE DEFINED](pt-BR :[A DEFINIR]) : responsable ou échéance ni mentionné(e) ni inférable. Le placeholder est la bonne réponse.
Test rapide : "si un participant lit cette ligne et dit 'je n'ai jamais dit ça', puis-je pointer l'extrait ?" Oui : STATED. "Ils ne l'ont pas dit directement, mais l'ont sous-entendu" : ASSUMED. Ni l'un ni l'autre : TO BE DEFINED, ou exclu du compte rendu. Les autres marqueurs de requirements-rigor, comme [INFERENCE: base], restent valides.
Étapes
-
Métadonnées. Lisez
docs/agents/refinement.mddans l'espace de travail pour identifier la langue configurée (en-USoupt-BR, défauten-US) et le chemin de publication. Les comptes rendus, questionnaires et entrées générées suivent cette langue. Identifiez le titre, la date, la durée, les participants avec leurs rôles, le projet, et les termes du glossaire déformés par la transcription automatique. La date est obligatoire : l'arithmétique des échéances en dépend. Si elle manque, demandez-la en une seule ligne avant de continuer. LisezCONTEXT.mdpour les termes du glossaire lorsqu'il est présent. Terminé quand : la date et les participants sont établis. -
Triage. INTACT (audio continu, intervenants identifiables), DÉGRADÉ (segments inaudibles, intervenants mal assignés, coupures), INSUFFISANT (trop court, ou pas la réunion des métadonnées). INSUFFISANT : indiquez la raison et arrêtez ; des comptes rendus de façade ne doivent pas circuler comme documents officiels. DÉGRADÉ : chaque lacune qui pourrait contenir une action ou une décision devient une question ouverte (« segment inaudible vers ~12min suite à la proposition de X ») ; les lacunes ne sont jamais reconstituées. Terminologie déformée : appliquez l'orthographe du glossaire et marquez
[POSSIBLE TRANSCRIPTION ERROR: original -> adopté]dans la section 0, en utilisant uniquement le terme adopté dans le corps du texte. Détails personnels, santé, famille, remarques sur des collègues absents : omettez de toutes les sections ; un engagement de projet noyé dans un contexte personnel est enregistré sans la circonstance. Intervenant non identifié avec un engagement : responsable[TO BE DEFINED: intervenant non identifié vers ~Xmin]et question ouverte. Une note indiquant que du contenu personnel a été omis peut apparaître dans le triage sans détails ; les échéances mentionnées uniquement dans un contexte personnel sont conservées textuellement sans la circonstance personnelle. Terminé quand : le triage est enregistré dans la section 0 avec les erreurs de transcription détectées. -
Extraire. Appliquez les règles de RULES.md : rétractation et remplacement, granularité des actions, priorité avec provenance, ce qui compte comme une décision. Terminé quand : chaque décision et action porte une provenance STATED, et les présomptions vivent strictement dans les sections 4 ou 5.
-
Rédiger les comptes rendus en suivant TEMPLATE.md. En « mode actions », écrivez uniquement les sections 3, 6 et 7. Terminé quand : le fichier existe dans
.scratch/<projet>-<AAAA-MM-JJ>/minutes.md(ou là où configuré dansdocs/agents/refinement.md), avec l'avertissement final. -
Auto-vérification et rapport en une seule ligne dans la section 8 : chaque action réelle dans le tableau a un objet JSON correspondant et aucun objet JSON n'existe en dehors du tableau ; chaque ligne et décision porte STATED ; aucun ASSUMED n'a fui dans le tableau ou les décisions ; les priorités correspondent entre le tableau et le JSON ; les dates JSON sont ISO ou null. Terminé quand : la section 8 indique « Auto-Audit : OK » ou détaille les corrections.
-
Router les éléments ouverts. Accords présumés et questions ouvertes avec des destinataires extérieurs à la session : rédigez un questionnaire par destinataire selon
QUESTIONNAIRE.mddansrequirements-rigor, à côté des comptes rendus, et liez-le depuis la section génératrice. Extraits avec contenu d'exigence (besoins, capacités, contraintes énoncés) : rédigezdiscovery-input.mdà côté des comptes rendus selon le modèle à la fin de TEMPLATE.md, et informez l'utilisateur que/requirements-discoverydémarre à partir de celui-ci. Terminé quand : chaque accord présumé a un destinataire et un questionnaire, et l'apport à la découverte existe lorsque la réunion contenait du contenu d'exigence.
Avis final
⚠️ Ce compte rendu est un brouillon généré par IA à partir d'une transcription. Il nécessite une validation par les participants avant de circuler comme document officiel, en particulier les accords présumés, qui n'ont pas été verbalisés explicitement et nécessitent confirmation.