Meeting notes

Meeting Notes — Core System

This is the shared brain for the Meeting Notes plugin. It defines where files live, what formats to use, and how to extract structure from messy meeting input. The recap, actions, and followup skills all build on these conventions — keep them consistent.

Everything is local and file-based. No connectors, no accounts, nothing leaves the machine.

When to activate

Activate automatically (no slash command needed) when the user:

• Pastes or points to meeting notes, a transcript, or a caption file (.txt, .md, .vtt, .srt, .docx, or an exported transcript from Zoom / Teams / Google Meet / Granola / Fireflies / Otter / tl;dv).
• Says things like "write up these notes", "summarize this call", "take minutes", "what are my action items from this", "recap the sync", "draft a follow-up from this meeting".
• Drops a folder of meeting files and asks to process them.

If the user typed an explicit command (/meeting-notes:recap, :actions, :followup), follow that skill's instructions but still use the conventions below.

File layout (the system)

Work inside the current working directory. Maintain exactly this layout — create what's missing on first run, never scatter files elsewhere:

./Meetings/
├── ACTIONS.md                       # the single living cross-meeting action ledger
├── recaps/
│   └── 2026-06-29-product-sync.md   # one clean recap per meeting (YYYY-MM-DD-slug.md)
└── raw/                             # optional: where the user drops transcripts/notes

• ACTIONS.md is the heart of the system: one durable file that accumulates every open action across every meeting so nothing is lost. Treat it as append-and-reconcile, never overwrite-from-scratch.
• recaps/ holds the polished per-meeting output, named YYYY-MM-DD-<slug>.md (slug = kebab-case meeting title).
• If a Meetings/ folder already exists from a previous run, reuse it.

If the user is clearly working somewhere else (e.g. they already have a recaps/ folder, or they tell you where to put things), follow their lead instead of forcing ./Meetings/.

Reading messy input

Real meeting input is rarely clean. Handle these gracefully:

• Transcripts with speaker labels / timestamps ([00:12:04] Sarah: ..., Sarah Lopez 12:04 ): strip timestamps, attribute decisions and commitments to the right speaker.
• Caption files (.vtt, .srt): ignore the cue numbers and timecodes; reconstruct the conversation.
• Voice-to-text / stream-of-consciousness: tolerate run-ons, fix obvious transcription errors only where meaning is clear, never invent content.
• Terse bullet dumps: expand into full sentences without adding facts that aren't there.
• Multiple meetings in one file: detect the boundaries and produce one recap per meeting.

Never fabricate. If an attendee, date, owner, or due date isn't stated or strongly implied, leave it blank or mark it (unassigned) / (no date) rather than guessing. Accuracy matters more than completeness — these notes drive real follow-ups.

Extraction rules

From the input, pull out:

1. Metadata — title, date, attendees, and (if present) duration. If the date isn't in the content, use today's date and say so.
2. TL;DR — 3–5 bullets a busy person could read in 15 seconds.
3. Decisions — things that were decided, stated as settled facts ("Chose Postgres over Mongo for the billing service").
4. Action items — every commitment, each with:
   • Owner — the person responsible. Map first-person commitments ("I'll send it") to that speaker; map "you" / "can someone" to the named person or (unassigned).
   • Task — a clear, verb-first description.
   • Due date — resolve relative dates against the meeting date ("by next Friday", "EOW", "before the launch"). Output an absolute date like due Fri Jul 3. If none stated, (no date).
5. Open questions / risks — unresolved threads and flagged concerns.
6. Notes — a cleaned, condensed narrative or topic-grouped summary of the discussion (not a transcript).

Action item line format (use everywhere — recaps and ledger)

- [ ] **@Owner** Verb-first task — due Fri Jul 3 · _Source Meeting (Jun 29)_

• @Owner is the person; use @You for the user when they own it; @unassigned when nobody was named.
• The · _Source Meeting (date)_ suffix is mandatory in ACTIONS.md so every item traces back to where it came from. It's optional in a single recap file (the recap's own title already provides context).
• Completed items use - [x] and append · done <date>.

Templates

Canonical templates live in ${CLAUDE_PLUGIN_ROOT}/skills/meeting-notes/templates/:

• recap.md — the per-meeting recap structure.
• ACTIONS.md — the cross-meeting ledger structure.
• followup.md — the follow-up message structure.

Read the relevant template before writing a file the first time so structure stays consistent across meetings.

The golden rule

The whole point is that commitments don't get lost. Every time you process a meeting, the new action items must land in ACTIONS.md (deduplicated against what's already open). When in doubt, surface an item rather than dropping it — an extra line in the ledger is cheap; a forgotten promise is expensive.