Meeting Notes skill for Codex

Good notes let someone who missed the meeting know within 30 seconds what was decided, who is doing what by when, and what is still open. They record commitments people actually made, in the words they agreed to, and nothing more. A transcript summary that reads well but invents an owner or a deadline is worse than no notes.

Before summarizing

1. Identify the source and its reliability:
   • Auto-transcript (VTT, SRT, TXT): speaker labels may be wrong or generic (“Speaker 2”), names and jargon are often misheard, crosstalk gets dropped.
   • Human live notes: incomplete but intentional; trust their decisions more than transcript inference.
   • Chat log alongside the call: often holds links and the exact numbers people pasted.
2. Get the meeting metadata: title, date, attendees, purpose or agenda. Ask the user for anything missing that the notes need (especially who attended and the meeting type).
3. Check where notes live and their format: a meetings/ or notes/ folder, a template in the docs, or conventions in AGENTS.md. Match existing files.

Planning and running the meeting itself (agenda design, facilitation) belongs to $meeting-facilitation.

Prepare a transcript

Strip timing cues from VTT/SRT so the text is readable but keep timestamps available for citations:

# VTT -> "HH:MM:SS Speaker: text" lines (keeps the cue start time;
# the sed handles Teams-style <v Name>...</v> voice tags)
awk '/-->/{t=substr($1,1,8); next} /^(WEBVTT|NOTE|[0-9]+$|$)/{next} {print t, $0}' call.vtt \
  | sed -E 's#<v ([^>]+)>#\1: #; s#</v>##' > call.txt
wc -l call.txt

For long transcripts (over ~1 hour), summarize in chunks of 10-15 minutes first, keeping timestamps, then merge. Never summarize a merged summary without checking decisions and actions against the original lines.

Extraction rules

Item	Counts when	Does not count
Decision	Someone with authority states it and nobody objects, or the group explicitly agrees (“OK, let’s go with B”)	“We should probably…”, one person’s preference, a decision deferred to later
Action item	A person accepts a task (“I’ll send the draft by Friday”) or is assigned and agrees	“Someone needs to look at X” with no taker: record it as an open question with “owner needed”
Open question	Raised, not answered; or answer depends on someone absent	Rhetorical questions
Parked	Explicitly deferred (“let’s take that offline”, “next sprint”)	Topics simply not reached (list as “not covered”)
Risk or blocker	Named as something that could stop or delay work	General worries without a consequence

When the transcript is ambiguous, keep the ambiguity visible: Owner: Priya (?) - confirm, Due: "end of next week" (2026-11-06?). Never resolve it by guessing.

Convert relative dates to absolute ones using the meeting date, and show both when the original phrasing matters: by Friday (2026-10-30).

Action item format

- [ ] **Priya** - Send revised pricing table to finance, including the EU VAT column - due 2026-10-30
- [ ] **Marco** - Decide whether the beta includes SSO; post the decision in #launch - due 2026-11-03
- [ ] **Owner needed** - Check whether the legal review covers the new data processor

Rules: one owner per item (a person, not a team; “Marco + Ana” becomes two items or one owner with a helper noted), a verb-first task, a date, and enough detail that the owner knows what done looks like. Split compound tasks.

Decision format

1. **Launch date moves to 2026-11-18** (from 11-11). Reason: payment provider certification
   not complete. Decided by: Ana (product lead). Revisit if certification lands before 11-07.

Include the reason and any condition attached. Decisions without reasons get relitigated.

Notes template

# <Meeting title> - <YYYY-MM-DD>
**Attendees:** Ana (product), Marco (eng), Priya (finance)   **Absent:** Lee
**Purpose:** <one line>   **Notes by:** <name / generated from transcript, reviewed by ...>

## Decisions
1. ...

## Action items
- [ ] **Owner** - task - due YYYY-MM-DD

## Key discussion
- <Topic>: 2-4 bullets with the substance, numbers and the options considered.

## Open questions
- <Question> - who can answer - needed by

## Parked / not covered
- ...

## Links
- <docs, tickets, dashboards mentioned>

Order matters: decisions and actions first, discussion after. Most readers stop after the action items.

Meeting-type adjustments

Type	Emphasize	Keep short
Standup	Blockers and who is helping	Status updates (one line each or omit)
Planning / sprint	Commitments, scope cuts, capacity	Debate about estimates
Design review	Decisions with rationale, rejected options and why	Walkthrough narration
Customer call	Customer’s words on pain points (quoted), requests, commitments made to them	Internal chatter
1:1	Agreed follow-ups only; ask the user what may be written down	Personal or sensitive topics (omit)
Incident review	Timeline facts, actions with owners	Speculation

Writing the discussion section

• Capture substance, not chronology: group by topic even if the meeting jumped around.
• Keep numbers, names of options and quoted constraints exactly (“max 200 ms p95”).
• Attribute positions only when it matters for follow-up (“Finance needs the number by Q4 close”). Do not attribute jokes, frustration or off-the-cuff remarks.
• Leave out small talk, repeated points and anything said “off the record”.

Sensitive content

Transcripts capture everything. Before writing notes intended for a wider audience, drop: personal matters, health, compensation and performance discussions, HR issues, unreleased financials beyond the audience’s access, and customer personal data. When unsure whether something belongs, ask the user rather than including it.

Sending the recap

A follow-up message to attendees is often wanted. Draft it, show it, and send or post only after the user gives a clear yes:

Subject: Recap - Launch sync 2026-10-28: date moves to 11-18

Hi all - decisions and actions from today. Reply if anything is wrong by Thursday.

Decisions: launch moves to 2026-11-18 (payment certification pending).
Actions:
- Priya: revised pricing table to finance, due 10-30
- Marco: SSO in beta yes/no, posted in #launch, due 11-03
Open: who checks legal coverage for the new processor?

Full notes: <link>

Gotchas

• Transcript speaker attribution is unreliable. If an action’s owner depends on who said “I’ll do it”, verify with surrounding context or mark it (?).
• Misheard names, product terms and numbers: cross-check against the chat log, agenda and attendee list; flag anything unverifiable.
• “We agreed” is not a decision if the decider was absent. Record it as a proposal pending that person.
• Generated summaries drift toward positive framing. Keep disagreement and unresolved risks visible.

Verification

• Every action item has exactly one owner, a date (or an explicit “date needed”), and maps to a line in the transcript or notes; spot-check three against the source timestamps.
• Every decision has a reason and a named decider.
• No owner, deadline or decision appears that cannot be traced to the source.
• Open questions and parked items are listed rather than silently dropped.
• Tell the user which items are marked uncertain so they can confirm before sharing.