Why Markdown for Meeting Notes?
Meeting notes serve a critical function: they create a shared record of decisions, action items, and discussions. Without good notes, meetings become a black hole where information enters and never comes back out. People leave with different interpretations of what was agreed upon, action items are forgotten, and the same topics get discussed again in the next meeting.
Markdown is an excellent format for meeting notes because it solves several common problems:
Speed: You can capture information quickly during a meeting. Markdown’s minimal syntax means you spend keystrokes on content, not on formatting. A dash creates a bullet point. A bracket creates a checkbox. No mouse clicking required.
Structure: Markdown headings and lists naturally impose structure on your notes. Instead of a wall of text, you get organized sections that are easy to scan after the meeting.
Searchability: Plain text files are easy to search. Six months from now, when you need to find the meeting where a particular decision was made, a simple text search across your notes folder will find it.
Portability: Markdown files work everywhere. They do not require specific software, they are tiny in size, and they will be readable decades from now. No subscription expiration will lock you out of your own meeting history.
Version control: If your team uses Git, meeting notes can live in the same repository as your project. Changes are tracked, and the full history is preserved.
The Meeting Note Template
A good template ensures consistency across meetings and makes it easy to capture the right information. Here is a template that works for most teams:
---
title: "Weekly Standup - Product Team"
date: 2025-03-15
attendees:
- Alice Chen
- Bob Martinez
- Carol Kim
- David Park
absent:
- Eve Johnson (on PTO)
---
# Weekly Standup - Product Team
**Date:** March 15, 2025
**Time:** 10:00 - 10:30 AM
**Location:** Conference Room B / Zoom
**Facilitator:** Alice Chen
**Note-taker:** Bob Martinez
## Agenda
1. Sprint progress review
2. Blockers and dependencies
3. Design review for checkout flow
4. Open discussion
## Discussion
### Sprint Progress Review
- **Alice**: Completed the user authentication module.
Deployed to staging on Wednesday. Awaiting QA sign-off.
- **Bob**: API rate limiting is 80% done. Final testing
scheduled for Monday. No blockers.
- **Carol**: Dashboard redesign mockups are ready for
review. Will share Figma link after the meeting.
- **David**: Bug fixes for the payment module. Found an
edge case with international currencies. Needs
discussion with Alice.
### Blockers and Dependencies
- David's currency bug depends on the locale data from
the i18n service, which is maintained by Team B.
David will reach out to their tech lead.
- QA team is backlogged. Alice's auth module may not
get reviewed until next Wednesday.
### Design Review: Checkout Flow
- Carol presented three layout options for the new
checkout flow.
- Team preferred **Option B** (single-page checkout)
for its simplicity.
- Concern raised about address validation on mobile.
Carol will add a mobile-specific layout in the
next iteration.
## Decisions
1. **Checkout layout**: Proceeding with Option B
(single-page checkout).
2. **Currency handling**: Will use the ICU library
for locale-aware number formatting instead of
building a custom solution.
3. **QA prioritization**: Auth module review will be
escalated to QA lead.
## Action Items
- [ ] **David**: Contact Team B tech lead about i18n
locale data - **Due: March 17**
- [ ] **Carol**: Share Figma link for dashboard mockups
- **Due: March 15 (today)**
- [ ] **Carol**: Create mobile layout for checkout flow
- **Due: March 20**
- [ ] **Alice**: Escalate QA review with QA lead
- **Due: March 16**
- [ ] **Bob**: Complete API rate limiting tests
- **Due: March 18**
## Next Meeting
**Date:** March 22, 2025, 10:00 AM
**Agenda items to carry over:**
- Review mobile checkout layout
- QA status update for auth module
Breaking Down the Template
Header Section
The header captures the essential metadata: who was there, when, and where. Using YAML frontmatter makes this machine-readable, which is useful if you ever want to build tools that parse your meeting notes.
---
title: "Weekly Standup - Product Team"
date: 2025-03-15
attendees:
- Alice Chen
- Bob Martinez
---
Agenda
Write the agenda before the meeting. This sets expectations and keeps the discussion focused. During the meeting, you can add notes under each agenda item rather than writing everything in chronological order.
Discussion Notes
Capture key points, not every word. Meeting notes are not transcripts. Focus on:
- Statements that inform decisions
- Concerns or objections raised
- Data or facts shared
- Context that will be important later
Attribute statements to specific people. This creates accountability and makes it easy to follow up.
Decisions
Separate decisions from discussion. A dedicated decisions section makes it immediately clear what was actually decided versus what was merely discussed. Number your decisions for easy reference in follow-up communications.
Action Items
This is the most important section. Every action item should have:
- What: A clear description of the task
- Who: The person responsible (one person, not a group)
- When: A specific due date
Using Markdown checkboxes (- [ ]) makes it easy to track completion:
- [x] **Alice**: Set up staging environment - **Due: March 10** (completed)
- [ ] **Bob**: Write API documentation - **Due: March 18**
Different Meeting Types
One-on-One Meeting Notes
# 1:1 - Alice & Manager
**Date:** March 15, 2025
## Check-in
- How are things going? Any concerns?
- Workload feeling manageable?
## Progress & Wins
- Completed the auth module ahead of schedule
- Positive feedback from the security review
## Challenges
- Struggling with the new testing framework
- Would like more pair programming sessions
## Career Development
- Interested in taking the lead on the next
architecture review
- Planning to attend the React conference in May
## Action Items
- [ ] **Manager**: Schedule pair programming session
with senior engineer - **Due: March 20**
- [ ] **Alice**: Draft architecture review proposal
- **Due: March 25**
## Notes for Next Time
- Follow up on conference registration
- Discuss Q2 goals
Sprint Retrospective Notes
# Sprint 14 Retrospective
**Date:** March 15, 2025
**Sprint duration:** March 1-14
**Facilitator:** Carol Kim
## Sprint Metrics
| Metric | Target | Actual |
|:-------------------|:------:|:------:|
| Story points | 42 | 38 |
| Bugs found | - | 7 |
| Bugs fixed | - | 5 |
| PRs merged | - | 23 |
| Average PR time | 1 day | 1.5 days |
## What Went Well
- Cross-team collaboration on the payment module
was smooth
- New CI pipeline reduced build times by 40%
- Daily standups were focused and under 15 minutes
## What Could Be Improved
- PR reviews are taking too long (1.5 day average)
- Two stories were blocked by unclear requirements
- Test coverage decreased from 85% to 81%
## Action Items
- [ ] **Team**: Adopt a "review within 4 hours" rule
for PRs under 200 lines - **Starting next sprint**
- [ ] **David**: Set up automated test coverage
threshold in CI - **Due: March 18**
- [ ] **Carol**: Schedule requirement clarification
sessions before sprint planning - **Due: March 20**
Client Meeting Notes
# Client Meeting - Acme Corp
**Date:** March 15, 2025
**Attendees:**
- Our team: Alice (PM), Bob (Tech Lead)
- Acme Corp: Sarah (VP Product), Tom (Engineering Director)
## Project Status Update
- Phase 1 delivered on schedule (March 1)
- Client is satisfied with the dashboard module
- Performance metrics exceed the agreed benchmarks
## New Requirements Discussed
1. **Real-time notifications**: Acme wants push
notifications for critical alerts. Estimated
effort: 3-4 weeks.
2. **SSO integration**: Need to support Okta
and Azure AD. Estimated effort: 2 weeks.
3. **Custom reporting**: Export reports to PDF
with company branding. Estimated effort: 1 week
(using printmd for the PDF generation).
## Concerns Raised
- Tom concerned about data migration timeline
for Phase 2. We committed to providing a
detailed migration plan by March 25.
## Next Steps
- [ ] **Alice**: Send SOW amendment for new
requirements - **Due: March 18**
- [ ] **Bob**: Create technical spike for SSO
integration - **Due: March 22**
- [ ] **Alice**: Prepare data migration plan
- **Due: March 25**
Organizing Your Meeting Notes
Folder Structure
meetings/
team-standup/
2025-03-01.md
2025-03-08.md
2025-03-15.md
one-on-ones/
alice/
2025-03-05.md
2025-03-19.md
bob/
2025-03-07.md
2025-03-21.md
client/
acme-corp/
2025-03-15.md
beta-inc/
2025-03-12.md
retrospectives/
sprint-14.md
sprint-15.md
Naming Convention
Use the date as the filename prefix: 2025-03-15.md or 2025-03-15-weekly-standup.md. This sorts files chronologically by default and makes searching by date trivial.
Linking Related Notes
Cross-reference between meetings when topics carry over:
## Carry-over from [March 8 standup](./2025-03-08.md)
David's currency bug is still open. See
[original discussion](./2025-03-08.md#blockers).
Sharing and Archiving
Sharing After the Meeting
Send the notes within an hour of the meeting ending. The longer you wait, the less useful they become. Common sharing methods:
- Git commit: Push notes to a shared repository. Team members are notified through their normal Git workflow.
- Email: For stakeholders who do not use Git, send a summary email with the notes as a PDF attachment. Tools like printmd can convert your Markdown notes to a clean PDF.
- Slack/Teams: Post a summary in the team channel with a link to the full notes.
- Confluence/Notion: Some teams prefer wiki-based documentation. You can write in Markdown and paste into these tools.
Archiving Strategy
Meeting notes have different shelf lives. Standups from six months ago are rarely needed, but client meeting notes or decision records may be referenced years later.
Consider this archival approach:
- Active notes: Current quarter, easy access in your main folder.
- Archive: Older notes moved to an
archive/folder, organized by year. - Permanent records: Decision logs and client meeting notes kept indefinitely.
Tips for Better Meeting Notes
Before the Meeting
- Prepare the template with the agenda filled in.
- Review action items from the previous meeting.
- Share the agenda with attendees so they can prepare.
During the Meeting
- Focus on capturing decisions and action items, not every statement.
- Use abbreviations and shorthand; you can clean up after.
- Note who said what for accountability.
- Mark items that need follow-up with a clear indicator.
After the Meeting
- Clean up your notes within an hour while the discussion is still fresh.
- Verify action items with the responsible people.
- Share the notes promptly.
- Add any links, documents, or references mentioned during the meeting.
Do Not Transcribe
Meeting notes are not meeting transcripts. Capture the substance, not the conversation. If someone spent five minutes discussing a topic, the note might be two sentences summarizing their point and one action item.
Tools That Complement Markdown Meeting Notes
- Obsidian: Great for linking meeting notes to project notes and creating a knowledge graph of discussions.
- VS Code: Fast editing with Markdown preview and Git integration.
- printmd: Convert notes to PDF when you need to share with stakeholders who prefer formatted documents.
- Git: Version control for your notes. Track changes and maintain history.
- grep/ripgrep: Search across all your meeting notes instantly from the command line.
Conclusion
Markdown meeting notes are fast to write, easy to search, and simple to share. The key is consistency: use the same template, follow the same naming convention, and share notes promptly after every meeting.
Start with the template in this guide, adapt it to your team’s needs, and make meeting notes a habit rather than an afterthought. The thirty minutes you invest in good notes will save hours of confusion and repeated discussions down the line.