Meeting Notes to Next Actions

The Prompt

You are an operations facilitator who converts messy meeting notes into a practical execution plan.

MEETING NOTES:
{{meeting_notes}}

TEAM CONTEXT:
{{team_context}}

DECISION DEADLINE:
{{decision_deadline}}

KNOWN CONSTRAINTS:
{{known_constraints}}

DESTINATION SYSTEM:
{{destination_system}}

Return exactly:
1) Missing or unclear context
   - what is too ambiguous to resolve confidently
   - what should be confirmed before execution
2) Decisions already made
   - bullet list with only confirmed decisions from the notes
3) Open decisions still unresolved
   - issue
   - recommended owner role
   - decision deadline or `TBD`
4) Action plan table
   - action
   - owner
   - due date
   - dependencies
   - risk if delayed
5) 48-hour follow-up draft
   - short sendable update to the team
6) System-of-record handoff
   - what should be written to {{destination_system}}
   - what should stay draft-only until human confirmation
7) What could slip
   - top 3 delivery risks
   - one mitigation each

Rules:
- Prefer concrete verbs (draft, review, approve, ship) over vague items.
- If owner or due date is missing, mark it explicitly instead of guessing.
- Flag contradictions in notes explicitly.
- Do not promote tentative discussion into confirmed decision.
- If the notes are too thin to support a real action plan, say what is missing before drafting the plan.
- Keep output concise and execution-ready.
- Keep the destination-system handoff factual and draft-oriented; do not assume an automated write already happened.

When to Use

Use this right after planning or cross-functional meetings where notes are long but accountability is unclear. It works best when a team needs immediate clarity on ownership, deadlines, unresolved decisions, and where the follow-through should live after the meeting.

Variables

Variable	Description	Example
meeting_notes	Raw notes, transcript excerpts, or action bullets	”Roadmap sync notes copied from docs, including unresolved debate about launch date”
team_context	Team roles, ownership boundaries, and project stage	”PM owns scope, Eng lead owns sequencing, legal approves customer-facing changes”
decision_deadline	Final date for unresolved decisions, if one exists	”By Friday EOD”, “Before next steering meeting”, “TBD”
known_constraints	Capacity, legal, technical, or timing limits already known	”Two engineers available, compliance review needed, no launch before migration completes”
destination_system	Where the final action register should live	”Notion project database”, “Jira board”, “Google Doc + Slack follow-up”

Tips & Variations

• Paste the notes in their raw form first. Cleaning them too much before prompting often removes the contradictions and unknowns you actually need surfaced.
• Add attendee roles and meeting purpose in team_context when ownership is likely to be ambiguous.
• For recurring meetings, ask the model to compare this week’s actions to last week’s unfinished items instead of treating every meeting as a fresh start.
• Add “format the follow-up as Slack” or “format as email” only after the action table is already solid.
• When the action register will be stored in Notion, Jira, or another workspace system, ask for a clear draft handoff section instead of letting the model blur summary and execution.

Example Output

Missing context: No confirmed owner is listed for pricing approval, and the notes do not say whether legal review is still required.

Decision made: API launch stays behind feature flag.

Action row: “Draft customer migration email” | Owner: Marketing | Due: Mar 3 | Dependency: final pricing copy | Risk: customer comms slip.