技能介绍

问题：孤立的会议纪要无法承载决策演进

传统会议纪要通常写成一次性文本，会后很难回答几个关键问题：上轮已确认的事项这次有没有被推翻？某个结论是在哪一版材料中确立的？如果两轮讨论的措辞不同，它们是同一个决策还是两件事？这些问题在需要审计或回溯时尤其棘手，因为纪要之间缺乏版本关系，变更只能靠人工比对。

Meeting Git 把会议视为连续的决策版本，而不是彼此孤立的纪要。它为每次会议生成结构化的 Meeting Commit，让事项的新增、修改、状态迁移都成为可校验、可追溯的版本操作。

核心工作流：LLM 提取，代码裁定

技能的核心思路是让 LLM 和确定性脚本各司其职：

语义提取：Agent 先阅读按来源和会议顺序组织的会议材料，提取 Candidate Item，生成 MeetingCommitDraft。脚本不代替这一步做语义理解。
确定性门禁：Draft 必须携带 parent_commit_id，随后由确定性脚本完成事项匹配、ID 转换和跨历史碰撞检查。若输出 applied: false，需要修正整个 Draft 后重新处理，而不是只提交部分 Candidate。
状态迁移与 Diff：Diff 和当前 HEAD 由确定性规则计算，LLM 不自行决定状态迁移。无法确定的匹配会保留为开放 CONFLICT，不会被自动合并或解决。
证据回溯：每个变化前后版本都附带可回溯的 Evidence。没有证据的事项不会被标记为 CONFIRMED。

边界与注意点

技能接受 Markdown、TXT 和 JSON Demo 材料。生产会议时间必须来自材料或用户明确提供，缺失时应先询问，不能伪造。腾讯会议数据必须先由官方 Skill/MCP 读取，再经确定性导入脚本转换，手写或非规范 JSON 会被拒绝。输出始终固定为四个部分：HEAD、Changes、Conflicts、Evidence，不能替换为普通会议摘要。此外，写操作必须确认，冲突不得自动解决，也不能基于该技能扩展 Web、SaaS、数据库或权限系统。