meeting-minutes-taker by daymade/claude-code-skills
npx skills add https://github.com/daymade/claude-code-skills --skill meeting-minutes-taker通过迭代审查,将原始会议转录稿转化为全面、基于证据的会议纪要。
预处理(可选但推荐):
doc-to-markdown 技能先将 .docx/.pdf 转换为 Markdown(保留表格/图片)transcript-fixer 技能修复 ASR/STT 错误context.md 以进行准确的发言人识别核心工作流程:
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
根据转录稿内容自动生成输出文件名:
模式:YYYY-MM-DD-<主题>-<类型>.md
| 组件 | 来源 | 示例 |
|---|---|---|
| 日期 | 转录稿元数据或首次提及的日期 | 2026-01-25 |
| 主题 | 主要讨论主题(2-4 个单词,kebab-case) | api-design, product-roadmap |
| 类型 | 会议类别 | review, sync, planning, retro, kickoff |
示例:
2026-01-25-order-api-design-review.md2026-01-20-q1-sprint-planning.md2026-01-18-onboarding-flow-sync.md在写入前请用户确认建议的文件名。
复制此清单并跟踪进度:
会议纪要进度:
- [ ] 步骤 0(可选):使用 transcript-fixer 预处理转录稿
- [ ] 步骤 1:读取并分析转录稿
- [ ] 步骤 1.5:发言人识别(如果转录稿包含"发言人 1/2/3")
- [ ] 分析发言人特征(字数、风格、主题焦点)
- [ ] 与 context.md 团队目录匹配(如果提供)
- [ ] 向用户展示发言人映射以进行确认
- [ ] 步骤 1.6:生成智能文件名,请用户确认
- [ ] 步骤 1.7:质量评估(可选,影响处理深度)
- [ ] 步骤 2:多轮生成(使用 Task 工具的并行子代理)
- [ ] 创建转录稿特定目录:<output_dir>/intermediate/<transcript-name>/
- [ ] 并行启动 3 个 Task 子代理(单条消息,3 次 Task 工具调用)
- [ ] 子代理 1 → <output_dir>/intermediate/<transcript-name>/version1.md
- [ ] 子代理 2 → <output_dir>/intermediate/<transcript-name>/version2.md
- [ ] 子代理 3 → <output_dir>/intermediate/<transcript-name>/version3.md
- [ ] 合并:UNION 所有版本,积极包含所有图表 → draft_minutes.md
- [ ] 最终:将草稿与转录稿比较,添加遗漏项
- [ ] 步骤 3:自我审查完整性
- [ ] 步骤 4:将草稿提交给用户进行人工审查
- [ ] 步骤 5:跨 AI 比较(如果用户提供外部 AI 输出)
- [ ] 步骤 6:根据人工反馈进行迭代(预计多轮)
- [ ] 步骤 7:人工批准最终版本
注意:<output_dir> = 最终会议纪要将保存的目录(例如,project-docs/meeting-minutes/)
注意:<transcript-name> = 从转录稿文件派生的名称(例如,2026-01-15-product-api-design)
分析转录稿以识别:
触发条件:转录稿仅包含通用标签,如"Speaker 1"、"Speaker 2"、"发言人1"等。
方法(受 Anker Skill 启发):
针对每个发言人,分析:
| 特征 | 寻找内容 |
|---|---|
| 字数 | 发言总字数(高 = 高级/领导,低 = 观察者) |
| 发言次数 | 发言次数(频繁 = 积极参与者) |
| 平均发言长度 | 每次发言的平均字数(长 = 主讲人,短 = 回应者) |
| 填充词比例 | 填充词百分比(对/嗯/啊/就是/然后)- 低 = 准备充分的发言人 |
| 发言风格 | 正式/非正式,技术深度,决策权威 |
| 主题焦点 | 他们讨论最多的领域(后端、前端、产品等) |
| 互动模式 | 其他人是否向他们提问?他们是否分配任务? |
示例分析输出:
Speaker Analysis:
┌──────────┬────────┬──────────┬─────────────┬─────────────┬────────────────────────┐
│ Speaker │ Words │ Segments │ Avg Length │ Filler % │ Role Guess │
├──────────┼────────┼──────────┼─────────────┼─────────────┼────────────────────────┤
│ 发言人1 │ 41,736 │ 93 │ 449 chars │ 3.6% │ 主讲人 (99% of content)│
│ 发言人2 │ 101 │ 8 │ 13 chars │ 4.0% │ 对话者 (short responses)│
└──────────┴────────┴──────────┴─────────────┴─────────────┴────────────────────────┘
Inference rules:
- 占比 > 70% + 平均长度 > 100字 → 主讲人
- 平均长度 < 50字 → 对话者/响应者
- 语气词占比 < 5% → 正式/准备充分
- 语气词占比 > 10% → 非正式/即兴发言
当用户提供项目上下文文件(例如 context.md)时:
上下文文件应包含:
## Team Directory
| Name | Role | Communication Style |
|------|------|---------------------|
| Alice | Backend Lead | Technical, decisive, assigns backend tasks |
| Bob | PM | Product-focused, asks requirements questions |
| Carol | TPM | Process-focused, tracks timeline/resources |
关键:切勿默默假设发言人身份。
向用户展示分析摘要:
Speaker Analysis:
- Speaker 1 → Alice (Backend Lead) - 80% confidence based on: technical focus, task assignment pattern
- Speaker 2 → Bob (PM) - 75% confidence based on: product questions, requirements discussion
- Speaker 3 → Carol (TPM) - 70% confidence based on: timeline concerns, resource tracking
Please confirm or correct these mappings before I proceed.
用户确认后,在整个文档中一致地应用映射。
评估转录稿质量以确定处理深度:
评分标准(1-10 分):
| 因素 | 分数影响 |
|---|---|
| 内容量 | >10k 字符:+2,5-10k:+1,<2k:上限为 3 |
| 填充词比例 | <5%:+2,5-10%:+1,>10%:-1 |
| 发言人清晰度 | 主要发言人 >80%:+1(清晰的主讲人) |
| 技术深度 | 高技术含量:+1 |
质量等级:
| 分数 | 等级 | 处理方法 |
|---|---|---|
| ≥8 | 高 | 完整结构化纪要,包含所有部分、图表、引用 |
| 5-7 | 中 | 标准纪要,专注于关键决策和行动项 |
| <5 | 低 | 仅摘要 - 简要要点,跳过详细转录 |
示例评估:
📊 Transcript Quality Assessment:
- Content: 41,837 chars (+2)
- Filler ratio: 3.6% (+2)
- Main speaker: 99% (+1)
- Technical depth: High (+1)
→ Quality Score: 10/10 (High)
→ Recommended: Full structured minutes with diagrams
用户决策点:如果质量低(<5),询问用户:
"Transcript quality is low (碎片对话/噪音较多). Generate full minutes or summary only?"
单次遍历绝对会丢失内容。 使用具有冗余完整遍历的多轮生成:
每次遍历从完整转录稿生成完整的纪要(所有部分)。具有隔离上下文的多次遍历会捕获不同的细节。UNION 合并整合所有发现。
❌ 错误:窄焦点遍历(浪费 token,导致偏见)
Pass 1: Only extract decisions
Pass 2: Only extract action items
Pass 3: Only extract discussion
✅ 正确:具有隔离上下文的完整遍历
Pass 1: Generate COMPLETE minutes (all sections) → version1.md
Pass 2: Generate COMPLETE minutes (all sections) with fresh context → version2.md
Pass 3: Generate COMPLETE minutes (all sections) with fresh context → version3.md
Merge: UNION all versions, consolidate duplicates → draft_minutes.md
Pass 1: Read transcript → Generate complete minutes → Write to: <output_dir>/intermediate/version1.md
Pass 2: Fresh context → Read transcript → Generate complete minutes → Write to: <output_dir>/intermediate/version2.md
Pass 3: Fresh context → Read transcript → Generate complete minutes → Write to: <output_dir>/intermediate/version3.md
Merge: Read all versions → UNION merge (consolidate duplicates) → Write to: draft_minutes.md
Final: Compare draft against transcript → Add any remaining omissions → final_minutes.md
必须使用 Task 工具来生成多个具有隔离上下文的子代理,每个子代理生成完整纪要:
使用 Task 工具的实现:
// Launch ALL 3 subagents in PARALLEL (single message, multiple Task tool calls)
Task(subagent_type="general-purpose", prompt="Generate complete meeting minutes from transcript...", run_in_background=false) → version1.md
Task(subagent_type="general-purpose", prompt="Generate complete meeting minutes from transcript...", run_in_background=false) → version2.md
Task(subagent_type="general-purpose", prompt="Generate complete meeting minutes from transcript...", run_in_background=false) → version3.md
// After all complete:
Main Agent: Read all versions → UNION merge, consolidate duplicates → draft_minutes.md
关键:子代理提示必须包含:
为什么多次完整遍历有效:
为什么隔离上下文很重要:
关键:将每次遍历输出写入文件,而不是对话上下文。
路径约定: 所有中间文件应创建在 <output_dir>/intermediate/ 下的转录稿特定子目录中,以避免处理不同转录稿时发生冲突。
关键:使用转录稿特定子目录结构:
<output_dir>/intermediate/<transcript-name>/version1.md
<output_dir>/intermediate/<transcript-name>/version2.md
<output_dir>/intermediate/<transcript-name>/version3.md
示例:如果最终纪要将是 project-docs/meeting-minutes/2026-01-14-api-design.md,那么:
中间文件:project-docs/meeting-minutes/intermediate/2026-01-14-api-design/version1.md
这可以防止在同一会话中处理多个转录稿时发生冲突
intermediate/ 文件夹应添加到 .gitignore(临时工作文件)
// Create transcript-specific subdirectory first mkdir: <output_dir>/intermediate/<transcript-name>/
// Launch all 3 subagents IN PARALLEL (must be single message with 3 Task tool calls) Task 1 → Write to: <output_dir>/intermediate/<transcript-name>/version1.md (complete minutes) Task 2 → Write to: <output_dir>/intermediate/<transcript-name>/version2.md (complete minutes) Task 3 → Write to: <output_dir>/intermediate/<transcript-name>/version3.md (complete minutes)
Merge Phase: Read: <output_dir>/intermediate/<transcript-name>/version1.md Read: <output_dir>/intermediate/<transcript-name>/version2.md Read: <output_dir>/intermediate/<transcript-name>/version3.md → UNION merge, consolidate duplicates, INCLUDE ALL DIAGRAMS → Write to: draft_minutes.md
Final Review: Read: draft_minutes.md Read: original_transcript.md → Compare & add omissions → Write to: final_minutes.md
基于文件的上下文卸载的好处:
重要:始终在转录稿特定子目录中保留中间版本:
<output_dir>/intermediate/<transcript-name>/version1.md、version2.md、version3.md - 每个子代理输出intermediate/ 添加到 .gitignore - 这些是临时工作文件,不是最终交付物assets/<meeting-name>/ 文件夹并使用  语法内嵌;包含简要描述 - 这创建了"下一级"的人工可读纪要,读者在阅读讨论前就理解了讨论的内容初始生成后,立即对照转录稿进行审查:
Completeness Checklist:
- [ ] All discussion topics covered?
- [ ] All decisions have supporting quotes?
- [ ] All speakers attributed correctly?
- [ ] All action items have specific owners?
- [ ] Numerical values preserved (ranges, counts)?
- [ ] Entity relationships captured?
- [ ] State machines complete (all states listed)?
如果发现差距,请默默添加缺失内容,不要提及遗漏了什么。
将完整的纪要作为草稿提交给人工审查。强调:
用户可能:
当用户提供来自其他 AI 工具的输出时(例如,Gemini、ChatGPT 等):
此步骤很有价值,因为:
比较过程:
跨 AI 比较的示例发现:
当用户请求更深入的审查时("deep review"、"check again"、"anything missing"):
当用户提供另一个版本进行合并时:
合并原则:UNION,从不删除
在合并阶段,必须积极包含所有版本中的所有图表。
图表是花费精力生成的高价值内容。不同的子代理可能根据他们关注的重点生成不同的图表。在合并过程中遗漏图表是重大损失。
合并图表策略:
要寻找的常见图表类型:
示例:遗漏的 v3 图表 如果 v3 有一个"状态查询机制"的流程图,但 v1/v2 没有,那么该流程图必须出现在合并输出中。不要假设它被其他图表覆盖。
| 文件 | 何时加载 |
|---|---|
| meeting_minutes_template.md | 首次生成 - 包含模板结构 |
| completeness_review_checklist.md | 在审查步骤期间 - 包含完整性检查 |
| context_file_template.md | 当帮助用户创建 context.md 时 - 包含团队目录模板 |
| 项目上下文文件(用户提供) | 当用户提供项目特定上下文时(团队目录、术语、约定) |
用于 .docx 转录稿的完整流程:
Step 0: doc-to-markdown # Convert .docx → Markdown (preserves tables/images)
↓
Step 0.5: transcript-fixer # Fix ASR errors (optional, if quality is poor)
↓
Step 1+: meeting-minutes-taker # Generate structured minutes
命令:
# 1. Install markitdown (one-time)
uv tool install "markitdown[pdf]"
# 2. Convert .docx to markdown
markitdown "录音转写.docx" -o transcript.md
# 3. Then use meeting-minutes-taker on transcript.md
组合工作流程的好处:
图表将会议纪要提升到纯文本之上。 它们使复杂的讨论对人类审查者来说立即易于理解。始终寻找添加视觉图表的机会。
sequenceDiagram
participant FE as Frontend
participant BE as Backend
participant SVC as External Service
participant DB as Database
FE->>BE: Click "Submit Order"
BE->>SVC: POST /process (send data)
SVC-->>BE: Return {status}
BE->>DB: Save result
BE-->>FE: Return success
erDiagram
ORDER ||--o{ ORDER_ITEM : "1:N"
ORDER {
uuid id PK
string customer_name
decimal total_amount
}
ORDER_ITEM {
uuid id PK
uuid order_id FK
int quantity
}
sequenceDiagram
participant User
participant System
Note over System: Current: V2 Active
User->>System: Create V3 (inactive)
User->>System: Set V2 inactive
User->>System: Set V3 active
Note over System: New: V3 Active
引用必须使用单独的 Markdown 块引用格式:
❌ 错误:内联引用格式
* **Quote:** > "This is wrong" - **Speaker**
✅ 正确:单独行的块引用
* **Quote:**
> "This is the correct format" - **Speaker**
✅ 正确:多个引用
* **Quote:**
> "First quote from the discussion" - **Speaker1**
> "Second quote supporting the same decision" - **Speaker2**
关键格式规则:
* **Quote:** 单独一行(此行没有引用内容)* **Quote:** 后不需要空行> 前缀- **SpeakerName**### 2.X [Category] Decision Title
* **Decision:** Specific decision made
* **Logic:**
* Reasoning point 1
* Reasoning point 2
* **Quote:**
> "Exact quote from transcript" - **Speaker Name**
带有"defer to later"、"Phase 2"、"not in MVP"等关键词的事项应放入停车场并附带上下文。
会议纪要不是一次性输出。高质量的纪要通过多次审查周期产生:
Round 1: Initial generation
└─ Human review: "Check original transcript for missing items"
Round 2: Deep transcript review, add omitted content
└─ Human review: "UserProfile conflicts with existing Account entity naming"
Round 3: Update terminology to use "CustomerProfile" instead
└─ Human review: "Note field conflicts with existing Comment system"
Round 4: Update to use "Annotation" instead of "Note"
└─ Human approval: Final version ready
AI 生成初稿;人类细化到最终版本。 切勿假设第一次输出是完整的或使用了正确的术语。始终鼓励人工审查,并准备好进行多个迭代周期。
intermediate/<transcript-name>/ 以避免冲突> "quote"[doc.md](reviewed-document));对于不在存储库中的外部/本地文档,使用纯文本Weekly Installs
135
Repository
GitHub Stars
713
First Seen
Jan 25, 2026
Security Audits
Installed on
opencode115
claude-code114
codex112
gemini-cli107
cursor101
github-copilot99
AI Elements:基于shadcn/ui的AI原生应用组件库,快速构建对话界面
65,000 周安装
Microsoft 365 Copilot 声明式代理开发指南:使用 TypeSpec 和 Agents Toolkit 创建企业级AI助手
7,600 周安装
NUnit 单元测试最佳实践指南:C# 数据驱动测试与断言方法详解
7,700 周安装
MSTest 单元测试最佳实践指南:C# 现代测试框架使用教程
7,600 周安装
C# MCP服务器生成器 - 快速构建Model Context Protocol服务器 | .NET 8开发工具
7,600 周安装
技术调研文档创建指南:结构化模板与最佳实践
7,700 周安装
Spring Boot Kotlin项目创建指南:使用GitHub Copilot快速搭建全栈应用
7,600 周安装