Meeting Summary Expert

Overview

Transform meeting notes, transcripts, or recordings into clear, actionable summaries. Every summary follows a consistent structure that makes it easy for attendees and non-attendees alike to understand what was discussed, what was decided, and who is doing what by when.

When to Use

• After any meeting where decisions were made or actions were assigned.

• Sprint ceremonies -- planning, retro, backlog refinement, sprint review.

• Stakeholder meetings -- steering committees, executive reviews, client calls.

• Ad-hoc discussions -- when an impromptu conversation produces commitments that need tracking.

Methodology

Step 1: Capture Meeting Metadata

Record the essential context:

Field Description

Date Meeting date (YYYY-MM-DD)

Time Start and end time with timezone

Participants Names and roles (e.g., "Sarah Chen, Product Lead")

Topic One-line meeting purpose

Location Room name, video link, or "async"

Step 2: Extract Key Discussion Points

From the raw notes or transcript, identify the substantive topics discussed. Guidelines:

• Summarize, do not transcribe. Capture the essence of each topic in 1-3 bullet points.

• Use plain language. Avoid jargon. Anyone reading the summary should understand the points without having attended.

• Focus on what matters. Skip small talk, repeated points, and tangential discussions.

• Note disagreements. If there was significant debate, capture the key positions and how they were resolved (or not).

Step 3: Extract Action Items

Every action item must answer three questions:

• Who is responsible? (Single owner, not a team)

• What specifically must they do? (Concrete, observable deliverable)

• By when? (Specific date, not "soon" or "next sprint")

Format as a table:

Due Date Owner Action

2026-03-10 Sarah Chen Share revised wireframes with the design team

2026-03-07 James Park Schedule load test for the staging environment

Action item quality checks:

• Each action has exactly one owner (not "Sarah and James")

• The deliverable is specific enough to verify completion

• The due date is a calendar date, not a relative timeframe

• Actions use active verbs: "share," "schedule," "draft," "review," "decide"

Step 4: Record Decisions

List each decision made during the meeting as a numbered item. Include enough context that someone who was not present understands the decision and its rationale.

Format:

• [Decision] -- [Brief rationale or context]. Decided by [who].

• [Decision] -- [Brief rationale or context]. Decided by [who].

Examples:

• Launch date set for April 15 -- Allows two full sprints for QA after feature freeze on March 28. Decided by steering committee.

• Use PostgreSQL instead of MongoDB for the analytics service -- Team consensus based on query pattern analysis showing 80% relational queries. Decided by engineering leads.

Step 5: Capture Open Questions

List unresolved questions that need follow-up. For each question, note who is expected to provide an answer and by when, if known.

• Do we need a separate staging environment for the new analytics service? (James to investigate by March 10)

• What is the budget ceiling for the Q2 marketing campaign? (Pending finance review)

Step 6: Save and Distribute

File naming convention: Meeting-Summary-[YYYY-MM-DD]-[topic-slug].md

Examples:

• Meeting-Summary-2026-03-04-sprint-planning.md

• Meeting-Summary-2026-03-04-q2-roadmap-review.md

Distribution:

• Share the summary within 24 hours of the meeting.

• Send to all participants and relevant stakeholders who were not present.

• Store in the team's shared documentation space (Confluence, Notion, shared drive).

Output Template

Meeting Summary

Metadata

Summary

• [Key discussion point 1]
• [Key discussion point 2]
• [Key discussion point 3]

Action Items

Decisions Made

1. [Decision] -- [Rationale]. Decided by [who].

Open Questions

1. [Question]? ([Who is expected to answer, by when])

What to Focus On

When summarizing, prioritize:

• Decisions that affect roadmap or strategy -- These have the broadest impact and are most likely to be referenced later.

• Who does what by when -- Accountability is the primary value of a meeting summary.

• Blockers and risks surfaced -- These need visibility beyond the meeting room.

• Changes to previously agreed plans -- These create confusion if not documented.

When summarizing, deprioritize:

• Status updates that are available elsewhere (Jira, dashboards)

• Repetition of information already documented

• Social conversation and small talk

• Detailed technical discussions better captured in design docs

Integration with Other Skills

• Feed decisions into wwas/ to create backlog items with strategic context.

• Use action items to create tickets via ../jira-expert/ .

• Document recurring meeting outcomes in ../confluence-expert/ templates.

References

• See references/meeting-facilitation-guide.md for meeting types, note-taking strategies, and anti-patterns.

• See assets/meeting_summary_template.md for ready-to-use templates.