meeting-minutes-taker

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", FIRST ask the user to label speakers on the source platform and re-export (see Step 1.5 Phase 0); infer from text only as a fallback
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")
  - [ ] Phase 0 FIRST: ask user to label speakers on the source platform (Feishu Minutes / Tencent Meeting), re-export, use labeled transcript
  - [ ] Fallback only (source labeling unavailable or declined by user):
    - [ ] Analyze speaker features (word count, style, topic focus)
    - [ ] Match against context.md team directory (if provided)
    - [ ] Present speaker mapping with per-speaker evidence 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 3.5: Retrieval Self-Test (consumption-side verification)
  - [ ] Fresh-context subagent extracts future-query claims list from transcript ONLY (never sees draft) → intermediate/<transcript-name>/retrieval-claims.md
  - [ ] Hit-test each claim against retrievable layer (Key Decisions / Action Items / Parking Lot / Open Questions), by component, with lexical anchors
  - [ ] Revocation scan before ANY promotion; promote with [self-test promoted] tag + greppable verbatim quote; uncertain → Open Questions
  - [ ] Report "enumerated N / hits M / promoted K / uncertain list" (never a binary pass); fail-open with visible NOT-RUN note if extraction fails
- [ ] 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.

Phase 0: Source-Side Labeling (ALWAYS TRY FIRST)

When the transcript comes from a platform that supports manual speaker labeling (Feishu Minutes 飞书妙记, Tencent Meeting 腾讯会议, or any tool with a diarization-editing page), stop and ask the user to label the speakers at the source, then re-export/re-ingest the labeled transcript before generating minutes. Send the user the source page link — it is usually in the transcript's frontmatter (minute_url, meeting URL).

Why this beats inference:

• Platform labeling is a human listening to the actual voices — the authoritative source. Text-based inference can only resolve speakers who happen to get name-called during the meeting; everyone else stays a guess.
• Diarization-merged segments (multiple people collapsed into one label) are unrecoverable from text alone — no amount of inference fixes them, but source-side relabeling does.
• Inference output forces [inferred] markers everywhere plus a per-speaker human review round; source labeling produces clean ground truth once.

Fall back to Phase A–C below only when: (a) the user explicitly says to proceed by inference, or (b) the source cannot be labeled (raw audio file with no platform page, no edit permission). In the fallback, every mapping must carry evidence and a confidence level, unresolved labels stay as-is (never force-assign), and when the user later labels the source, go back and correct the minutes.

Fallback 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)
-

---

*Content truncated.*