What each part of the prompt does
- A definition of decision
- "Something the group agreed to do, stop or change" gives Claude a test to apply. Without it, every idea mentioned in passing ends up in the log as if it had been agreed.
- Placeholders instead of guesses
- [OWNER?] and [DATE?] make gaps visible. A log with an invented owner is worse than one with a question mark, because the named person never knows the task is theirs.
- Transcript inside the context tag
- Long transcripts work well with Claude when they sit inside <context>, separate from the instructions. The model reads them as material to analyse rather than as part of the request.
- Tables you can paste
- Fixed columns for decisions and actions paste cleanly into docs, spreadsheets and most project tools, so the log becomes the task list instead of another document to retype.
Variations to try
Same idea, one thing changed.
Follow-up email to attendees You are an operations lead who turns messy meeting notes into a record the team can act on. <context> Meeting: [MEETING NAME] on [DATE] People present: [ATTENDEES] Raw notes or transcript: [NOTES] </context> <instructions> 1. List every decision that was actually made. A decision is something the group agreed to do, stop or change. 2. For each decision, record who owns it and the reason given in the notes. 3. List every action item with an owner and a due date. If the notes do not name an owner or a date, write [OWNER?] or [DATE?] instead of guessing. 4. List the questions that were raised but not settled, and who should answer each one. 5. Note any disagreement that was left open, in neutral words. </instructions> <constraints> - Use only what is in the notes. Do not fill gaps with likely outcomes. - Treat ideas that were only discussed as open questions, not decisions. - Keep each line short enough to read in a chat message. </constraints> <output_format> Decisions: a table with the columns Decision, Owner, Reason. Action items: a table with the columns Task, Owner, Due. Open questions: bullets, each with the person who should answer. Summary: three sentences for people who missed the meeting. Follow-up email: a short email to all attendees with the decisions and each person's action items, under 150 words. </output_format>
Running decision log entry You are an operations lead who turns messy meeting notes into a record the team can act on. <context> Meeting: [MEETING NAME] on [DATE] People present: [ATTENDEES] Raw notes or transcript: [NOTES] </context> <instructions> 1. List every decision that was actually made. A decision is something the group agreed to do, stop or change. 2. For each decision, record who owns it and the reason given in the notes. 3. List every action item with an owner and a due date. If the notes do not name an owner or a date, write [OWNER?] or [DATE?] instead of guessing. 4. List the questions that were raised but not settled, and who should answer each one. 5. Note any disagreement that was left open, in neutral words. </instructions> <constraints> - Use only what is in the notes. Do not fill gaps with likely outcomes. - Treat ideas that were only discussed as open questions, not decisions. - Keep each line short enough to read in a chat message. </constraints> <output_format> Decisions: one row per decision in the format Date | Decision | Owner | Reason | Revisit by, ready to append to an existing log. Action items: a table with the columns Task, Owner, Due. Open questions: bullets, each with the person who should answer. Summary: three sentences for people who missed the meeting. </output_format>
If the result isn't right
- Recorder transcripts are long; if Claude misses decisions near the end, split the transcript in two and run the prompt on each half.
- Send the log to attendees the same day and ask them to fix any [OWNER?] lines; that one round of replies is where the real owners appear.
- Keep each meeting's log in one running document so the next meeting can open with last time's open questions.