# Meeting Notes

> Process meeting notes, transcripts, or recordings into a clean recap, a tracked cross-meeting action list, and follow-ups. Activate whenever the user shares meeting notes, a call/Zoom/Teams/Granola/Fireflies transcript, a .vtt/.srt caption file, or raw bullets from a meeting, OR asks to "write up", "summarize", "recap", "take minutes from", or "pull action items from" a meeting. This skill defines the shared conventions (file layout, recap format, action ledger) used by /meeting-notes:recap, /meeting-notes:actions, and /meeting-notes:followup.

- Skill: `nord342/meeting-notes` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add nord342/meeting-notes`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nord342/meeting-notes/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: nord342 (https://skillmd.com/u/nord342)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nord342/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.