The Meeting Decision Log Extractor: Turn a Messy Transcript Into Who-Owns-What
Why this prompt matters
Teams routinely walk out of the same meeting with three different understandings of what was decided, and only discover the mismatch when someone ships the wrong thing two sprints later. A vague 'we'll sort it out' that gets written into a recap as a firm decision is one of the most common sources of cross-functional rework — and it is far cheaper to catch the ambiguity in the first hour after the meeting than to unwind a sprint's worth of misdirected work.
What we use it for
A product manager just left a 45-minute cross-functional planning meeting between engineering, design, and marketing about a delayed Q3 feature launch, and needs to send a decision recap within the hour — before people's memories of who-agreed-to-what start to diverge — but manually re-listening to the recording or notes to reconstruct exactly what was agreed would take 20+ minutes and still risk missing a contradiction between two speakers.
Prompt
Act as an experienced chief-of-staff or operations lead who has run hundreds of cross-functional meetings and knows exactly how a vague "we'll figure it out" turns into three teams building three different things a week later. CONTEXT: - Meeting transcript or raw notes: [MEETING TRANSCRIPT OR NOTES] - Participants and their roles: [MEETING PARTICIPANTS AND ROLES] - Meeting purpose/agenda: [MEETING PURPOSE] TASK: Extract a clean decision log from the raw meeting content. Distinguish clearly between what was actually decided and what was merely discussed. CONSTRAINTS: - Only list something as a "Decision Made" if the transcript shows clear agreement — do not invent an owner or deadline if none was actually stated - If a decision sounded final but had no named owner or deadline, flag it under Ambiguity Flags instead of the Decisions table — do not guess - If two participants appeared to agree on different versions of the same decision, call out the contradiction explicitly - Do not pad the output with meeting-process commentary (no "the meeting opened with..." narration) — go straight to substance - Keep each decision to one line; put nuance and caveats in a separate notes column, not the decision text itself OUTPUT FORMAT: 1. Decisions Made (table: Decision | Owner | Deadline | Confidence — high/medium/low based on how explicit the transcript was) 2. Open Items Requiring Follow-up (things discussed but not resolved, with who needs to weigh in next) 3. Ambiguity Flags (things that sounded decided but had no clear owner/deadline, or where speakers seemed to disagree) 4. Suggested One-Line Recap (a single Slack-ready message summarizing the meeting's outcome for people who weren't there)
Result
1. Decisions Made
| Decision | Owner | Deadline | Confidence |
|---|---|---|---|
| Q3 launch date moves from Aug 15 to Sep 5 | Priya (PM) | Confirmed in meeting | High |
| Onboarding flow ships without the referral-code step for launch; referral code becomes a fast-follow | Dan (Eng Lead) | Fast-follow by Sep 19 | High |
| Marketing holds the press release until engineering confirms the new date is locked | Sam (Marketing) | Confirmation needed by Aug 29 | Medium — Sam agreed but didn't explicitly confirm the Aug 29 checkpoint date, inferred from context |
2. Open Items Requiring Follow-up
- Design has not confirmed whether the simplified onboarding flow needs new user-research validation before the Sep 5 date — Priya to follow up with Design lead (Wren) directly, not resolved in this meeting
- Budget for the delayed launch's paid marketing push was mentioned as "probably fine" by Sam but not confirmed against actual Q3 budget — needs Finance sign-off before marketing commits spend
3. Ambiguity Flags
- Dan said engineering "should be able to" hit Sep 5, which is weaker language than a firm commitment — this is recorded as a decision in the log above but the confidence is medium-high, not certain; recommend a written confirmation from Dan before treating Sep 5 as locked
- Priya and Sam appeared to agree the referral code delay was fine, but Sam's tone ("I guess that works") suggests lower conviction than Priya's framing implied — worth a direct check-in with Sam before external commitments reference the fast-follow date
4. Suggested One-Line Recap
"Q3 launch moves to Sep 5 without referral codes (fast-follow by Sep 19); marketing holds the press release until engineering reconfirms the date by Aug 29 — still need Design's read on onboarding research and Finance sign-off on the delayed launch's ad budget."
Every team has lived through this: a 45-minute planning meeting ends, everyone nods, and two weeks later it turns out three people walked away with three different understandings of what was actually agreed. The recap email gets written from memory, someone's confident paraphrase of "we'll sort it out" becomes a hard commitment in writing, and by the time anyone notices the mismatch, a sprint's worth of work is already pointed in the wrong direction.
This prompt is built to catch that gap in the first hour, not after the fact. It takes a raw meeting transcript or notes and produces a decision log that draws a hard line between what was genuinely decided and what merely sounded decided.
Why the ambiguity-flagging matters more than the decision list
Most meeting-summary tools happily produce a clean list of "decisions" — but a clean-looking list is exactly the problem when half of it was never actually locked down. This prompt is explicitly instructed not to invent an owner or deadline when the transcript doesn't state one, and to flag soft language ("should be able to," "I guess that works") as lower-confidence even when it's technically an agreement. That distinction is the entire value of the prompt: it's designed to surface the two or three decisions in every meeting that feel resolved in the room but will unravel the moment someone acts on them without a real owner attached.
How to use it
Paste in a transcript or your own rough notes along with who was in the room and what the meeting was for. Run it immediately after the meeting ends, while the context is still fresh enough to sanity-check the output against your own memory — the ambiguity flags are most useful as a prompt for a two-minute follow-up message ("hey, can you confirm you're actually on the hook for X by Y"), not as a final record on their own.