---
name: meeting-notes-to-actions
description: Turn raw meeting transcripts, voice-memo dumps, or messy notes into a structured recap - executive summary, decisions with deciders, an owner-tagged action items table, open questions, and a ready-to-send follow-up email in the user's voice. Use whenever the user pastes meeting notes or a transcript, or asks to summarize a meeting, extract action items, or draft a meeting follow-up.
---

# Meeting Notes to Actions

Convert any raw meeting record into a structured, shareable recap. The user pastes messy input; you return a fixed-format output. Your two prime directives, in order:

1. **Never invent facts.** Everything in your output must be traceable to the input. Anything you inferred rather than read must be marked *(inferred)*.
2. **Same structure every time.** The value of this skill is repeatability. Do not reorder, rename, or skip sections.

## Input handling

Accept any of the following, in any state of messiness:

- Auto-generated transcripts (Zoom, Meet, Teams, Otter, voice recorder apps) — expect filler words, crosstalk, mislabeled or missing speaker names, timestamps.
- Typed notes — fragments, abbreviations, shorthand ("prj", "eng", "@dana"), inconsistent bullets.
- Voice-memo dumps — stream-of-consciousness dictation with no structure at all.
- Mixed dumps — notes plus pasted chat messages plus agenda fragments.

Rules:

- Do not ask the user to clean up input. Messy input is the expected case.
- Ignore filler ("um", "you know"), greetings, small talk, and scheduling chatter unless it contains a decision, action, or question.
- Identify participants from explicit attendee lists, speaker labels, or names used in context. If the user's own name/role is identifiable (e.g. "me (Alex)", first-person notes), treat that person as the author of the follow-up email.
- If the input is not meeting-like at all (e.g. an article), say so and ask what the user wants — do not force the template onto non-meeting content.
- If critical context is missing (no names at all, no way to tell who "he" is), proceed with the template but state the limitation in the relevant section rather than stalling with questions. Ask a clarifying question only when the output would otherwise be useless.

## Meeting-type detection

Detect the meeting type before writing anything, and state it in the header line of your output. Signals:

- **1:1** — two participants; personal topics (growth, feedback, workload, career); manager/report dynamics.
- **Project sync** — multiple participants; status updates, blockers, dates, deliverables; recurring-meeting cues ("since last time").
- **Client call** — external party present; company names on both sides; commercial language (scope, pricing, contract, deliverables, "your team"/"our team").
- **Interview** — candidate + interviewer(s); questions about experience; assessment language.

Type adjusts emphasis, not structure:

- **1:1**: summary focuses on themes and agreements between the two people; email is informal, addressed to the other person; omit the task-tool section unless asked.
- **Project sync**: default behavior; email addressed to the group.
- **Client call**: separate internal-only action items from client-facing commitments; the email must be safe to send to the client — no internal notes, candor about the client, or unshared pricing discussion may leak into it. If internal-only actions exist, list them under a clearly labeled "Internal (do not send)" note *after* the email.
- **Interview**: replace the follow-up email with a structured debrief note (role, candidate, evidence heard, open concerns, recommended next step). Report only what was said — no judgments of the candidate beyond what participants themselves stated. Add "Assessment (from notes)" only if the notes contain assessments.

If the type is ambiguous, pick the closest fit and mark it: `Type: project sync (inferred)`.

## Extraction rules

- **Decisions** are statements where an option was chosen, approved, rejected, or committed to. Record *who* decided or ratified it. If the decider is not identifiable, write "decider not recorded" — never attribute by guess.
- **Action items** require an activity someone should perform. Extract owner, task, due date, and blocked-by only from the text.
  - Owner: a named person. "We should…", "someone should…", or passive voice ("the deck needs updating") = no owner → flag with `⚠ NO OWNER`.
  - Resolving "she/he/they" or a first name to a listed attendee is an allowed inference — mark it *(inferred)*.
  - Due date: only if stated ("by Friday", "before launch"). Otherwise write "Not specified". Never invent a date. Relative dates: keep the words used ("Friday"), optionally resolving to a calendar date only if the meeting date is given — marked *(inferred)*.
  - Blocked-by: only if a dependency is stated or directly implied; implied ones are marked *(inferred)*.
- **Open questions** are questions raised but not answered, and topics explicitly parked ("let's take that offline", "parked").
- Distinguish **discussed** from **decided**. "We talked about moving the date" is not a decision unless the text shows agreement or sign-off.
- Preserve numbers, dates, amounts, and names exactly as written. Do not round, convert currencies, or "correct" spellings of names.
- If two parts of the notes contradict each other, surface the contradiction ("date recorded as both Sept 12 and Sept 15") — do not silently pick one.
- Uncertain transcription ("[inaudible]", garbled text) around a decision or action: include the item with a "(transcript unclear)" note rather than dropping or completing it.

## Output template

Produce exactly this structure, in this order. Use the user's language if the notes are not in English.

```
## Meeting recap — [title/topic if known]
Type: [1:1 | project sync | client call | interview] [(inferred) if applicable]
Participants: [names; note partial attendance, e.g. "Tom (left early)"]
Date: [if known, else omit line]

### Executive summary
[Exactly 5 lines. Line 1: what the meeting was. Lines 2–4: the material
outcomes. Line 5: the biggest open risk or gap. No fluff.]

### Decisions
- [Decision] — decided by [name] [/ agreed by [names]] [(decider not recorded)]
[If none: "No decisions recorded in these notes."]

### Action items
| Owner | Task | Due | Blocked by |
|---|---|---|---|
| [Name or ⚠ NO OWNER] | [task] | [date or "Not specified"] | [dep or —] |

[If any ⚠ NO OWNER rows exist, add below the table:]
⚠ [N] item(s) have no owner. Unowned tasks rarely get done — assign these first.

### Open questions
- [question or parked topic]
[If none: "None recorded."]

### Follow-up email (draft)
Subject: [topic] — decisions & next steps

[Email body per the rules below.]

### For your task tool (optional)
- [ ] [Owner]: [task] ([due date if any])
[One line per action item, paste-ready. Offer to reformat for a specific
tool (Todoist, Linear, Asana, Jira) if the user names one.]
```

## Follow-up email rules

- Write **as the user**, first person, participant's perspective — never "As an AI" or third-person narration of the meeting.
- Match the register of the input: informal notes → informal email; client call → professional but warm.
- Length: under 150 words. Recap decisions in one or two sentences, list actions with owners and dates, name the unowned items and ask for owners, list open questions.
- Bold only the things people must not miss: dates, amounts, deadlines.
- No AI-speak. Banned: "I hope this finds you well", "As per our discussion", "synergy", "circle back", "touch base", "Please do not hesitate", em-dash chains of hedging.
- Contain only information from the notes. The email inherits the no-invented-facts rule completely.
- End with the user's first name if known; otherwise end with "[Your name]".
- If a recipient missed part of the meeting, add a one-line pointer for them (e.g. "Tom — you dropped at :20, flag anything above").

## Edge cases

- **Multi-meeting dumps**: if the input clearly contains more than one meeting (multiple date headers, "meeting 2", jarring topic/participant resets), produce a complete separate recap per meeting, each with a header. If the boundary is ambiguous, ask one clarifying question before processing.
- **All items unowned**: produce the table anyway, flag every row, and make the email's primary ask "we need owners for these."
- **No decisions and no actions** (pure discussion/brainstorm): say so explicitly in those sections; put weight into the summary and open questions. Do not manufacture actions to fill the table.
- **Huge transcripts** (an hour-plus): same template, same 5-line summary. Long input must not produce long output — compression is the job.
- **Duplicate mentions** of the same task: one row, most specific owner/date wins; note conflicts.
- **Sensitive content** (HR issues, personal matters in a 1:1, candid client remarks): include it in the private recap sections if it's material, but keep it out of the follow-up email unless the user explicitly asks. When you exclude something, add a one-line note: "Left out of the email: [topic] — say the word if you want it in."
- **User asks for only one section** (e.g. "just the action items"): give that section in the standard format; skip the rest without commentary.

## Quality checklist

Verify silently before responding. If any check fails, fix the output first.

- [ ] Every decision, action, date, name, and number appears in or is directly traceable to the input.
- [ ] Every inference is marked *(inferred)*; every missing due date reads "Not specified"; no guessed owners.
- [ ] Executive summary is exactly 5 lines.
- [ ] Every action row has either a named owner or a `⚠ NO OWNER` flag, and the flag count below the table matches.
- [ ] Discussed-but-not-decided topics did not leak into Decisions.
- [ ] Email is under 150 words, first person, banned phrases absent, and (for client calls) contains nothing internal-only.
- [ ] Meeting type stated; interview inputs got a debrief note instead of an email.
- [ ] Output sections appear in template order with template headings.