Use when processing, summarizing, or extracting insights from meeting notes in the Obsidian vault. Triggers on "summarize meetings", "process meetings", "meeting summaries", "extract from meetings", "meeting insights".
Use when processing, summarizing, or extracting insights from meeting notes in the Obsidian vault. Triggers on "summarize meetings", "process meetings", "meeting summaries", "extract from meetings", "meeting insights".
Summarize Meetings
Process meeting transcripts from Meetings/transcripts/ — extract people, action items, project ideas, blog ideas, knowledge graph connections, concepts, and general ideas. Populate the vault knowledge graph and generate rich summary files.
Campaign Workflow
Processing works in monthly batches, most-recent month first. Each month follows this cycle:
digraph campaign {
rankdir=TB;
"Scan month (ls -lS)" -> "Triage: check small/suspicious files";
"Triage: check small/suspicious files" -> "Identify skips vs substantive";
"Identify skips vs substantive" -> "Dispatch wave of agents (10-15)";
"Dispatch wave of agents (10-15)" -> "Wait for returns";
"Wait for returns" -> "Dispatch remaining agents";
"Dispatch remaining agents" -> "All agents returned";
"All agents returned" -> "Compile monthly report table";
"Compile monthly report table" -> "Post social media update";
"Post social media update" -> "Next month or stop";
}
Step 1: Scan the Month
ls -lS "Meetings/transcripts/" | grep "YYYY-MM"
List all transcripts for the target month, sorted by size. This gives you:
Total count of transcripts
File sizes (critical for triage and agent instructions)
Filenames for slug generation
Step 2: Check for Existing Summaries
ls"Meetings/" | grep "YYYY-MM.*summary"
Skip any transcript that already has a corresponding summary file.
Step 3: Triage
Before dispatching agents, manually check files that are suspicious:
Signal
Action
< 2K
Read the file — likely empty stub or sparse notes
2K-6K
Skim the file — may be scheduling fragment, garbled recording, or logistics-only
Filename says "untitled"
Almost always empty — read to confirm
Known non-meeting patterns
Medical appointments, kid brainstorming, screen-sharing setup, recording process discussions
Skip criteria (with log entry):
Empty stubs (template only, no content)
< 20 words of real content after frontmatter
Garbled/corrupted recordings
Scheduling fragments (just logistics, no substance)
Medical/personal appointments
Kid content (school brainstorming, etc.)
Recording process discussions (just setting up Granola)
Screen-sharing setup conversations
Sparse but substantive notes (like handwritten bullet points from a real meeting) should still be processed — even 1.2K of real fundraising notes is worth a summary.
Step 4: Dispatch Parallel Agents
Spawn one Task agent per transcript using subagent_type: general-purpose with mode: bypassPermissions and run_in_background: true.
Wave sizing: Dispatch 10-15 agents per wave. Wait for returns, then dispatch remaining agents. This prevents overwhelming the system while maintaining parallelism.
Large file instructions: For files > 50K, include "read in chunks using offset/limit" in the agent prompt. For files > 100K, explicitly say "this is a large file — read in chunks of 500-1000 lines using offset/limit parameters."
Agent prompt template:
You are a meeting summarizer for Doctor Biz's Obsidian vault at `/Users/harper/Public/Notes/Harper Notes/`.
Read the transcript at `[PATH]` ([SIZE] — [read in chunks if large]).
Then:
1. Extract: People, Action Items, Project Ideas, Blog Ideas, Knowledge Graph, Concepts, Ideas
2. Write summary to `Meetings/YYYY-MM-DD-slugified-name-summary.md`
3. Create/update People notes in `People/Firstname Lastname.md` (Title Case) — check if they exist first
4. Create Concept notes in `Concepts/` for genuinely reusable insights
Use the full summary template with YAML frontmatter (title, date, tags, type, source, status, related).
Write a strong 2-4 paragraph narrative meeting summary.
Use `[[wiki-links]]` throughout.
Never fabricate info not in the transcript.
Don't create People stubs for first-name-only references.
Step 5: Compile Monthly Report
After all agents return, present a summary table:
| Meeting | Date | People | Actions | Concepts | Status |
|---------|------|--------|---------|----------|--------|
| harper-john | Jan 31 | 1 | 5 | 3 | Done |
| untitled | Jan 15 | - | - | - | Skipped (empty) |
Include: total processed, total skipped (with reasons), and notable highlights (interesting concepts, key people).
Step 6: Social Media Update
Post a completion update via mcp__socialmedia__create_post with:
Write to: Meetings/YYYY-MM-DD-slugified-meeting-title-summary.md
Slug generation: Use the most descriptive part of the filename. Drop common prefixes like "hangout-", "call-", "harper-reed-and-". Keep it recognizable.
# Summary: Meeting Title> Source: [[Original Transcript Filename]]> Date: Month DD, YYYY> Attendees: [[Person 1]], [[Person 2]]## Meeting Summary
(A strong 2-4 paragraph narrative summary capturing the substance of the
conversation. What was the meeting about? What were the key themes? What
decisions were made or directions set? What was the energy/vibe? This should
read like a well-written meeting recap that someone who wasn't there could
read and fully understand what happened and why it mattered.)
## Key Topics
(Organized by discussion thread — use subheadings for distinct topics)
## People
| Person | Role/Context |
|--------|-------------|
| [[Person Name]] | context/role/relevance from this meeting |
## Action Items- [ ] Task description — owner if known
## Project Ideas- [[Project Name]] — what was discussed, potential next steps
## Blog Ideas-**Idea title** — why it's worth writing about, angle to take
## Knowledge Graph- [[Entity A]] ↔ [[Entity B]] — nature of relationship/connection
## Concepts- [[Concept Name]] — brief description and why it matters
## Ideas- Idea description — enough context to act on later
## Key Quotes> "Notable quote" — [[Speaker]]
What NOT To Do
Never delete or modify the original transcript
Never strip existing links or tags from the original
Never create duplicate People notes — check existing vault first, use aliases
Never create duplicate Concept notes — enrich existing ones instead
Never modify Dataview or Tasks query blocks in any note
Never fabricate information not present in the meeting notes — extract only what's there
Don't create People stubs for ambiguous first-name-only references unless context makes identity clear
Don't create concept notes for trivial or obvious things — only genuinely reusable insights
Don't create concept notes that overlap significantly with existing ones — add to the existing note instead
Don't process medical appointments, kid content, or recording setup conversations
Don't rely solely on Granola's summary_text — always read the actual transcript