meeting-notes

meeting-notes 技能概览

meeting-notes skill 是一个轻量的格式化与结构化助手，适合把粗糙的会议转录、聊天记录或人工笔记整理成清晰的会议纪要。它真正擅长的不是做 transcription，而是帮助 agent 把会议过程整理成可执行、可追踪的记录，包括 agenda、讨论要点、决策、action items、next steps 和 parking lot。

meeting-notes 最适合哪些场景

当你已经有会议内容，只是需要快速产出一份格式统一的结果时，就很适合用 meeting-notes：

• 团队同步会总结
• 项目进展会议记录
• 干系人会议纪要
• action item 跟踪
• 讨论结束后的决策留档

它尤其适合更看重稳定结构、而不是复杂分析的人。

meeting-notes 和通用 prompt 的区别

普通的“总结这场会议”prompt，往往会漏掉负责人、截止时间或明确的决策。meeting-notes skill 给模型提供了一套固定的 meeting notes 模板，让输出更容易浏览、分享和跟进。对大多数人来说，这种一致性就是它值得安装的核心原因。

用户安装前通常最关心什么

大多数在评估 meeting-notes skill 的用户，通常会先看这几点：

• 相比直接写普通 prompt，是否真的省时间
• 能不能处理凌乱的原始笔记
• 是否能把 action items 提取得足够清楚
• 会不会过于死板，不适合自己的会议风格

简短地说：如果你的主要问题是结构混乱、后续难跟进，它就很有用；但它不能替代准确、完整的原始材料。

这个技能不做什么

meeting-notes 不会凭空补出会议 intelligence。如果输入里没有参会人、决策、负责人或截止日期，输出依然会存在空缺，或者只能给出带占位性质的内容。它也没有附带 repo 侧的脚本、规则或参考文件来强制执行更深层的工作流。

如何使用 meeting-notes 技能

如何安装 meeting-notes

使用下面的命令从仓库安装 meeting-notes skill：

npx skills add Shubhamsaboo/awesome-llm-apps --skill meeting-notes

安装后，只要你的请求明确涉及会议记录、会议纪要、action items 或讨论总结，agent 就可以调用这个 skill。

仓库里优先看什么

这个 skill 非常简单，建议先看：

• awesome_agent_skills/meeting-notes/SKILL.md

这个 skill 目录下没有额外的 README.md、metadata.json、rules/ 或辅助脚本，所以它的价值基本都集中在输出结构本身，以及你是否会正确使用这套结构。

meeting-notes 需要什么输入

当你提供以下信息中的至少一部分时，meeting-notes skill 的效果最好：

• 会议标题
• 日期和时间
• 参会人
• 粗略 agenda
• transcript、要点式笔记或聊天记录
• 明确写出的决策
• 已知的 action items、负责人和截止时间

如果你只贴一小段模糊描述，结果大概率会是泛泛而谈的摘要；如果你给的是原始但信息充足的笔记，这个 skill 的实用性就会明显提高。

最适合 meeting-notes 使用的输入格式

适合 meeting-notes usage 的源材料包括：

• 来自 Zoom、Meet 或 Teams 的 transcript
• 会议过程中记录的 bullet notes
• 总结讨论内容的 Slack thread
• 已经清理到能看出主题的语音转写内容

当原始材料虽然杂乱、但信息密度高时，这个 skill 尤其有价值。

把模糊请求改成高质量的 meeting-notes prompt

弱请求：

Summarize this meeting.

更强的请求：

Use the meeting-notes skill to turn these raw notes into formal meeting minutes. Keep the standard sections for Agenda, Key Discussion Points, Decisions Made, Action Items, Next Steps, and Parking Lot. If an owner or deadline is missing, mark it as TBD instead of inventing one. Source notes: [paste notes]

为什么这样更有效：

• 它明确调用了结构模板
• 它阻止模型虚构负责人和日期
• 它提前规定了缺失信息的处理方式

一个实用的 prompt 模板

如果你想让 meeting-notes usage 更稳定，可以直接套用下面这个模式：

Use the meeting-notes skill.
Meeting title: [title]
Date/time: [date/time]
Attendees: [names]
Goal: convert the following raw notes into concise meeting minutes.
Requirements: capture decisions separately from discussion, create an action-items table, and flag missing owners or deadlines as TBD.
Raw notes/transcript: [paste content]

这样能给模型足够的上下文，更容易直接产出一版干净的初稿。

从原始笔记到最终纪要的推荐流程

一个比较实用的 workflow 是：

1. 粘贴原始笔记或 transcript。
2. 明确要求使用 meeting-notes skill 输出结构化结果。
3. 先检查 Decisions Made 部分。
4. 再核对 Action Items 表格里的负责人和截止日期。
5. 如有缺口，继续要求修订：补全信息、压缩讨论内容、或把行动项写得更具体。
6. 最好在 24 小时内发送或归档最终版本。

这个顺序和 skill 的设计重点一致：它更强调结果与后续执行，而不是逐字复述。

如何处理缺失信息

糟糕会议纪要最常见的问题，就是模型在你没注意时“默默猜测”。你应该明确告诉模型：

• 保留不确定性
• 未知负责人或截止时间统一写成 TBD
• 含糊不清的事项不要放进 Decisions Made
• 尚未解决的话题移到 Parking Lot

这几条看似简单，但会显著提高结果的可信度。

meeting-notes 在团队工作流中的位置

如果你的团队已经有固定会议，但缺少一致的文档化方式，meeting-notes skill 会非常合适。它尤其适用于：

• 内部项目会议
• 有明确决策输出的例行 standup
• 跨职能同步会
• 面向客户或干系人的回顾纪要

但如果你的团队需要的是完整 transcript 分析、情绪识别，或合规级别的会议记录，它的价值就没那么高了。

meeting-notes 技能常见问题

如果我自己会写 prompt，还有必要安装 meeting-notes 吗？

通常有必要，前提是你会反复使用同一种 meeting-notes 格式。这个 skill 能节省你反复写 prompt 的时间，也能让输出更统一。如果只是偶尔用一次，手写 prompt 也许就够了。

meeting-notes 适合新手吗？

适合。meeting-notes guide 本身就很简单，因为这个 skill 的核心就是一套清晰模板加上一些最佳实践。对新手来说，默认结构尤其有帮助，特别是它把 discussion、decisions 和 action items 明确分开。

什么情况下不该用 meeting-notes？

以下情况建议跳过 meeting-notes：

• 你需要逐字 transcript
• 原始材料残缺到无法识别决策
• 你想要的是深度分析，而不是会议纪要
• 你的组织已经有一套非常严格、且和这个模板冲突的会议纪要格式

meeting-notes 会自动生成 action items 吗？

它可以从输入中提取“可能的” action items，但质量完全取决于源材料。如果你的笔记里没有明确写谁负责、何时截止，模型就不该自行补全这些信息。想要更好的结果，最好直接提供明确的 owner 和 deadline。

meeting-notes 和普通摘要有什么不同？

普通 summarization 的目标是压缩内容；meeting-notes for Meeting Notes 更接近运营型文档整理：讨论了什么、决定了什么、谁负责什么、接下来要做什么。若这份纪要会直接推动后续工作，这个区别就非常关键。

如何改进 meeting-notes 技能效果

提供更好的源笔记，而不只是更长的内容

想提升 meeting-notes 输出质量，最快的方法不是一股脑贴更多内容，而是给更清晰的输入：

• 尽量用带发言人归属的 bullets
• 明确写出 decision statements
• 使用清晰的负责人姓名
• 用统一格式记录 due dates

很多时候，一份更短但更清楚的笔记，会比一整段噪声很高的 transcript dump 更好用。

明确告诉技能哪些内容不能编

可以加上这样的约束：

Do not fabricate attendees, decisions, owners, or deadlines. Use TBD when missing.

这能减少 meeting-notes usage 中最常见的失败模式：看起来很自信，但其实没有依据的细节。

强制生成更有执行性的 action items

如果 action items 写得太虚，可以这样让它重写：

Rewrite the action items so each one contains a concrete task, one owner, one due date or TBD, and a status.

当第一版里出现“follow up”或“look into it”这种过软、不可执行的任务时，这个方法特别有效。

把决策和开放讨论分开

另一个常见问题，是把尚未达成结论的争论混进最终结果里。你可以这样改进输出：

Only include items in Decisions Made if the source clearly shows agreement or approval. Move unresolved points to Parking Lot or Next Steps.

这一个指令，就能让 meeting-notes skill 在真实团队使用中更值得信赖。

再做一轮面向分发的优化

第一版完成后，建议再做一次 refinement：

Shorten discussion bullets, keep all decisions and actions, and make the output ready to send to attendees.

这样通常能得到一版更适合直接分享的纪要，同时又不会丢掉责任归属和后续行动。

按你的团队运作方式调整模板

如果你的会议节奏快、偏战术执行，就缩短 Key Discussion Points，把重点放在 Action Items。如果你的会议更偏战略讨论，就保留更完整的讨论要点和决策依据。这个 skill 的价值来自结构化，但具体的轻重比例，仍然应该按你团队的实际需求来调。