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:

1. Read the transcript provided by user
2. Load project-specific context file if provided by user (optional)
3. Intelligent file naming: Auto-generate filename from content (see below)
4. Speaker identification: If transcript has "Speaker 1/2/3", identify speakers before generation
5. Multi-turn generation: Use multiple passes or subagents with isolated context, merge using UNION
6. Self-review using references/completeness_review_checklist.md
7. Present draft to user for human line-by-line review
8. Cross-AI comparison (optional): Human may provide output from other AI tools (e.g., Gemini, ChatGPT) - merge to reduce bias
9. 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.md
• 2026-01-20-q1-sprint-planning.md
• 2026-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):

1. Load team directory section
2. Match feature patterns to known team members
3. Cross-reference roles with speaking patterns

Context file should include:

## 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 |

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:

1. Full path to transcript file
2. Full path to output file (version1.md, version2.md, version3.md in transcript-specific subdirectory)
3. Context files to load (project-specific context if provided, meeting_minutes_template.md)
4. Reference images/documents if provided by user
5. Output language requirement (match user's language preference, preserve technical terms in English)
6. 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