Meeting Minutes Taker
Transform raw meeting transcripts into comprehensive, evidence-based meeting minutes through iterative review.
Quick Start
Pre-processing (Optional but Recommended):
- Document conversion: Use
doc-to-markdown skill to convert .docx/.pdf to Markdown first (preserves tables/images)
- Transcript cleanup: Use
transcript-fixer skill to fix ASR/STT errors if transcript quality is poor
- Context file: Prepare
context.md with team directory for accurate speaker identification
Core Workflow:
- Read the transcript provided by user
- Load project-specific context file if provided by user (optional)
- Intelligent file naming: Auto-generate filename from content (see below)
- Speaker identification: If transcript has "Speaker 1/2/3", identify speakers before generation
- Multi-turn generation: Use multiple passes or subagents with isolated context, merge using UNION
- Self-review using references/completeness_review_checklist.md
- Present draft to user for human line-by-line review
- Cross-AI comparison (optional): Human may provide output from other AI tools (e.g., Gemini, ChatGPT) - merge to reduce bias
- Iterate on feedback until human approves final version
Intelligent File Naming
Auto-generate output filename from transcript content:
Pattern: YYYY-MM-DD-<topic>-<type>.md
| Component |
Source |
Examples |
| Date |
Transcript metadata or first date mention |
2026-01-25 |
| Topic |
Main discussion subject (2-4 words, kebab-case) |
api-design, product-roadmap |
| Type |
Meeting category |
review, sync, planning, retro, kickoff |
Examples:
2026-01-25-order-api-design-review.md2026-01-20-q1-sprint-planning.md2026-01-18-onboarding-flow-sync.md
Ask user to confirm the suggested filename before writing.
Core Workflow
Copy this checklist and track progress:
Meeting Minutes Progress:
- [ ] Step 0 (Optional): Pre-process transcript with transcript-fixer
- [ ] Step 1: Read and analyze transcript
- [ ] Step 1.5: Speaker identification (if transcript has "Speaker 1/2/3")
- [ ] Analyze speaker features (word count, style, topic focus)
- [ ] Match against context.md team directory (if provided)
- [ ] Present speaker mapping to user for confirmation
- [ ] Step 1.6: Generate intelligent filename, confirm with user
- [ ] Step 1.7: Quality assessment (optional, affects processing depth)
- [ ] Step 2: Multi-turn generation (PARALLEL subagents with Task tool)
- [ ] Create transcript-specific dir: <output_dir>/intermediate/<transcript-name>/
- [ ] Launch 3 Task subagents IN PARALLEL (single message, 3 Task tool calls)
- [ ] Subagent 1 → <output_dir>/intermediate/<transcript-name>/version1.md
- [ ] Subagent 2 → <output_dir>/intermediate/<transcript-name>/version2.md
- [ ] Subagent 3 → <output_dir>/intermediate/<transcript-name>/version3.md
- [ ] Merge: UNION all versions, AGGRESSIVELY include ALL diagrams → draft_minutes.md
- [ ] Final: Compare draft against transcript, add omissions
- [ ] Step 3: Self-review for completeness
- [ ] Step 4: Present draft to user for human review
- [ ] Step 5: Cross-AI comparison (if human provides external AI output)
- [ ] Step 6: Iterate on human feedback (expect multiple rounds)
- [ ] Step 7: Human approves final version
Note: <output_dir> = directory where final meeting minutes will be saved (e.g., project-docs/meeting-minutes/)
Note: <transcript-name> = name derived from transcript file (e.g., 2026-01-15-product-api-design)
Step 1: Read and Analyze Transcript
Analyze the transcript to identify:
- Meeting topic and attendees
- Key decisions with supporting quotes
- Action items with owners
- Deferred items / open questions
Step 1.5: Speaker Identification (When Needed)
Trigger: Transcript only has generic labels like "Speaker 1", "Speaker 2", "发言人1", etc.
Approach (inspired by Anker Skill):
Phase A: Feature Analysis (Pattern Recognition)
For each speaker, analyze:
| Feature |
What to Look For |
| Word count |
Total words spoken (high = senior/lead, low = observer) |
| Segment count |
Number of times they speak (frequent = active participant) |
| Avg segment length |
Average words per turn (long = presenter, short = responder) |
| Filler ratio |
% of filler words (对/嗯/啊/就是/然后) - low = prepared speaker |
| Speaking style |
Formal/informal, technical depth, decision authority |
| Topic focus |
Areas they discuss most (backend, frontend, product, etc.) |
| Interaction pattern |
Do others ask them questions? Do they assign tasks? |
Example analysis output:
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% → 非正式/即兴发言
Phase B: Context Mapping (If Context File Provided)
When user provides a project context file (e.g., context.md):
- Load team directory section
- Match feature patterns to known team members
- Cross-reference roles with speaking patterns
Context file should include:
## Team Directory
|------|------|---------------------|
| Alice | Backend Lead | Technical, decisive, assigns backend tasks |
| Bob | PM | Product-focused, asks requirements questions |
| Carol | TPM | Process-focused, tracks timeline/resources |
Phase C: Confirmation Before Proceeding
CRITICAL: Never silently assume speaker identity.
Present analysis summary to user:
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.
After user confirmation, apply mappings consistently throughout the document.
Step 1.7: Transcript Quality Assessment (Optional)
Evaluate transcript quality to determine processing depth:
Scoring Criteria (1-10 scale):
| Factor |
Score Impact |
| Content volume |
>10k chars: +2, 5-10k: +1, <2k: cap at 3 |
| Filler word ratio |
<5%: +2, 5-10%: +1, >10%: -1 |
| Speaker clarity |
Main speaker >80%: +1 (clear presenter) |
| Technical depth |
High technical content: +1 |
Quality Tiers:
| Score |
Tier |
Processing Approach |
| ≥8 |
High |
Full structured minutes with all sections, diagrams, quotes |
| 5-7 |
Medium |
Standard minutes, focus on key decisions and action items |
| <5 |
Low |
Summary only - brief highlights, skip detailed transcription |
Example assessment:
📊 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
User decision point: If quality is Low (<5), ask user:
"Transcript quality is low (碎片对话/噪音较多). Generate full minutes or summary only?"
Step 2: Multi-Turn Initial Generation (Critical)
A single pass will absolutely lose content. Use multi-turn generation with redundant complete passes:
Core Principle: Multiple Complete Passes + UNION Merge
Each pass generates COMPLETE minutes (all sections) from the full transcript. Multiple passes with isolated context catch different details. UNION merge consolidates all findings.
❌ WRONG: Narrow-focused passes (wastes tokens, causes bias)
Pass 1: Only extract decisions
Pass 2: Only extract action items
Pass 3: Only extract discussion
✅ CORRECT: Complete passes with isolated context
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
Strategy A: Sequential Multi-Pass (Complete Minutes Each Pass)
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
Strategy B: Parallel Multi-Agent (Complete Minutes Each Agent) - PREFERRED
MUST use the Task tool to spawn multiple subagents with isolated context, each generating complete minutes:
Implementation using Task tool:
// 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
CRITICAL: Subagent Prompt Must Include:
- Full path to transcript file
- Full path to output file (version1.md, version2.md, version3.md in transcript-specific subdirectory)
- Context files to load (project-specific context if provided, meeting_minutes_template.md)
- Reference images/documents if provided by user
- Output language requirement (match user's language preference, preserve technical terms in English)
- Quote formatting requirement (see Quote Formatting Requirements section below)
Why multiple complete passes work:
- Each pass independently analyzes the SAME content
- Different context states catch different details (no single pass catches everything)
- Pass 1 might catch decision X but miss action item Y
- Pass 2 might catch action item Y but miss decision X
- UNION merge captures both X and Y
Why isolated context matters:
- Each pass/agent starts fresh without prior assumptions
- No cross-contamination between passes
- Different "perspectives" emerge naturally from context isolation
Progressive Context Offloading (Use File System)
Critical: Write each pass output to files, not conversation context.
Path Convention: All intermediate files should be created in a transcript-specific subdirectory under <output_dir>/intermediate/ to avoid conflicts between different transcripts being processed.
CRITICAL: Use transcript-specific subdirectory structure:
<output_dir>/intermediate/<transcript-name>/version1.md
<output_dir>/intermediate/<transcript-name>/version2.md
<output_dir>/intermediate/<transcript-name>/version3.md
Example: If final minutes will be project-docs/meeting-minutes/2026-01-14-api-design.md, then:
- Intermediate files:
project-docs/meeting-minutes/intermediate/2026-01-14-api-design/version1.md
- This prevents conflicts when multiple transcripts are processed in the same session
- The
intermediate/ folder should be added to .gitignore (temporary working files)
// 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
Benefits of file-based context offloading:
- Conversation context stays clean (avoids token overflow)
- Intermediate results persist (can be re-read if needed)
- Each pass starts with fresh context window
- Merge phase reads only what it needs
- Human can inspect intermediate files for review - Critical for understanding what each pass captured
- Supports very long transcripts that exceed context limits
- Enables post-hoc debugging - If final output is missing something, human can trace which pass missed it
IMPORTANT: Always preserve intermediate versions in transcript-specific subdirectory:
<output_dir>/intermediate/<transcript-name>/version1.md, version2.md, version3.md - Each subagent output- These files help human reviewers understand the merge process
- Do NOT delete intermediate files after merge
- Human may want to compare intermediate versions to understand coverage gaps
- Add
intermediate/ to .gitignore - These are temporary working files, not final deliverables
- Transcript-specific subdirectory prevents conflicts when processing multiple transcripts
Output Requirements
- Chinese output with English technical terms preserved
- Evidence-based decisions - Every significant decision needs a supporting quote
- Structured sections - Executive Summary, Key Decisions, Discussion, Action Items, Parking Lot
- Proper quote formatting - See Quote Formatting Requirements section below
- Mermaid diagrams (STRONGLY ENCOURAGED) - Visual diagrams elevate minutes beyond pure text:
- ER diagrams for database/schema discussions
- Sequence diagrams for data flow and API interactions
- Flowcharts for process/workflow decisions
- State diagrams for state machine discussions
- Diagrams make minutes significantly easier for humans to review and understand
- Context-first document structure - Place all reviewed artifacts (UI mockups, API docs, design images) at the TOP of the document (after metadata, before Executive Summary) to establish context before decisions; copy images to
assets/<meeting-name>/ folder and embed inline usi
