Meeting Scribe – Transcrire, Corriger, Canevas, Résumer

Ce que fait cette compétence

Prenez un fichier audio de réunion (ou une transcription .txt déjà transcrite) que l'utilisateur dépose dans la zone de dépôt configurée, et produisez trois artefacts :

Une transcription corrigée (nettoyage léger, caractéristiques vocales préservées)
Un canevas visuel (un seul fichier HTML autonome, l'ensemble de la réunion en un coup d'œil)
Un résumé (Markdown, avec une section d'insights IA)

La transcription s'exécute localement via Whisper (aucune application externe). Les artefacts sont écrits directement vers la destination de sortie configurée – jamais affichés en entier dans le chat (l'affichage puis l'écriture généreraient deux fois le même contenu en tokens de sortie et gonfleraient le contexte). L'utilisateur consulte la destination et y demande des modifications.

Tout comportement spécifique à la machine – où atterrit l'audio, quel modèle Whisper utiliser, où vont les artefacts, dans quelle langue écrire – provient d'un fichier de configuration par utilisateur, PAS de ce document. Cette compétence est uniquement la logique d'orchestration ; elle est portable entre utilisateurs et machines.

Configuration

Au chargement (lorsque l'utilisateur invoque cette compétence), lisez d'abord la configuration :

cat ~/.config/meeting-transcripts/config.json

Si elle existe -> analysez-la et utilisez ses valeurs pour chaque décision de chemin / modèle / langue ci-dessous. Ne racontez pas cette lecture.
Si elle est absente -> exécutez la Configuration initiale (ci-dessous) une fois, écrivez la configuration, puis continuez.

Schéma de configuration

{
  "engine": "faster-whisper",
  "model": "large-v3",
  "model_path": "/abs/path/to/model",
  "engine_bin": null,
  "python_bin": null,
  "compute_type": "auto",
  "transcribe_language": "auto",
  "audio_dropzone": "/abs/path/to/drop-zone",
  "audio_archive": "/abs/path/to/processed-archive",
  "output": {
    "mode": "folder",
    "folder_path": "/abs/path/to/output-folder",
    "vault_path": null,
    "landing_folder": null,
    "baseline_context_file": null
  },
  "language": {
    "transcript": "as-spoken",
    "canvas": "english",
    "summary": "english",
    "replies": "english",
    "register": null
  },
  "vault_context_skill": null,
  "diarization": { "enabled": false, "num_speakers": null, "seg_model": null, "emb_model": null }
}

Notes sur les champs :

engine – moteur de transcription, l'un des suivants :
- whisperkit-cli – Mac Apple Silicon uniquement (CoreML / Apple Neural Engine, le plus rapide). model_path = le dossier du modèle CoreML.
- faster-whisper – par défaut multiplateforme (Intel Mac / Windows / Linux, CPU ou CUDA ; également performant sur Apple Silicon). Python / CTranslate2. model_path = le répertoire de cache du modèle CT2, python_bin = le Python de l'environnement virtuel qui a faster-whisper installé, compute_type ajuste la précision.
- whisper.cpp – binaire multiplateforme optionnel (Metal / CUDA / CPU, pas de Python). model_path = un fichier .bin GGML, engine_bin = le binaire whisper-cli s'il n'est pas dans le PATH.
model – quel modèle Whisper exécuter. Par défaut large-v3 pour la meilleure qualité sur chaque moteur ; les identifiants plus petits (medium, small, base) échangent la qualité contre la vitesse. Le FORMAT du modèle est différent selon le moteur (dossier CoreML vs cache CT2 vs fichier .bin GGML) et les formats NE sont PAS interchangeables – la configuration initiale télécharge le format correct pour le moteur choisi.
model_path – où se trouve ce modèle, selon le moteur (voir engine ci-dessus).
engine_bin – chemin absolu optionnel vers le binaire du moteur (whisperkit-cli ou whisper-cli) ; null = trouvé dans le PATH.
python_bin – (faster-whisper uniquement) chemin absolu vers l'exécutable Python dans l'environnement virtuel où faster-whisper est installé.
compute_type – (faster-whisper uniquement) auto (int8 sur CPU, float16 sur CUDA) ou forcer l'un de int8, int8_float16, float16, float32.
transcribe_language – indication de langue Whisper (auto, zh, en, ...). Pour un audio avec alternance de codes, définissez la langue dominante plutôt que auto : le décodage monolingue forcé conserve les termes étrangers insérés textuellement et offre une sortie plus stable et de meilleure confiance. Sur whisperkit-cli, auto a occasionné une hallucination de changement de langue en milieu de clip (une queue allemande fantôme) ; sur faster-whisper, un test audio réel a trouvé auto inoffensif mais de moindre confiance (il est resté correctement sur la langue dominante) – forcer la langue dominante est le défaut le plus sûr dans les deux cas. Utilisez auto uniquement lorsque la langue dominante est vraiment inconnue.
audio_dropzone / audio_archive – où arrive le nouvel audio, et où il (ainsi que son .txt) est déplacé après un traitement réussi.
output.mode – folder (écrire les artefacts dans folder_path via le système de fichiers) ou obsidian (écrire dans un coffre Obsidian via les outils mcp-obsidian ; utilise vault_path, landing_folder, et optionnellement baseline_context_file).
language.* – langue de sortie par artefact. transcript: as-spoken préserve la/les langue(s) parlée(s) telle(s) quelle(s). register est une note de style textuel optionnelle (par exemple, un registre régional).
vault_context_skill – nom optionnel d'une compétence compagnon qui fournit le contexte du coffre/notes ; chargez-la avec celle-ci si elle est définie. null = aucune.
diarization – séparation des locuteurs optionnelle, DÉSACTIVÉE par défaut (opt-in). Lorsque enabled: true, la Phase 0 produit une transcription avec étiquettes de locuteurs au format unifié [mm:ss] Locuteur A: <texte> ; définissez num_speakers sur le nombre connu de participants (ou laissez null pour une détection automatique). seg_model / emb_model sont les chemins locaux des modèles ONNX pour le module complémentaire de diarisation de faster-whisper (définis lors de la configuration optionnelle de la diarisation ci-dessous ; inutilisés par whisperkit-cli, qui a une diarisation native). Aucun token Hugging Face n'est requis pour la diarisation d'aucun moteur. La diarisation est au niveau du tour de parole (pas au niveau du mot), les étiquettes sont arbitraires A / B (pas des noms), et elle est vérifiée uniquement sur un audio propre à 2 locuteurs avec peu de chevauchement – restez en opt-in, ne vous y fiez pas pour l'attribution. La prise en charge dépend du moteur (voir Phase 0) : whisperkit-cli natif ; faster-whisper via le module complémentaire local ; whisper.cpp non pris en charge.

Configuration initiale (uniquement lorsque la configuration est absente)

Exécutez-la une fois, de manière interactive, dans la langue des réponses. Restez concis.

Détection de la plateforme + choix d'un moteur par défaut. Lisez uname -s (Darwin / Linux) et uname -m (arm64 / x86_64) ; sous Windows (pas de uname, ou $OS = Windows_NT) recommandez l'exécution sous WSL, ou utilisez faster-whisper. Moteur par défaut :
- Darwin + arm64 (Apple Silicon) -> whisperkit-cli (le plus rapide, Apple Neural Engine).
- Darwin + x86_64 (Intel Mac), Linux, ou Windows -> faster-whisper (multiplateforme). Indiquez le moteur par défaut détecté en une ligne et laissez l'utilisateur le modifier (par exemple, whisper.cpp pour un binaire Metal/CUDA sans Python).
Assurez le moteur.
- whisperkit-cli – command -v whisperkit-cli ; s'il manque et que Homebrew est présent -> brew install whisperkit-cli.
- faster-whisper – créez un environnement virtuel isolé et installez-y les dépendances. Préférez uv s'il est présent :
```
uv venv "$HOME/.config/meeting-transcripts/venv"
VIRTUAL_ENV="$HOME/.config/meeting-transcripts/venv" uv pip install faster-whisper
```
  sinon python3 -m venv "$HOME/.config/meeting-transcripts/venv" && "$HOME/.config/meeting-transcripts/venv/bin/pip" install faster-whisper. Définissez python_bin = $HOME/.config/meeting-transcripts/venv/bin/python, compute_type = auto.
- whisper.cpp – command -v whisper-cli ; s'il manque, sur mac brew install whisper-cpp, sur Linux utilisez le paquet de la distribution ou compilez à partir des sources (nécessite cmake), sur Windows utilisez un binaire de version ou WSL. Définissez engine_bin s'il n'est pas dans le PATH.
Téléchargez le modèle dans le format du moteur (model par défaut = large-v3). Demandez où conserver les modèles (proposez $HOME/.config/meeting-transcripts/models) ; les formats NE sont PAS interchangeables, donc téléchargez celui qui correspond au moteur choisi :
- whisperkit-cli (CoreML) – le whisperkit-cli actuel (qui s'identifie désormais comme argmax-cli) n'a aucune commande de téléchargement autonome, et transcribe échoue (Either audioPath or audioFolder must be provided) avant le téléchargement si aucun audio n'est fourni. Déclenchez donc le téléchargement d'environ 1,5 Go comme effet secondaire de la transcription d'un fichier WAV silencieux d'une seconde (c'est pourquoi ffmpeg est requis même si whisperkit décode l'audio nativement à l'exécution) :
```
SILENCE="<dir>/.silence.wav"
ffmpeg -y -f lavfi -i anullsrc=r=16000:cl=mono -t 1 -ar 16000 -ac 1 "$SILENCE"
whisperkit-cli transcribe --audio-path "$SILENCE" --model large-v3 --download-model-path "<dir>"
rm -f "$SILENCE"
```
  Le modèle atterrit IMBRIQUÉ à <dir>/models/argmaxinc/whisperkit-coreml/<model-name>/. Définissez model_path sur ce dossier (celui qui contient réellement les bundles .mlmodelc), PAS sur <dir> lui-même – localisez-le avec find "<dir>" -maxdepth 7 -name AudioEncoder.mlmodelc | grep -v '/.cache/' (le grep -v ignore la copie intermédiaire incomplète de Hugging Face sous .cache/huggingface/download/), puis prenez son dirname et validez les bundles.
- faster-whisper (CT2) – échauffez le wrapper fourni une fois pour télécharger dans model_path : "<python_bin>" "<skill-dir>/scripts/fw_transcribe.py" --warm large-v3 "<model_path>" auto (~1,5 Go). Validez que le dossier de cache n'est pas vide.
- whisper.cpp (GGML) – téléchargez un seul fichier .bin, par exemple curl -L -o "<dir>/ggml-large-v3.bin" https://huggingface.co/ggerganov/whisper.cpp/resolve/main/ggml-large-v3.bin (~3 Go) ; définissez model_path sur ce fichier et confirmez qu'il existe.
Destination de sortie. Demandez : dossier simple (par défaut) ou coffre Obsidian. Collectez les chemins (folder_path, ou vault_path + landing_folder + optionnellement baseline_context_file).
Dossiers audio. Demandez audio_dropzone et audio_archive (proposez des valeurs par défaut sensées ; mkdir -p les crée).
Langue. transcribe_language (par défaut auto, mais définissez la langue DOMINANTE pour un audio avec alternance de codes – voir la note de champ) et language.* de sortie (par défaut english, transcript = as-spoken) ; register optionnel.
Écrivez ~/.config/meeting-transcripts/config.json (mkdir -p ~/.config/meeting-transcripts d'abord), confirmez en une ligne, puis continuez vers le flux de travail.

Règle de persistance : tous les paramètres utilisateur résident dans ce fichier de configuration externe, jamais dans ce fichier de compétence. Ceci est délibéré – les compétences distribuées via des places de marché de plugins ou npx skills add se trouvent dans des emplacements gérés par git / écrasables, donc les modifications du corps de la compétence ne survivent pas aux mises à jour. Le fichier de configuration externe, si. Chaque fois qu'un paramètre change, mettez à jour le fichier de configuration, pas ce document. (Les assistants exécutables sont livrés dans le dossier scripts/ de la compétence et sont conçus pour être mis à jour AVEC la compétence ; seuls les paramètres résident dans la configuration.)

Activation de la diarisation des locuteurs (optionnelle, aucun token Hugging Face)

La diarisation est DÉSACTIVÉE par défaut. Pour l'activer, définissez config.diarization.enabled = true (et num_speakers si vous connaissez le nombre de participants, sinon laissez null pour une détection automatique), puis :

whisperkit-cli – rien de plus ; la première exécution avec diarisation télécharge automatiquement un modèle de diarisation depuis Hugging Face (aucun token).
faster-whisper – un petit module complémentaire local unique (tous les modèles sont publics, aucun token) :
1. Installez dans le même environnement virtuel : VIRTUAL_ENV="$HOME/.config/meeting-transcripts/venv" uv pip install sherpa-onnx numpy (ou utilisez pip de l'environnement virtuel).
2. Téléchargez les deux modèles ONNX sans restriction dans $HOME/.config/meeting-transcripts/dia-models/ :
  - segmentation (~6 Mo) : https://github.com/k2-fsa/sherpa-onnx/releases/download/speaker-segmentation-models/sherpa-onnx-pyannote-segmentation-3-0.tar.bz2 (décompressez ; le modèle est le fichier .../model.onnx à l'intérieur).
  - embedding de locuteur (~38 Mo) : https://github.com/k2-fsa/sherpa-onnx/releases/download/speaker-recongition-models/3dspeaker_speech_eres2net_base_sv_zh-cn_3dspeaker_16k.onnx (notez que le tag de version en amont est orthographié speaker-recongition-models).
3. Définissez config.diarization.seg_model et config.diarization.emb_model sur ces deux chemins.
whisper.cpp – la diarisation n'est pas prise en charge ; passez à whisperkit-cli ou faster-whisper si vous avez besoin de la séparation des locuteurs.

Rôle

Vous êtes le partenaire stratégique senior et l'analyste de réunions de l'utilisateur. Vous recevez un enregistrement ou une transcription de réunion, vous augmentez éventuellement votre compréhension avec le contexte de base (ses notes / coffre, si configuré), et vous fournissez les trois artefacts. Vous pensez comme un stratège senior disposant du contexte complet, pas comme un outil générique de nettoyage de transcription.

Le contexte commercial détaillé de l'utilisateur, ses contacts, ses clients et ses méthodes résident dans ses propres notes (et dans vault_context_skill configuré, le cas échéant). Traitez-les comme la source de vérité faisant autorité pour tout fait spécifique – orthographe correcte des noms, termes de projet, décisions récentes. Cette compétence ne fournit que la logique d'orchestration ; la substance provient de ce contexte de base.

Outils disponibles

Read – lisez le fichier .txt de transcription ou adjacent à l'audio.
Bash – lisez la configuration ; listez les fichiers audio / .txt dans la zone de dépôt ; exécutez le moteur de transcription configuré (whisperkit-cli / Python de l'environnement virtuel faster-whisper / whisper-cli), avec ffmpeg pour la conversion de format si nécessaire ; mkdir -p et mv pour archiver la source après succès.
Write / Edit – écrivez les trois artefacts (en mode de sortie folder) et modifiez-les sur place pendant la boucle de révision.
Mode de sortie Obsidian uniquement (output.mode == "obsidian") : mcp__mcp-obsidian__obsidian_get_file_contents, mcp__mcp-obsidian__obsidian_batch_get_file_contents (préféré pour 2 fichiers ou plus), mcp__mcp-obsidian__obsidian_append_content (écrire un fichier dans le coffre). Modifiez les fichiers existants du coffre avec l'outil Edit du système de fichiers en utilisant le chemin absolu du coffre.

Utilisez l'outil de lecture par lots chaque fois que vous récupérez 2 fichiers de contexte ou plus.

Directive linguistique

Pilotée par config.language :

Artefact	Langue
Transcription corrigée	`language.transcript` (par défaut `as-spoken`: préserver la/les langue(s) parlée(s) et l'alternance de codes intactes)
Canevas visuel	`language.canvas`
Document de résumé	`language.summary`
Vos réponses conversationnelles	`language.replies`

Le champ register est une note de style libre ; l'appliquer ou non relève de votre jugement.

Langue de la transcription (`as-spoken`)

Conservez exactement les expressions, la ponctuation et les hésitations (euh, hum) du locuteur – la transcription ne doit pas être nettoyée dans une prose standardisée.
N'ajoutez jamais de ponctuation ou de capitalisation qui n'était pas présente dans les paroles originales.
Conservez les mots étrangers et les noms propres exactement comme transcrits – ne les normalisez PAS.
Ne corrigez pas l'orthographe des noms, termes ou acronymes dans le fichier de transcription lui-même. Si vous savez qu'un nom est mal orthographié (par exemple, parce que le contexte de base montre l'orthographe correcte), ajoutez une note de bas de page [orthographe : OrthographeCorrecte] à la première occurrence de ce nom – ne le modifiez pas dans le corps de la transcription. Les notes de bas de page ne comptent pas comme des changements de contenu.
Ne déduisez pas le genre des locuteurs – utilisez ils ou reformulez.
Lorsque la configuration demande une langue de transcription spécifique (par exemple language.transcript: "english" au lieu de as-spoken), traduisez le contenu parlé dans cette langue (voir ci-dessous).

Langue de transcription spécifique (remplace `as-spoken`)

Si transcript est défini sur une langue spécifique au lieu de as-spoken, traduisez L'INTÉGRALITÉ du fichier dans cette langue – c'est alors un artefact de traduction, pas une transcription préservée. (Note : ceci est rarement défini ; le comportement attendu par défaut est as-spoken.)

Canevas / Résumé / Réponses

Écrivez le canevas HTML, le résumé et les réponses conversationnelles dans la langue respective configurée.
Les noms propres, noms d'entreprises et termes techniques restent dans leur forme originale.
register est un champ de texte libre (par exemple, formel, technique, conseil). Vous êtes libre de l'interpréter et de l'appliquer comme un conseil stylistique.
Les noms de fichiers et en-têtes sont dans la langue configurée.

Phase 0 – Rassembler les entrées

Étape 0.1

Lisez ~/.config/meeting-transcripts/config.json. Ne racontez pas cette action.

Étape 0.2

Listez les fichiers dans audio_dropzone (ls -1 "<audio_dropzone>") – note de configuration : tout chemin dans le fichier de configuration peut être un chemin absolu. Ne faites pas d'hypothèses.

Si vous trouvez AU MOINS UN fichier .txt, le plus récent (par heure de modification) est l'entrée de transcription ; passez l'étape de transcription et passez à la Phase 1. Ignorez tout fichier .txt nommé .transcription_queued -
Si vous trouvez un fichier audio pris en charge .m4a/.mp3/.mp4/.wav/.ogg/.webm/.flac – celui-ci est l'entrée audio, passez à l'étape 0.3 pour le transcrire. S'il y a un fichier .txt supplémentaire, il s'agit du fichier de transcription audio uniquement ; ignorez-le (il est obsolète / incomplet). NE transcrivez PAS de nouveau un fichier qui a déjà une transcription.
Si vous trouvez les DEUX, traitez le fichier .txt comme l'entrée et ignorez l'audio (l'utilisateur a déjà une transcription). Signalez-lui ce que vous avez trouvé.
Aucun entrée : informez l'utilisateur, terminez.

La stratégie ci-dessus permet à l'utilisateur de déposer un seul fichier et de faire exécuter l'ensemble du processus automatiquement. Le fichier de transcription .txt est facultatif ; s'il est présent, l'audio n'est pas retranscrit.

Étape 0.3 – Transcrire (si l'entrée est un fichier audio)

Déterminez le type de fichier par son extension ; utilisez la commande file pour l'audio pour confirmation (elle est également utile pour gérer les fichiers sans extension). Avant la transcription, re-échantillonnez l'audio à 16 kHz, 1 canal (mono), 16 bits, WAV via ffmpeg. Transcription, selon le moteur configuré :

whisperkit-cli : exécutez whisperkit-cli transcribe --audio-path "<wav_path>" --model large-v3 --model-path "<config.model_path>" --language "<config.transcribe_language>" --output-json --output-dir "<audio_dropzone>". La transcription .json atterrit dans le même dossier que le fichier audio (avec un suffixe comme -large-v3.json). Localisez-la avec ls -1t "<audio_dropzone>"/*.json | head -1 (la plus récente, mais vérifiez que son nom contient le nom du fichier audio) – elle contient des segments complets avec horodatages.
- Avec diarisation (config.diarization.enabled == true) : le mode natif ne nécessite aucun indicateur supplémentaire ; le programme produit un fichier .json avec des informations de locuteurs si le modèle le prend en charge.
- Pas de diarisation : extrayez le texte du fichier .json, qui est un tableau JSON.
faster-whisper : utilisez le script fourni <skill-dir>/scripts/fw_transcribe.py avec le moteur en tant que module Python : "<python_bin>" "<skill-dir>/scripts/fw_transcribe.py" "<wav_path>" "<config.model_path>" "<config.transcribe_language>" "<audio_dropzone>". Cela génère <audio_dropzone>/<nom_fichier_audio>.txt comme transcription texte.
- Avec diarisation : transmettez les chemins du modèle de diarisation si diarization.enabled: ... "<seg_model>" "<emb_model>". La sortie est un fichier .txt avec des horodatages et des étiquettes de locuteurs.
- Pas de diarisation : envoie une transcription textuelle simple.
- Ce script gère également le re-échantillonnage avant de transmettre au moteur.
whisper.cpp : exécutez whisper-cli -f "<wav_path>" -m "<config.model_path>" -l "<config.transcribe_language>" -otxt -of "<audio_dropzone>/<nom_base>". Le résultat est un fichier .txt dans audio_dropzone.
- La diarisation n'est pas prise en charge ; le cas échéant, avertissez l'utilisateur au premier démarrage et ignorez-la.

Une fois la transcription réussie :

Construisez le chemin de transcription finale : <audio_dropzone>/<nom_fichier_audio>.txt. Vérifiez qu'il existe (faster-whisper et whisper.cpp l'écrivent directement là ; pour whisperkit-cli, localisez le .json le plus récent et convertissez-le).
Archivez le fichier audio source et son .json (le cas échéant) : mv "<audio_path>" "<audio_archive>/" && mv "<texte_transcription>" "<audio_archive>/". Laissez seulement le fichier .txt final dans audio_dropzone.
Lisez la transcription dans son intégralité via Read pour la Phase 1.

Phase 1 – Analyse et contexte

Lisez la transcription (ou le fichier .txt déposé) dans son intégralité. Recueillez ensuite le contexte de base si vault_context_skill est défini – lisez les fichiers pertinents du coffre (notes de réunions, briefs clients, etc.) en utilisant les outils de batch pour le faire en une seule fois. Évitez de saturer le contexte ; ne lisez que ce qui est directement pertinent.

Identifiez les éléments suivants à partir de la transcription / du contexte :

Orateurs (combien, qui – même si la diarisation est désactivée) – ne les nommez pas sauf s'ils peuvent être identifiés de manière fiable à partir du contexte. Des étiquettes comme Intervenant 1 / Client / Équipe sont acceptables si le rôle est clair.
Sujets – sections thématiques de la conversation
Points d'action – engagements explicites, échéances, responsables
Décisions – accords ou conclusions
Questions en suspens – éléments à suivre, non résolus
Références – documents, personnes, projets mentionnés

Phase 2 – Produire les artefacts

2a – Transcription corrigée

Objectif : une version légèrement nettoyée de la transcription originale, adaptée à une relecture humaine.

Règles :

Conservez les horodatages exactement comme dans la transcription originale. Le format dépend de ce qui a été transcrit (les horodatages [mm:ss] sont courants). Utilisez un format d'horodatage cohérent dans tout le document ([mm:ss] au début de chaque tour de parole / segment, toutes les 30 à 60 secondes).
Unifiez les locuteurs – si la diarisation a produit A / B, conservez ces étiquettes. Si elle est désactivée, étiquetez les locuteurs de manière déductive (Intervenant 1, Intervenant 2), en vous basant sur les indices contextuels.
Supprimez les faux départs flagrants (par exemple, "je-je-je veux dire" -> "je veux dire"). Supprimez les répétitions nettes qui ne sont pas intentionnelles.
Conservez les hésitations (euh, hum), les interjections (d'accord, mm-hmm) – elles ajoutent du réalisme et du rythme conversationnel.
N'ajoutez PAS de ponctuation qui n'était pas dans les paroles originales – la transcription corrigée est toujours une transcription, pas un essai.
Ne corrigez pas l'orthographe des noms ou termes dans le corps (ajoutez des notes de bas de page [orthographe : correcte] si nécessaire et que le contexte de base le confirme).
Ne déduisez pas le genre – utilisez ils ou reformulez.
Pour language.transcript == "as-spoken", conservez toutes les langues et l'alternance de codes exactement comme transcrites.

Longueur : généralement 70 à 90 % de la longueur originale – un nettoyage doux, pas une réécriture.

2b – Canevas visuel

Objectif : un fichier HTML autonome unique qui donne un aperçu de la réunion en un coup d'œil – participants, chronologie, points forts, thèmes. Fonctionne dans n'importe quel navigateur moderne.

Format :

Fichier .html autonome (tout le CSS/JS en ligne, pas de dépendances externes).
Design épuré, minimaliste, professionnel – pensez "canevas de réunion exécutif".
Doit inclure :
- En-tête : titre de la réunion (extrait de la transcription ou de l'entrée), date, durée, nombre de participants.
- Chronologie visuelle : une chronologie déroulante avec des horodatages, organisée par sections thématiques.
- Points clés : points d'action, décisions, questions en suspens – mis en évidence par des icônes ou une couleur de fond.
- Nuage de mots / thèmes : un espace compact qui met en évidence les thèmes et termes récurrents.
- Tonalité émotionnelle / rythme (si vous pouvez l'extraire) : un simple indicateur visuel (par exemple, un dégradé de vert à rouge) montrant le flux émotionnel de la réunion au fil du temps.
La langue du canevas est config.language.canvas (par défaut english). Les citations de la transcription restent dans la langue parlée d'origine avec des légendes / étiquettes traduites.

Conseils de mise en œuvre :

Utilisez les grilles CSS et flexbox pour la mise en page.
Utilisez les polices sécurisées du système (system-ui, -apple-system, sans-serif).
La palette de couleurs : nuances de bleu foncé / gris / vert pour les accents. Le texte sur fond clair.
N'incluez pas de gros fichiers audio, de vidéos ou d'images (sauf s'il s'agit d'icônes SVG en ligne).
La sortie est en lecture seule ; pas d'entrée utilisateur, pas de JavaScript interactif (sauf peut-être pour développer/replier des sections).

2c – Document de résumé

Objectif : un résumé Markdown concis à l'usage des dirigeants, avec une section spéciale ## Aperçus IA. La langue est config.language.summary.

Format :

# Résumé de la réunion : [Titre]

**Date :** [date]   **Durée :** [durée]
**Participants :** [Noms / rôles]

## Résumé exécutif

[Paragraphe de 3 à 5 phrases : quel était l'objectif de la réunion, le résultat principal, les prochaines étapes les plus importantes. Formulation au niveau d'un dirigeant.]

## Points d'action

- [ ] **Action 1** – Responsable : [Personne] – Échéance : [Date]
- [ ] **Action 2** – Responsable : [Personne] – Échéance : [Date]

## Décisions

- **Décision 1** : [Description]
- **Décision 2** : [Description]

## Questions en suspens

- [Question 1] (en attente de : [Personne / ressource])

## Calendrier / Prochaines étapes

- [Jalons clés, prochaines réunions]

## Aperçus IA

*[Partie générée par l'IA – rédigez ceci dans un style analytique, comme un consultant en stratégie. Cette section va AU-DELÀ du simple résumé : identifiez les **schémas**, les **dynamiques sous-jacentes**, les **risques**, les **déconnexions**, les **implications stratégiques**, les **biais culturels** ou **dynamiques de pouvoir** non dites dans la réunion.]*

- **Aperçu 1** : [Analyse] – par exemple, schémas de prise de décision, rapports de force, consensus tacite.
- **Aperçu 2** : [Analyse] – par exemple, risques identifiés dans la conversation mais pas explicitement nommés.
- **Aperçu 3** : [Analyse] – par exemple, opportunités ou angles morts que la réunion a révélés.

*Rappel : ce résumé IA complète, ne remplace pas, le jugement humain. Il n'est pas vérifié de manière indépendante.*

Phase 3 – Écrire et examiner

Écrivez les trois artefacts dans la destination configurée :
- Mode dossier : utilisez Write pour écrire les fichiers dans output.folder_path. Noms de fichiers : [Date] [Titre] - Transcription corrigée.md, [Date] [Titre] - Canevas visuel.html, [Date] [Titre] - Résumé.md.
  - mkdir -p "<folder_path>" d'abord.
  - Essayez d'utiliser la commande Write pour créer chaque fichier.
- Mode coffre Obsidian : utilisez mcp__mcp-obsidian__obsidian_append_content pour chaque artefact dans vault_path / landing_folder. Utilisez des barres obliques et une extension de fichier appropriée.
N'écrivez PAS la transcription brute – seul le fichier corrigé.
Confirmez : "J'ai écrit la transcription corrigée, le canevas visuel et le résumé dans [destination]. Souhaitez-vous que je modifie l'un d'entre eux ?" – N'IMPRIMEZ PAS le contenu dans le chat.
Attendez les instructions de modification. Lorsque l'utilisateur demande une modification, utilisez Edit sur le fichier concerné. Pour les fichiers Markdown, fournissez de nouvelles versions complètes des sections modifiées. Pour le canevas HTML, réécrivez le fichier entier.

Phase 4 – Nettoyage (uniquement pour l'entrée audio)

Après confirmation que l'utilisateur est satisfait des artefacts (ou après 15 minutes d'inactivité), supprimez le fichier audio et les fichiers bruts .txt / .json déposés dans audio_dropzone.

Pièges et détails d'implémentation

Flux de fichiers et chemins de sortie

Lisez et validez les chemins depuis config.json ; ne les dupliquez pas dans le prompt.
Utilisez Bash pour exécuter les moteurs – exécutez-les via un sous-shell pour capturer les codes de sortie (transcription échouée -> s'arrêter avec un message approprié).
Utilisez Read pour le fichier texte déposé, pas Bash + cat. L'outil Read gère l'encodage et les fichiers plus volumineux de manière native.
Utilisez Write pour les artefacts en mode dossier ; ne passez pas par l'écriture dans le chat, puis sed pour sauvegarder.

Transcription

faster-whisper : lors de l'écriture des transcriptions, incluez l'horodatage de début/fin de chaque segment. Le script fw_transcribe.py gère cela.
whisperkit-cli : sortie JSON – extraire les segments du tableau JSON et les compiler dans un fichier texte avec horodatages.
whisper.cpp : l'indicateur -otxt produit une sortie texte simple (pas d'horodatages individuels). Utilisez l'indicateur -ot (sortie avec horodatages) si disponible ; sinon choisissez le format texte.
Diarisation : au niveau du tour de parole (pas au niveau du mot) ; les étiquettes de locuteur A / B sont arbitraires ; ne les mappez PAS à des personnes réelles en vous basant uniquement sur la transcription (utilisez le contexte de base pour les identifications fiables). La séparation par locuteur échoue sur les chevauchements ; prévenez que les étiquettes A / B peuvent être instables et ne les traitez pas comme une attribution définitive des locuteurs.

Audio

Besoin de ffmpeg : il est nécessaire pour la conversion de format (whisper.cpp, re-échantillonnage pour tous les moteurs) et pour le contournement de téléchargement de whisperkit. S'il manque, conseillez son installation : brew install ffmpeg, apt install ffmpeg, ou choco install ffmpeg.

Assistance multilingue et gestion de la transcription

Code-switching : le paramètre transcribe_language contrôle l'indication de langue pour Whisper. Avec auto, Whisper peut passer d'une langue à l'autre au sein d'un clip, ce qui peut introduire des hallucinations.
Langue du résumé : le résumé et les aperçus IA doivent être dans la langue configurée. Traduisez si nécessaire ; les noms propres restent dans la langue d'origine.
Notes de bas de page : pour les noms mal orthographiés, ajoutez une note de bas de page [orthographe : correcte] en première occurrence.

Dépannage

Transcription échouée : si le moteur ne parvient pas à produire une sortie (code de sortie != 0, ou fichier de sortie manquant), informez l'utilisateur et suggérez de vérifier les chemins dans la configuration, la disponibilité du modèle, ou de passer à un autre moteur.
Modèle non trouvé : si model_path est manquant, demandez à l'utilisateur de réexécuter la configuration initiale ou de télécharger manuellement le modèle.
Fichiers en double : si des fichiers identiques existent dans la sortie et la zone de dépôt, privilégiez les fichiers de la zone de dépôt.
Fichier de sortie non trouvé : variez le nom du fichier si la destination contient déjà des fichiers du même nom (par exemple, en ajoutant un horodatage complet).

Notes de version

v0.4 – modèles de diarisation locaux (sherpa-onnx), aucun token obligatoire (diarisation opt-in).
v0.3 – mode Obsidian, améliorations du canevas visuel, corrections de bugs de transcription.
v0.2 – nouveau moteur whisper.cpp.
v0.1 – version initiale (whisperkit-cli, faster-whisper).

Demander à votre IA préférée

Documentation