Markdown meeting notes: a template for decisions and actions

A useful meeting note is a record people can act on. Start with the purpose and date, then keep discussion, decisions, actions, and unanswered questions in separate sections. Markdown gives the note a readable structure while keeping the original file simple to edit, diff, and share.

Copy the meeting-notes template

Replace the example labels with your team's terms. If the note will be shared beyond the people in the room, define acronyms and link background material.

# Project planning sync — 2026-11-04

## Purpose
Agree on the next release scope and identify blockers.

## Attendees
- Name — role or team
- Name — role or team

## Discussion
### Topic: release scope
- What changed since the last review?
- Which constraints or risks need a follow-up?

## Decisions
- We will ship the smaller migration first. See [ADR 012](../decisions/012-smaller-migration.md).

## Actions
- [ ] Priya — draft the migration checklist — due 2026-11-08
- [ ] Sam — verify the rollback steps — due 2026-11-10

## Open questions
- Does the change affect the existing import workflow?

## Next check-in
2026-11-11 — review the checklist and rollback test.

Make actions unambiguous

Write each action as owner + verb + deliverable + due date. “Investigate export” is hard to hand off. “Maya — test the PDF export on the compatibility fixture — due Friday” tells everyone what completion means.

• Put confirmed decisions in their own section instead of leaving them inside a discussion paragraph.
• Use an unchecked list item for a pending action and a checked item only when the source file is updated to show it is complete.
• Record an open question when the group did not reach a decision. Name who will bring the answer back.
• Link to tickets, documents, or an ADR instead of copying a large technical explanation into the notes.

In GitHub Flavored Markdown, task-list markers such as - [ ] and - [x] render as checkbox indicators. Their interactive behavior depends on the product displaying the Markdown. In an editor preview, the source remains the place to update the task state unless the product explicitly supports editing the checkbox.

Close the loop

1. Capture the purpose and attendee list before the meeting when practical.
2. During the meeting, use short bullets for observations and a separate line for each decision.
3. Before ending, read actions aloud and confirm the owner and deadline with the person responsible.
4. Afterward, share the note in the team's normal system and link it from the related issue or project page.
5. At the next check-in, mark completed actions in the source file or record why they remain open.

A dated filename can help notes sort in a folder, for example 2026-11-04-release-planning.md. Avoid putting confidential discussion or personal information into a broadly shared notes file unless the team has agreed on its access and retention rules.

When to create a separate decision record

Meeting notes capture the flow of a conversation; they are not always the best long-term home for a consequential architecture choice. When a decision affects system structure, dependencies, security, or an interface, create a concise Architecture Decision Record and link to it from the notes. This keeps the meeting context while making the enduring decision easier to find.

Want to inspect a small example? Try it in a Markdown preview, then verify your publishing destination.