mcpField
M
meeting-minutes

meeting-minutes

github.com/github生产力40.5k9.9k 次安装今天更新
代码仓库

关于 meeting-minutes

meeting-minutes 是一项为时长不超过 60 分钟的内部会议生成结构化纪要的技能，适用于将讨论、转录稿、录音或笔记整理成简明记录的团队。它侧重决策和可跟踪的行动项。

主要功能

  1. 01收集会议详情和参考材料
  2. 02记录出席情况、决策及理由
  3. 03为行动项注明负责人和期限
  4. 04按固定纪要结构组织内容
  5. 05标记未决事项和缺失信息

适用场景

  1. 01根据会议转录稿起草纪要
  2. 02将同步或规划笔记整理为行动项
  3. 03记录设计评审中的决策
  4. 04为内部会议准备简明跟进记录

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/github/awesome-copilot --skill meeting-minutes

安装后在 Claude Code 中输入/meeting-minutes确认已加载。

详细介绍

会议纪要 Skill — 简短内部会议

目的 / 概述

此 Skill 为时长不超过 60 分钟的内部会议生成高质量、一致的会议纪要。输出内容力求清晰、可执行，并便于转换为任务跟踪工具（例如 GitHub Issues、Jira）。生成的纪要优先呈现决策和行动项，以便团队能够快速从讨论转向执行。

何时使用

在以下情况下使用此 skill：

  • 时长较短的内部同步会、站会、设计评审、问题分诊、规划会或临时会议
  • 需要简要记录决策、已分配的行动项和后续跟进事项的场景
  • 从实时会议、转录文本、录音或笔记创建标准化纪要文档

操作工作流

阶段 1：信息收集（起草之前）
  • 获取会议元数据：标题、日期、开始/结束时间（或时长）、组织者和目标受众。
  • 确认可用输入：议程、幻灯片、录音、转录文本或原始笔记。
  • 如果缺少关键细节，在生成纪要前最多提出 3 个澄清问题（见下方“信息确认”）。
阶段 2：记录（会议期间 / 会议结束后立即）
  • 记录出席者和缺席者。
  • 按议程项记录简要笔记，如有可能附上时间标记。
  • 记录明确的决策、理由摘要（1–2 句话）和行动项（负责人 + 截止日期）。
阶段 3：起草
  • 按照下方严格纪要结构生成纪要。
  • 确保每个行动项都包含负责人、截止日期（或时间范围），并在适用时包含验收标准。
  • 在“待议事项”中标记未解决的问题或需要跟进的事项。
阶段 4：审核与发布
  • 如有可能，将草稿发送给会议组织者或指定审核人进行快速核验（24 小时内）。
  • 将最终纪要及时发布到约定渠道（共享驱动器、仓库、工单或电子邮件），并可选地在团队跟踪工具中创建任务。

信息确认（必需的澄清问题）

在生成纪要之前，如果缺少以下任何信息，Agent 必须最多提出三个澄清问题：

  • 会议标题、日期、开始时间（或时长）和组织者是什么？
  • 是否有议程或转录文本/录音可供参考？如果有，请提供。
  • 谁应被指定为纪要的审核人或批准人？

如果用户回复“没有转录文本”或“没有议程”，继续执行，但将来源材料标记为“临时笔记”，并标记潜在缺口。

严格纪要结构（输出结构）

你必须按照以下确切结构生成会议纪要。如果信息不可用，请使用 TBD 或 Unknown，并说明如何获取。

1. 元数据
  • 标题：
  • 日期（YYYY-MM-DD）：
  • 开始时间（UTC）：
  • 结束时间（UTC）或时长：
  • 组织者：
  • 地点 / 虚拟链接：
  • 纪要作者（Agent 或个人）：
  • 分发名单（谁接收纪要）：
2. 出席情况
  • 出席：[姓名 + 角色列表]
  • 请假 / 缺席：[列表]
  • 记录人 / 纪要员：[姓名或“Agent”]
3. 议程

按顺序列出议程项的要点列表：

  • 事项 1：简短标题
  • 事项 2：简短标题
  • …
4. 摘要

用一段简洁文字（1–3 句话）概括会议目标和总体结果。

5. 已做出的决策

每项决策单独列为一个要点：

  • 决策 1：决策陈述。
    • 决策 / 批准人：[姓名或小组]
    • 理由（1–2 句话）：简要原因。
    • 生效日期（如适用）：YYYY-MM-DD
  • 决策 2：…
6. 行动项

表格式要点；必须包含负责人和截止日期：

  • [ID] 行动：简短描述
    • 负责人：姓名（团队）
    • 截止日期：YYYY-MM-DD 或 "ASAP" / 时间范围
    • 验收标准：（完成此行动的标准）
    • 关联产物 / 工单：（可选 URL 或工单 ID）

示例：

  • [A1] 为功能 X 起草部署运行手册
7. 按议程项的备注

简短、事实性、时间戳可选：

  • 议程项 1：标题
    • 关键要点：
      • 要点 A（时间戳 00:05）
      • 要点 B（时间戳 00:12）
    • 未决问题 / 疑问：
      • Q1：问题文本（如已分配，注明负责人）
  • 议程项 2：...
8. 停车场 / 未解决事项
  • 事项：简短描述
    • 搁置原因 / 下一步：
    • 建议负责人或解决的下次会议
9. 风险 / 阻碍（如有）
  • 风险 1：简短描述、影响、缓解负责人
  • 风险 2：...
10. 下次会议 / 后续跟进
  • 建议日期 / 时间（如有）
  • 下次会议的目标
11. 附件 / 参考资料
  • 议程文档：URL
  • 幻灯片：URL
  • 转录 / 录音：URL
  • 相关工单：URL 或 ID 列表
12. 版本与变更日志
  • 版本：1.0
  • 最后更新：YYYY-MM-DDTHH:MM:SSZ
  • 变更：编辑的简短说明及编辑人

风格与质量规则

  • 保持会议纪要简洁：对于时长 <= 30 分钟的会议，总长度通常应不超过 1 页 A4；对于接近 60 分钟的会议，不超过 2 页。
  • 使用平实语言和项目符号列表以提高可读性。
  • 将决策和行动项放在文档顶部。
  • 不要包含推测性语言或未经证实的说法。如果有不确定的内容，请标记为 TBD 并注明缺失信息的来源。
  • 使用一致的时间戳和 ISO 8601 日期（YYYY-MM-DD 或完整的 UTC 时间戳）。

应该做 / 不要做

应该做：

  • 为每个行动项包含负责人和截止日期。
  • 尽可能为行动项提供验收标准。
  • 链接到产物（工单、幻灯片、录音）以实现可追溯性。
  • 如果会议纪要包含重大决策，发送草稿以供快速审阅。

不要做：

  • 遗漏决策或行动项——这些是会议纪要的主要价值。
  • 将个人观点与事实混在一起。将评论明确标记为“观点”或将其排除。
  • 发布讨论期间收集的原始 PII，除非有必要且已获授权。

示例提示词（用于 Copilot / Agent）

从转录生成会议纪要的提示词：

“根据以下会议转录生成会议纪要。会议标题：‘Platform Weekly Sync’。日期：2026-02-10。时长：45 分钟。组织者：Priya（平台负责人）。转录：<粘贴转录>。遵循 Strict Minutes Schema。突出决策，并在有暗示时创建包含负责人和截止日期的行动项。”

从笔记生成会议纪要的提示词：

“我有一次 30 分钟设计评审的原始笔记。标题：‘Feature Y Design Review’。日期：2026-02-11。笔记：<粘贴笔记>。按照 Strict Minutes Schema 生成简洁的会议纪要。如果关键字段缺失，最多提出 3 个澄清问题。”

快速模板（可复制）

简洁会议纪要模板（短）：
- Title:
- Date:
- Organizer:
- Present:
- Summary:
- Decisions:
  - Decision 1 — Who — Effective:
- Action Items:
  - [A1] Action — Owner — Due — Acceptance Criteria
- Next Steps / Next Meeting:
详细会议纪要模板（完整 schema）：

使用上面的 Strict Minutes Schema。

生成的会议纪要的验证与验收标准

生成的会议纪要文档在以下情况下可接受：

  • 包含元数据、参会人员、决策和行动项部分。
  • 每个行动项都有指定的负责人和截止日期或明确的时间范围。
  • 所有重大决策都已记录，并至少包含 1 行理由。
  • 附件或参考资料已列出，或明确标记为 None。
  • 文档是事实性的；不确定的项目标记为 TBD。

评论

支持 Markdown