meeting-report

会议报告

根据 Microsoft Teams .vtt 转录文本生成结构化的法语会议报告，并可选择使用 Teams .csv 出席报告补充内容。

此技能适用于任何项目。它会自动检测 hexagone-monorepo 项目，并在检测到该项目时应用项目专属规则（子领域分类、子文件夹路由、foundation 仅按日期命名）。对于其他项目，则会退回到通用的单文件夹输出方式。

写入报告后，此技能还可以根据报告内容提出后续 GitLab/GitHub 问题（步骤 12）。

前提条件

步骤 1–11 无需外部工具。**步骤 12（可选的问题创建）**使用 Git 平台 CLI——这些属于软性依赖：如果没有安装 CLI 或尚未通过身份验证，步骤 12 会直接跳过，不影响报告。

• gh（GitHub CLI）——仅在需要根据报告创建 GitHub 问题时使用。安装：https://cli.github.com
• glab（GitLab CLI）——仅在需要根据报告创建 GitLab 问题时使用。安装：https://gitlab.com/gitlab-org/cli

何时使用此技能

在用户执行以下操作时激活：

• 在提示词中提供 Teams .vtt 文件的路径
• 说“根据这份 Teams 转录文本创建会议报告”
• 说“生成这次会议的报告”
• 说“将这份转录文本转换成报告”
• 另外提供 Teams .csv 出席文件（可选）

输入

此技能需要用户在提示词中提供一个或两个文件路径：

• 必需：.vtt 文件——WebVTT 格式的 Teams 会议转录文本
• 可选：.csv 文件——Teams 出席报告

检测方式：检查用户提示词中的文件扩展名。如果两种文件都存在，.vtt 是转录文本，.csv 是出席报告。如果只提供一个文件，则必须是 .vtt。

项目模式检测

开始处理前，判断当前工作目录是否属于 hexagone-monorepo 项目。这将决定后续工作流的路由方式。

执行以下检查（满足任意一项即可进入 hexagone-monorepo 模式）：

1. 文件夹布局——docs/reports/foundation/ 和 docs/reports/interoperability/ 均存在
2. Git 远程仓库——git remote -v 中提及 hexagone-monorepo
3. 包名称——根目录的 package.json 中，name 包含 hexagone-monorepo

如果均不匹配 → 通用模式。

用户也可以明确覆盖检测结果：

• “mode générique” / “generic mode” → 强制使用通用模式
• “mode hexagone” → 强制使用 hexagone-monorepo（仅当文件夹布局存在时有效）

生成报告前，用一句简短的话告知用户检测到的模式（例如：“检测到的模式：hexagone-monorepo。”或“检测到的模式：通用模式。”）。

工作流

步骤 1：定位并读取文件

1. 从用户提示词中解析文件路径（查找 .vtt 和 .csv 扩展名）
2. 使用 Read 验证每个文件是否存在
3. 如果没有找到 .vtt → 停止并请用户提供一个
4. 完整读取 .vtt 内容
5. 如果提供了 .csv，则读取其内容

步骤 2：解析转录文本

Teams .vtt 文件结构：

WEBVTT

NOTE
Meeting metadata may appear here (date, title, organizer)

00:00:01.000 --> 00:00:04.000
<v Speaker Name>Speech content</v>

00:00:05.000 --> 00:00:08.000
Anonymous speech without voice tag

提取：

1. 会议日期——按以下顺序尝试：
   • (a) 包含日期格式的 NOTE 标头内容（ISO YYYY-MM-DD 或法语 DD/MM/YYYY）
   • (b) 文件名中的日期格式（例如 20260410_...vtt → 2026-04-10）
   • (c) 以当天日期作为备用值
2. 发言人——解析 <v Speaker Name>...</v> 语音标签（可能不存在）
3. 内容块——每个带时间戳的片段都是一个发言回合

步骤 3：确定参与者

优先顺序：

1. 如果提供了 .csv 出席报告 → 解析该文件并提取 Name 列。Teams 出席 CSV 通常包含 Name、First Join、Last Leave、Duration、Role、Email 等列。## Participants 部分只使用姓名。

2. 否则，如果 .vtt 中存在 <v> 语音标签 → 提取不重复的发言者姓名

3. 否则 → 停止并要求用户提供参与者名单，然后再继续：

   « 转录内容是匿名的，且未提供出席文件。你能给我参与者名单吗？ »

步骤 4：分类子领域（仅限 hexagone-monorepo 模式）

通用模式下跳过此步骤。 通用模式不进行领域分类——报告会放入单个输出文件夹（见步骤 10）。

在 hexagone-monorepo 模式下，使用下表根据转录内容中的领域信号进行分析（关键词匹配不区分大小写）：

文件夹	信号（法语／技术关键词）
foundation/	sprint、rétro、rétrospective、point équipe、stand-up、daily、foundation、équipe foundation
core/	architecture transversale、cross-domain、LDAP、S3A、S3A settings、permissions utilisateur、rôles、authentification
interoperability/	Hexaflux、interopérabilité、interop、HL7、HL7 v2、HL7 v2.5、FHIR、IHE、PAM、ADT、segment、PID、PV1、PV2、NK1、OBX、EVN、MSH、HPK、flux、intégration、message、mapping、broker、Mirth、Rhapsody
gap/	admission、patient、venue、séjour、dossier patient、pré-admission、AMO、AMC、débiteur、couverture sociale、facturation、valorisation、portail patient、ROC、serveur d'actes、actes、urgences、Diapason
grh/	RH、ressources humaines、employé、salarié、contrat、paie、MyRHConnect、RH Dossier
gef/	pharmacie、M21、contentieux、emprunts、trésorerie、HA GHT、immobilisations、achats、fournisseurs、comptabilité générale、Hélios、export comptable
ui-ux/	design、maquette、Figma、atelier UX、atelier UI、wireframe、écran、prototype、UX/UI

分类规则：

分类依据是项目／领域，而不是团队组织归属。Hexaflux 团队在组织上属于 Foundation 团队，但其工作完全围绕 Hexaflux 项目（领域 = interoperability），因此其定期会议应归入 interoperability/，而非 foundation/。始终先检查项目专属信号，再考虑通用的 Foundation 站会规则。

1. 如果会议是 Hexaflux 团队定期会议（提及 « Hexaflux »，或涉及 HL7／互操作范围的每周会议／站会／回顾会）→ interoperability/
2. 否则，如果会议是 Foundation 团队定期会议，讨论横向／跨领域平台工作（sprint、rétro、daily、point équipe、stand-up——不涉及特定项目范围）→ foundation/
3. 区分 Interoperability 和 GAP。 HL7 消息会携带患者数据（PID、PV1、NK1 等），因此 GAP 关键词（patient、admission、séjour、venue）自然也会出现。如果 HL7／互操作信号与 GAP 信号同时出现，则会议讨论的是集成，而非患者业务流程 → 分类为 interoperability/。只有在讨论功能／业务层面（UI、portail patient、facturation、admission 业务工作流），且不涉及技术 HL7／消息层时，才分类为 gap/。
4. 否则，统计每个领域文件夹的关键词匹配数，并选择匹配数最高的文件夹（主导领域）
5. 如果匹配数相同，则优先选择其信号在转录中最先出现的文件夹
6. 如果完全没有匹配信号 → 请用户确认目标文件夹

第 5 步：提取会议标题和 Slug

1. 阅读会议记录开头部分，查找明确提及主题的内容（问候语通常会提到会议标题）
2. 推断一个简洁的法语会议标题（例如：Atelier UX/UI Recherche Patient）
3. 根据标题生成 kebab-case slug：
   • 使用小写字母，且仅包含 ASCII 字符（去除重音符号）
   • 将空格和标点替换为 -
   • 最长约 60 个字符
   • 示例：atelier-ux-ui-recherche-patient

第 6 步：按主题重写内容

风格： 大幅改写，按主题归类，不按时间顺序排列，也不逐字记录。

1. 识别讨论的主要主题——按主题检测，将发言归入不同主题组，而非按发言者顺序排列
2. 对于每个主题，提取：
   • Décisions（决策）——已作出的具体决策（始终作为 ### Décisions 子章节列出）
   • Point d'attention（注意事项）——模糊之处、未解决事项（可选的 ### Point d'attention 子章节）
   • Problèmes identifiés（已发现的问题）——阻碍因素、技术问题、缺失依赖项（可选的 ### Problèmes identifiés 子章节）
3. 使用专业法语撰写：
   • 使用“nous”或非人称语气
   • 积极补全所有缺失的重音符号——Teams 的法语转录在重音符号和标点方面问题严重
   • 删除填充词——「euh」「du coup」「en fait」、重复内容、结巴
   • 在决策条目中的关键术语上使用 **粗体** 强调
4. **目标长度：**完整报告为 800–1500 词
5. 为章节编号：## 1. <主题>、## 2. <主题>，依此类推
6. **不要逐字引用发言者的话。**输出应为综合报告，而非会议记录。

第 7 步：确定是否添加 Mermaid 图表

仅当内容确实适合可视化时才添加 Mermaid 图表。适用场景：

• 多步骤工作流（例如包含 6/8/7 个步骤的计费流程）
• 有明确分支的决策树
• 多个参与方之间的事件顺序（例如入院 → 住院 → 计费）
• 系统间的数据流

优先使用以下图表类型：

• flowchart LR 或 flowchart TD 表示流程和决策
• sequenceDiagram 表示参与方之间的交互
• timeline 表示项目阶段

将图表放在相关主题章节内，而非报告顶部。

**默认不添加图表。**如果不确定，就跳过。通常情况下，报告不需要图表。

第 8 步：汇总报告

使用以下精确模板：

# Compte-rendu — <Type de réunion> <Sujet>

**Date :** DD/MM/YYYY
**Organisateur :** <Nom> (<Rôle>)

## Participants

<Nom1>, <Nom2>, <Nom3>, ...

---

## 1. <Topic 1>

### Décisions

- **<Key term>** : <decision>
- ...

### Point d'attention

<Optional paragraph — only when there is an ambiguity or unresolved item>

### Problèmes identifiés

- <Optional bullet list — only when problems were raised>

---

## 2. <Topic 2>

### Décisions

- ...

---

<...as many topics as needed...>

规则：

• 不添加 YAML front matter
• 正文中的日期使用法语格式 DD/MM/YYYY（只有文件名使用 ISO 格式）
• 参与者必须写在一行中，以逗号分隔；不得使用表格，也不写角色
• 组织者：如果能从转录或 CSV 中识别，则写 **Organisateur :** Nom (Rôle)。如果无法识别，则写 **Organisateur :** À préciser
• 在各主题之间使用 --- 水平分隔线

第 9 步：确定文件名

hexagone-monorepo 模式：

• 基金会团队会议（foundation/ 文件夹）→ YYYY-MM-DD.md（仅日期，不加 slug——每天最多安排一场固定团队会议）
• 其他所有文件夹 → YYYY-MM-DD-<slug>.md

通用模式：

• 始终使用 YYYY-MM-DD-<slug>.md

文件名始终使用 ISO 日期格式 YYYY-MM-DD，与报告正文中使用的法语日期格式 DD/MM/YYYY 不同。

第 10 步：确定输出文件夹并写入文件

hexagone-monorepo 模式：

1. 目标路径：docs/reports/<sub-domain>/<filename>.md
2. 确认子域文件夹存在（ls docs/reports/<sub-domain>/）。如果不存在，则创建该文件夹。

通用模式：

1. 从以下文件夹中选择第一个已存在的文件夹：
   • docs/reports/
   • docs/meetings/
   • meetings/
   • reports/
2. 如果这些文件夹都不存在，则创建 docs/reports/ 并使用该文件夹。
3. 目标路径：<chosen-folder>/<filename>.md

两种模式均适用：

1. 检查是否已有同名文件——如果有，则在写入前追加 -2、-3 等（不得覆盖）
2. 使用 Write 工具写入文件

步骤 10b：生成 HTML 报告（可选）

写入 Markdown 后，检查是否启用了 HTML 生成。查找 .meeting-reports.json 中的 htmlGeneration:true，或 package.json 中的 meetingReports.htmlGeneration。如果未找到，则静默跳过。

如果已启用，生成现代化 HTML，包含：响应式设计、深色／浅色模式切换、用于主题设置的 CSS 变量、适用于 Web 的安全字体、基于 CSS 的图表、按颜色区分的章节。使用 .html 扩展名写入，并采用相同的文件冲突处理方式。如果生成失败，记录警告并继续。

步骤 11：向用户报告

显示简洁摘要：

1. ✓ 模式：hexagone-monorepo 或 generic
2. ✓ 目标路径 3a. ✓ HTML 报告：已生成（已启用时）、已跳过（已禁用时）或失败（附带警告）
3. 单行摘要：（hexagone 模式下的子域）、主题数量、参与者数量
4. 说明触发的任何回退（没有考勤 CSV、没有语音标签、未找到日期因此使用今天的日期、已创建默认文件夹等）
5. 不要运行 git add、git commit 或 git push——用户将在审核后手动提交报告。

然后继续步骤 12。

步骤 12：提出后续问题（可选）

报告写入并汇报后，可选择提出根据报告创建后续 GitLab/GitHub issue。此步骤不得阻止、延迟或更改报告——步骤 11 中的报告已经交付。此步骤在两种模式（generic 和 hexagone-monorepo）下都会运行。

步骤 12a：预检（静默门槛）

运行以下检查。只要有一项失败，就打印一行简短说明原因并停止——不要显示提示：

1. 交互式上下文——如果技能以非交互方式／批处理方式运行，则跳过。
2. 单一平台——当前目录中的 git remote -v 必须解析为恰好一个平台：GitHub 远程地址（github.com）或 GitLab 远程地址。没有远程地址或同时存在两个平台 → 跳过。
3. CLI 已就绪——必须已安装并通过身份验证的对应 CLI：GitHub 使用 gh auth status，GitLab 使用 glab auth status。未安装或未通过身份验证 → 跳过。
4. 高质量候选项——至少有一个高质量候选项通过步骤 12b 筛选。没有候选项 → 跳过。

跳过提示（单行，法语），例如：「Aucune issue proposée : pas de remote git détecté.」／「Aucune issue proposée : glab non authentifié.」／「Aucune issue proposée : aucune décision actionnable dans le compte-rendu.」

步骤 12b：提取候选问题

从刚刚写入的报告（而非原始转录）中提取可执行的后续事项：

• 主要来源：### Problèmes identifiés 和 ### Point d'attention 下的条目。
• 只有当 ### Décisions 下的条目意味着需要后续工作时，才从中提取（例如「决定迁移 X」→ 将迁移列为候选项）。已确定的事实不属于 issue。
• 质量筛选——剔除纯信息类、延期事项（「之后再讨论」）或没有可执行动词的条目。优先选择少量明确的候选项，而不是大量模糊的候选项。
• 对每个保留的条目，构建：
  • 标题——用祈使句法语改写，不能照抄原条目，长度 ≤ 约 80 个字符，并剔除控制字符和多余换行
  • 建议类型——Problèmes identifiés → bug；Point d'attention / Décisions → task
• 最多保留前 4 项（AskUserQuestion 的选项数量上限）。如果筛选后还有更多候选项，只保留信号最强的 4 项，并告知用户可以重新运行以创建其余项。

步骤 12c：展示并选择

使用单个 AskUserQuestion，并设置 multiSelect: true：

• 问题标题明确写出确切目标：「Les issues seront créées sur <owner/repo> (<host>). Lesquelles créer ?」——这既用于选择，也用于确认目标。
• 每个候选项对应一个选项：标签 = 标题，描述 = 来源章节 + 主题 + 建议类型。
• 用户可选择零项或多项。如果用户未选择任何项或关闭提示 → 不创建任何内容，并报告已完成。

步骤 12d：创建已选问题

对于每个选中的候选项，直接调用平台 CLI——不要通过 gitlab-issue / github-issues 技能（它们是交互式控制台，会重新询问此处已经确认的信息）：

1. 先搜索重复项： gh issue list --search "<title>" / glab issue list --search "<title>"。如果存在内容近乎相同且仍处于开放状态的问题，展示该问题，并让用户确认或跳过此候选项。
2. 创建：
   • GitHub：gh issue create --title "<title>" --body "<body>"
   • GitLab：glab issue create --title "<title>" --description "<body>"
3. 正文 = 对事项的 2-3 行法语概述 + 指向报告文件的相对链接。绝不要将原始转录摘录或可识别患者身份的内容粘贴到正文中——详细内容保留在本地报告中。
4. 标签——只有在现有项目标签明显适用时才使用（例如 bug）。绝不要创建新标签；如果没有合适的标签，则省略。
5. 始终使用检测到的主机 / 项目——绝不要使用硬编码默认值。

步骤 12e：报告结果

逐个问题打印结果：已创建问题的 URL；对于任何失败，打印候选标题 + 错误信息。提供重新处理失败或未展示项目的选项。

步骤 12 说明：

• 此步骤会产生网络副作用（创建问题），但仍然不执行 git 操作——不提交、不推送。
• v1 不会在运行之间保留状态：对同一份转录重新运行此技能，会再次提出相同的候选项。默认不选择任何项目，并在创建前搜索重复项，是相应的防护措施。

重要说明

• 默认与项目无关。 只有检测到 hexagone-monorepo 项目时，才进行子域分类并路由到 docs/reports/<sub-domain>/。
• 不进行脱敏或假名化。 团队会议被视为内部可信内容。报告中可能会逐字出现姓名和内容。
• 不执行 git 提交或推送。 此技能会写入报告文件；用户手动提交和推送。步骤 12 可能会创建 GitLab / GitHub 问题——这是一个可选、受控的网络副作用——但绝不会运行 git add、git commit 或 git push。
• 问题创建为可选、受控且范围有限。 步骤 12 会根据报告提出简要的后续问题，绝不会自动创建任何问题（默认不选择任何项目）。深入调查的单一 Bug 问题应交由 triage-issue 技能处理，而不是在此处处理。
• 大幅改写——不要照录。 输出应是主题综合，而非按时间顺序整理的会议记录。
• 积极修正法语重音符号。 Teams .vtt 法语转录常常缺少重音符号和标点。
• 仅在 hexagone-monorepo 模式下使用 Foundation 日期命名规则。 通用模式始终使用 YYYY-MM-DD-<slug>.md。
• Mermaid 是可选项，应少用，且仅在有帮助时使用。 默认不绘制图表。
• 参与者信息回退顺序： 先查 .csv，再查 <v> 语音标签，然后询问用户。绝不要臆造姓名。
• 绝不要覆盖现有报告。 如果同名文件已存在，则追加数字后缀。

示例

示例 1：通用项目，简单会议

User: crée un compte-rendu de cette transcription Teams /tmp/kickoff.vtt

→ Detection: no docs/reports/foundation/ found → generic mode
→ Skill reads the .vtt
→ Parses <v> voice tags → 5 speakers
→ Extracts date 2026-04-22
→ Picks docs/reports/ (exists) as output folder
→ Writes docs/reports/2026-04-22-kickoff-projet.md
→ Reports: « Mode détecté : générique. »

示例 2：通用项目，尚无 docs/reports 文件夹

User: génère le compte-rendu /tmp/atelier.vtt /tmp/attendees.csv

→ Detection: generic mode
→ No docs/reports/, no docs/meetings/, no meetings/, no reports/ → creates docs/reports/
→ Writes docs/reports/2026-04-15-atelier-architecture.md
→ Reports: « Mode détecté : générique. Dossier docs/reports/ créé. »

示例 3（hexagone-monorepo）：UX/UI 工作坊，附带考勤 CSV

User: crée un compte-rendu de cette transcription Teams /tmp/atelier_recherche_patient.vtt /tmp/attendees.csv

→ Detection: docs/reports/foundation/ + interoperability/ exist → hexagone-monorepo mode
→ Skill reads both files
→ Extracts date from .vtt NOTE header: 2026-03-18
→ Participants from .csv: Chloé Julenon, Richard Gill, Adrien Marcos, Myriam Fatoux, Damien Battistella
→ Detects ui-ux signals (atelier, écran, maquette, recherche patient)
→ Classifies as ui-ux/
→ Writes docs/reports/ui-ux/2026-03-18-atelier-recherche-patient.md

示例 4（hexagone-monorepo）：Foundation 团队冲刺回顾，无 CSV

User: génère le compte-rendu de cette réunion /tmp/sprint_review.vtt

→ Detection: hexagone-monorepo mode
→ Parses <v Speaker> voice tags → extracts 4 speakers
→ Extracts date from NOTE header: 2026-04-10
→ Detects foundation signals (sprint, rétro, point équipe)
→ Classifies as foundation/
→ Uses date-only naming
→ Writes docs/reports/foundation/2026-04-10.md

示例 5：匿名转录，无 CSV（任何模式）

User: transforme cette transcription en rapport /tmp/meeting.vtt

→ No <v> tags found
→ No .csv provided
→ Stops and asks: « La transcription est anonyme et aucun fichier de présence n'est fourni. Peux-tu me donner la liste des participants ? »
→ Waits for the user, then continues with the provided names

示例 6（hexagone-monorepo）：Hexaflux 周会——讨论 HL7，并非 GAP

User: crée un compte-rendu /tmp/hexaflux_weekly.vtt

→ Detection: hexagone-monorepo mode
→ Detects HL7 / ADT / PID / PV1 / NK1 / OBX / segment / mapping signals
→ Patient and admission keywords are present BUT tied to HL7 message segments, not business workflows
→ Applies the interop-vs-gap disambiguation rule → picks interoperability/
→ Writes docs/reports/interoperability/2026-04-17-hexaflux-weekly.md

示例 7：报告后的后续问题提议（GitHub）

User: génère le compte-rendu /tmp/sprint.vtt

→ Report written to docs/reports/2026-05-12-sprint-planning.md and reported (Steps 1–11)
→ Step 12a preflight: git remote → github.com/Dedalus-ERP-PAS/foo, `gh` authenticated → pass
→ Step 12b: derives 3 quality candidates from Problèmes identifiés + Point d'attention
→ Step 12c: AskUserQuestion « Les issues seront créées sur Dedalus-ERP-PAS/foo (github.com). Lesquelles créer ? »
→ User selects 2 of 3
→ Step 12d: `gh issue create` ×2 (duplicate search first, no label invented)
→ Step 12e: reports the 2 created issue URLs

示例 8：跳过问题步骤——没有 git 远程地址

User: transforme cette transcription en rapport /tmp/atelier.vtt

→ Report written and reported (Steps 1–11)
→ Step 12a preflight: `git remote -v` empty → no platform
→ Prints « Aucune issue proposée : pas de remote git détecté. » and stops