summarize-meeting

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:

1. Who is responsible? (Single owner, not a team)
2. What specifically must they do? (Concrete, observable deliverable)
3. 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:

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

Examples:

1. Launch date set for April 15 -- Allows two full sprints for QA after feature freeze on March 28. Decided by steering committee.
2. 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.

1. Do we need a separate staging environment for the new analytics service? (James to investigate by March 10)
2. 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

| Field | Value |
|-------|-------|
| **Date** | [YYYY-MM-DD] |
| **Time** | [HH:MM] - [HH:MM] [TZ] |
| **Participants** | [Name, Role]; [Name, Role]; ... |
| **Topic** | [One-line meeting purpose] |

## Summary

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

## Action Items

| Due Date | Owner | Action |
|----------|-------|--------|
| [YYYY-MM-DD] | [Name] | [Specific, verifiable action] |

## 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.

Troubleshooting

| Problem | Likely Cause | Resolution | |---------|-------------|------------| | Action items are assigned to teams instead of individuals | Culture avoids individual accountability; facilitator does not press for a single owner | Enforce the "one owner" rule during the meeting; if a team is named, ask "Who on that team is the single point of contact?" | | Summaries are too long and nobody reads them | Summarizer includes too much detail; tries to capture everything | Apply the "would someone who missed the meeting need this?" filter to every bullet point; target 1 page maximum for 1-hour meetings | | Decisions are not documented, leading to re-litigation in future meetings | Meeting moved quickly; facilitator focused on discussion, not decisions | Pause after each decision and state it aloud: "Let me confirm: we decided X because Y"; add decision capture as a facilitator checklist item | | Action items have vague due dates ("soon", "next sprint") | Facilitator does not push for specificity; team uncomfortable committing to dates | Require a calendar date for every action; if the team cannot commit, set a date to decide the date | | Summaries are distributed days after the meeting | Summarizer is overburdened or perfectionist | Set a 24-hour distribution rule; use a structured template to reduce writing effort; assign summary responsibility before the meeting | | Open questions from previous meetings are never resolved | No follow-up mechanism; questions captured but not tracked | Add "Previous Open Questions" as a standing agenda item; assign each question an owner and a resolution date | | Attendees disagree with the summary after distribution | Summary reflects summarizer's interpretation, not group consensus | Share key decisions and action items verbally at the meeting close; invite corrections within 24 hours of distribution |

Success Criteria

• 100% of meetings with decisions or action items produce a written summary within 24 hours
• Every action item has a single named owner and a specific calendar due date
• Action item completion rate exceeds 80% by the stated due date
• Summaries are 1 page or less for meetings under 1 hour
• Decisions are documented with enough context that a non-attendee can understand the rationale
• Open questions fr