c0sogi/write-korean-meeting-minutes-hwpx

Rédaction de comptes rendus de réunion coréens HWPX

Rédige un compte rendu officiel en coréen à partir d'un enregistrement audio/vidéo ou d'une transcription, et fournit un fichier .hwpx valide. S'il n'y a pas de transcription, elle est d'abord créée en Markdown à l'aide de meetdown. Le périmètre actuel s'arrête à la génération HWPX ; aucune conversion PDF n'est effectuée.

Environnement d'exécution

• Utilise le système de fichiers et les droits d'exécution du shell.
• Les commandes Python et les packages sont exécutés avec uv et uvx. L'outil de transcription vocale meetdown==0.2.1 nécessite Python 3.12 ou supérieur.
• La transcription vocale nécessite une connexion réseau et les identifiants de l'un des services suivants : CLOVA Speech, OpenAI ou Gemini.
• La création HWPX utilise un template inclus et un script basé sur la bibliothèque standard Python.

Principes impératifs

• Ne jamais supposer la date, le lieu, les participants, les noms des orateurs, les responsables, les échéances, les décisions, les chiffres ou les noms propres.
• Le Created at de meetdown correspond à l'heure de génération de la transcription, pas à celle de la réunion.
• Les mentions A, B, [[SPEAKER_1]] ne sont pas des noms réels ; les remplacer par le nom correspondant uniquement si un mapping des orateurs a été fourni par l'utilisateur.
• Distinguer les propositions, les préoccupations, les décisions, les actions de suivi et les points en suspens.
• Ne pas élever automatiquement au rang de décision une idée répétée plusieurs fois.
• Si l'avis initial diffère de l'accord explicite de fin de réunion, privilégier le dernier accord ou la dernière instruction.
• Les remarques désignant l'écran (« ici », « cette image », « ce côté ») ne sont pas détaillées si le document de référence n'est pas fourni.
• Ne pas exposer les clés API dans les arguments de commande, les logs, le Markdown, le JSON, le HWPX ou la réponse finale.
• Les titres de document et les titres de sections/sous-sections sont affichés en gras.
• Seules les courtes phrases contenant des décisions, des conclusions ou des actions de suivi importantes sont mises en évidence en bleu #2F5597 et en gras. Ne pas bleuir la majeure partie du texte.

Documents inclus

Ne lire que les documents pertinents à la situation.

• references/meetdown-guide.md : à lire s'il n'y a pas de transcription ou si l'exécution de meetdown échoue.
• references/minutes-writing.md : à lire avant de restructurer la transcription en compte rendu.
• references/hwpx-template.md : à lire lors de la création, du remplacement ou de la modification du template HWPX.
• references/installation.md : à lire pour indiquer l'emplacement d'installation ou la configuration de l'opérateur.
• references/evaluation.md : à lire lors de la conception de tests de régression après modification de la compétence.
• assets/minutes.schema.json : référence pour la structure de minutes.json.
• assets/example-minutes.json : utilisé uniquement comme exemple de structure de données, pas comme modèle de contenu.
• assets/example-audit.json : exemple de format de registre d'audit.
• assets/meeting-minutes-template.hwpx : modèle de base pour le compte rendu.

Scripts à utiliser

Tous les chemins sont relatifs à la racine de la compétence.

• scripts/transcribe.py : exécute meetdown en mode non interactif et protège les secrets.
• scripts/inspect_transcript.py : inspecte la structure et les risques de la transcription Markdown.
• scripts/validate_minutes.py : valide minutes.json avant la création HWPX.
• scripts/render_hwpx.py : applique le contenu structuré au template HWPX.
• scripts/validate_hwpx.py : vérifie le ZIP, le XML, les phrases obligatoires, le gras et la mise en évidence bleue.
• scripts/validate_skill.py : vérifie les règles fondamentales de la compétence d'agent.
• scripts/self_test.py : effectue une vérification complète de la procédure locale sans connexion réseau.

Ordre des opérations

État d'avancement :

• 1. Classifier les fichiers d'entrée et les documents de référence.
• 2. Transcrire avec meetdown s'il n'y a pas de transcription.
• 3. Inspecter la structure et la qualité de la transcription.
• 4. Rédiger le registre d'audit.
• 5. Créer et valider minutes.json.
• 6. Générer le HWPX.
• 7. Valider le HWPX et corriger les erreurs.
• 8. Rapporter les résultats et les points nécessitant une confirmation.

1. Classifier les documents d'entrée

Appliquer l'ordre de priorité suivant :

1. Métadonnées de réunion, mapping des orateurs, terminologie et corrections confirmés par l'utilisateur.
2. Ordre du jour, supports de présentation, RFP, liste des participants, etc., utilisés lors de la réunion réelle.
3. Transcription valide avec horodatage et orateurs.
4. Transcription intégrale sans horodatage.
5. Indice de date dans le nom du fichier, uniquement si le format est spécifié.

Traitement par type d'entrée :

• Si une transcription Markdown valide existe, l'utiliser telle quelle ; ne pas retranscrire le même enregistrement.
• S'il n'y a que de l'audio/vidéo, transcrire avant de rédiger le compte rendu.
• Si la transcription et l'enregistrement sont tous deux présents, privilégier la transcription. Ne retranscrire que si la transcription est vide, corrompue ou concerne une autre réunion.
• Transcrire chaque enregistrement séparément. Ne les concaténer dans l'ordre des fichiers que s'il est confirmé qu'il s'agit d'enregistrements consécutifs de la même réunion.
• S'il n'y a ni enregistrement ni transcription, rédiger une version de révision uniquement si les notes de réunion sont suffisantes. Ne pas inventer de contenu si les preuves sont insuffisantes.

2. Transcrire si nécessaire

Lire references/meetdown-guide.md avant de transcrire.

Exécution de base pour une réunion en coréen avec CLOVA Speech :

uv run scripts/transcribe.py "<fichier_audio>" \
  -o "<transcription.md>" \
  --provider clova \
  --language ko-KR

Ne réessayer avec les options suivantes que si le téléchargement unique d'un fichier long échoue ou si une limitation du fournisseur est évidente :

--chunk-duration 10m

Utiliser la compression smallest par défaut. Ne réessayer avec lossless que s'il est avéré que la compression dégrade la qualité de la transcription. Pour les réunions avec plusieurs participants, conserver la segmentation des orateurs sauf raison particulière.

Inspecter impérativement après la transcription :

uv run scripts/inspect_transcript.py "<transcription.md>" \
  -o "<transcription.inspect.json>"

Ne pas rédiger de compte rendu à partir d'un fichier vide, d'une page d'erreur HTML, ou d'un fichier sans transcription intégrale utilisable ni segments horodatés.

3. Organiser les métadonnées

Enregistrer les valeurs suivantes lorsqu'elles sont confirmées :

• Ordre du jour
• Date et heure
• Organisation responsable
• Lieu
• Participants
• Principaux sujets
• Mapping des orateurs
• Terminologie confirmée (noms de personnes, noms d'organisations, noms de projets, noms de produits, termes techniques)

Ne pas interrompre le travail si des métadonnées de faible importance sont manquantes. Rédiger une version de révision, indiquer À confirmer dans la cellule correspondante et le noter dans quality.missing_metadata. Ne demander confirmation que pour les informations dont l'absence modifierait significativement le résultat final complet.

4. Rédiger le registre d'audit

Avant de rédiger le texte final, créer minutes.audit.json. Pour chaque élément important, utiliser le format suivant :

{
  "type": "fact | proposal | concern | decision | action | open_question",
  "statement": "Contenu court et normalisé",
  "source": "Nom du fichier de transcription ou de document de référence",
  "speaker": "A ou nom réel confirmé",
  "start": "00:42:02",
  "end": "00:42:10",
  "confidence": "high | medium | low"
}

Critères de classification :

• fact : fait confirmé ou expliqué lors de la réunion.
• proposal : proposition, idée, option.
• concern : objection, risque, contrainte.
• decision : accord explicite, choix, confirmation, approbation, instruction.
• action : tâche concrète à effectuer.
• open_question : point non conclu.

Les actions de suivi doivent impérativement comporter une tâche. Ne remplir le responsable et la date limite que s'il existe une preuve.

5. Créer les données du compte rendu

Suivre references/minutes-writing.md et assets/minutes.schema.json. assets/example-minutes.json sert uniquement de référence pour la structure ; ne pas en copier le contenu.

Structure obligatoire du document :

• C O M P T E R E N D U
• Tableau de métadonnées en haut
• D É R O U L E M E N T D E L A R É U N I O N
  • Résumé de la réunion
  • 2. Discussions principales
  • 2.1 et suivants : discussions par sujet, généralement 3 à 7
• R É S U L T A T S D E L A R É U N I O N
  • [Résumé]
  • [Actions de suivi]
  • [Points à confirmer] (uniquement si nécessaire)

Rédiger dans un style coréen professionnel, concis et neutre. Utiliser les terminaisons de base -함, -하기로 함, -논의됨, -필요함, -판단됨. Supprimer les hésitations, les bégaiements, les répétitions et les apartés sans rapport, mais conserver les objections, les contraintes techniques, les coûts et les délais qui justifient une décision.

Pour les phrases à mettre en évidence en bleu, les insérer dans le tableau emphasis sous forme de chaînes courtes identiques au texte. Marquer les éléments importants avec important: true.

Validation :

uv run scripts/validate_minutes.py "<minutes.json>"

Corriger toutes les erreurs. Vérifier également les avertissements concernant les métadonnées manquantes, les phrases de mise en évidence absentes du texte, un ratio de mise en évidence excessif et les paragraphes trop longs.

6. Générer le HWPX

Si l'utilisateur n'a pas fourni de modèle compatible, utiliser le modèle par défaut.

uv run scripts/render_hwpx.py \
  --template assets/meeting-minutes-template.hwpx \
  --data "<minutes.json>" \
  --output "<compte_rendu_final.hwpx>"

Le moteur de rendu conserve la structure du tableau et les styles de paragraphe existants, met en gras les titres et les sous-titres, et met en évidence les phrases clés spécifiées en bleu #2F5597 et en gras. Si le contenu est long, ne pas réduire excessivement la taille de la police ; laisser le texte se poursuivre naturellement sur la page suivante.

Si l'utilisateur fournit un modèle HWPX sensiblement différent, ne pas l'exécuter aveuglément. Suivre references/hwpx-template.md pour vérifier d'abord les adresses des cellules du tableau et la structure des paragraphes, puis adapter le moteur de rendu.

7. Valider le HWPX

uv run scripts/validate_hwpx.py "<compte_rendu_final.hwpx>" \
  --expect-data "<minutes.json>"

En cas d'échec de la validation, modifier le JSON ou le template, puis regénérer. Ne pas transmettre un fichier dans l'état suivant :

• mimetype n'est pas le premier élément du ZIP ou il est compressé.
• Le XML obligatoire est manquant ou ne peut pas être analysé.
• Les phrases attendues sont manquantes.
• Les titres de document ou de section ne sont pas en gras.
• La mise en évidence a été demandée mais le style bleu gras est absent.
• Il reste des espaces réservés non finalisés.

Si Hancom Office est disponible, ouvrir le fichier pour vérifier les bordures du tableau, le remplacement des polices, le flux des pages, les phrases tronquées et le dernier paragraphe. Ne pas déclarer la vérification visuelle comme terminée si le fichier n'a pas été réellement ouvert.

8. Résultats et rapport

Produire les éléments suivants selon le cas :

• transcript.md (si une transcription a été nécessaire)
• transcript.inspect.json
• minutes.json
• minutes.audit.json
• minutes.review.md (s'il existe des éléments non confirmés)
• Fichier .hwpx final

Format du rapport final :

Terminé
- HWPX : <chemin>
- Transcription : <chemin ou utilisation de la transcription existante>
- Validation : réussie | avertissements
- À confirmer : aucun | résumé des éléments clés

Gestion des échecs

• En l'absence d'identifiants, indiquer uniquement le nom des variables d'environnement nécessaires et ne pas demander à l'utilisateur de saisir les secrets dans le chat.
• En cas de limite de taille ou de temps, réessayer avec --chunk-duration 10m.
• Si la fiabilité de la transcription est faible, ne pas corriger arbitrairement les noms propres et les chiffres ; les laisser comme éléments à vérifier.
• Si le rendu HWPX échoue, en signaler la cause et ne pas fournir le fichier corrompu comme résultat.
• Si une conversion PDF est demandée, préciser que cela dépasse le périmètre actuel de la compétence et qu'un environnement de conversion séparé est nécessaire.

Auto-test

Exécuter après l'installation de la compétence ou après avoir modifié un script ou un template :

uv run scripts/self_test.py

Ce test n'appelle pas d'API de reconnaissance vocale ; il effectue l'analyse de la transcription, la validation JSON, la génération HWPX et la validation structurelle.