Meeting Notes Skill

Meeting Notes Skill

This skill structures meeting notes to maximize value and ensure follow-through.

Required Inputs

Ask the user for these if not provided:

• Meeting title and date
• Attendees (names and roles)
• Raw notes or transcript (paste discussion notes, a transcript, or describe what was discussed)
• Meeting type (1:1 / sprint planning / product review / stakeholder sync / other) — determines which template to use

Reads from / Writes to the Brain

If a professional-brain (brain/) exists, this is where notes become durable memory:

• Read first: the relevant stakeholders/ files (so you arrive knowing each attendee's open asks and concerns) and any decisions/ the meeting revisits.
• Write after: append each decision (with its rationale and a reopen-when) to decisions/, add new asks/concerns to the right stakeholders/ file, and flag any new assumption into hypotheses/. Tag every captured fact with its provenance — most meeting statements are [verbal] until independently confirmed. Save the raw notes to source/.

Standard Meeting Notes Template

Meeting Header

Meeting: [Meeting Title]
Date: [Date]
Attendees: [Names/Roles]
Note Taker: [Name]
Duration: [Actual duration]

Agenda

• Topic 1
• Topic 2
• Topic 3

(Check off items as discussed)

Decisions Made

Clear documentation of decisions:

Decision: [What was decided]
Context: [Why this decision]
Owner: [Who's responsible for executing]
Deadline: [When if applicable]

Use this format for each decision made.

Action Items

All action items should be:

• [Action item] - @Owner - Due: [Date]
• [Action item] - @Owner - Due: [Date]

Format:

• Clear, specific action
• Single owner (no "team" ownership)
• Concrete deadline
• Checkbox for tracking

Discussion Notes

Key points discussed organized by topic:

Topic 1: [Name]

• Key point or discussion highlight
• Important context or concern raised
• Any data or information shared

Topic 2: [Name]

• Key discussion points
• Decisions or conclusions reached

Open Questions / Follow-Up

Questions that couldn't be answered:

• Question: [What we need to know]
• Owner: [Who will find out]
• By When: [Deadline]

Next Steps

Clear summary of what happens next:

1. [Immediate next action]
2. [Follow-up meeting if needed]
3. [Any broader process to start]

Best Practices

During the meeting:

• Focus on decisions and action items over dialogue
• Capture specific commitments, not general discussion
• Note dissenting opinions on important decisions
• Ask for clarity on vague commitments ("I'll look into it" → "I'll analyze the data and share findings by Friday")

After the meeting:

• Send notes within 2 hours while fresh
• Tag action item owners (@mention them)
• Include links to relevant documents
• Follow up on overdue action items

What to capture: ✅ Decisions made ✅ Action items with owners and deadlines ✅ Key points of discussion ✅ Open questions ✅ Next steps

What to skip: ❌ Verbatim transcripts ❌ Off-topic tangents ❌ Preliminary discussion before decisions ❌ Redundant information

Meeting Types & Adaptations

1:1 Meetings

Focus on:

• Career development discussions
• Feedback (both directions)
• Current challenges
• Action items for both parties

Template additions:

• Recent Wins: What's going well
• Challenges: What's not going well
• Career Discussion: Development topics
• Feedback: For both parties

Sprint Planning

Focus on:

• Story acceptance criteria
• Sizing/estimation decisions
• Dependency identification
• Sprint commitment

Template additions:

• Sprint Goal: What we're committing to
• Story Points: Capacity and estimates
• Dependencies: External blockers
• Definition of Done: Acceptance criteria

Product Reviews

Focus on:

• Design decisions
• User feedback discussed
• Changes requested
• Launch readiness assessment

Template additions:

• Design Decisions: What was approved/rejected
• User Feedback: Key insights discussed
• Open Design Questions: What needs iteration
• Launch Criteria: Remaining requirements

Stakeholder Sync

Focus on:

• Status updates delivered
• Concerns raised
• Approvals given
• Escalation needs

Template additions:

• Status Overview: High-level progress
• Approvals Obtained: Sign-offs received
• Escalations: Issues raised to stakeholders
• Next Sync: When and what to cover

Example Meeting Notes

# Product Roadmap Review - Q1 2026
**Date**: January 20, 2026  
**Attendees**: Sarah (CPO), Mike (Eng Lead), Jennifer (Design), Tom (PM)  
**Note Taker**: Tom  
**Duration**: 45 minutes

## Agenda
- [x] Review Q1 planned features
- [x] Discuss resource constraints
- [x] Prioritization discussion
- [x] Timeline alignment

## Decisions Made

**Decision**: Move multi-channel dashboard to Q2, prioritize mobile app improvements for Q1  
**Context**: Customer feedback shows mobile experience is significantly impacting retention (65% of users primarily mobile). Engineering team can only tackle one major initiative this quarter.  
**Owner**: Tom (PM) to communicate to stakeholders  
**Deadline**: January 22

**Decision**: Allocate 20% of engineering time to technical debt  
**Context**: Accumulated tech debt is slowing feature development. Team velocity dropped 30% last quarter.  
**Owner**: Mike (Eng Lead) to create tech debt backlog  
**Deadline**: January 27

**Decision**: Run mobile beta with 100 users before full launch
**Context**: Need to validate improvements on diverse devices
**Owner**: Jennifer (Design) to coordinate with QA
**Deadline**: February 10

## Action Items
- [ ] **Update Q1 roadmap deck with new prioritization** - @Tom - Due: Jan 22
- [ ] **Schedule alignment meeting with support team about dashboard delay** - @Tom - Due: Jan 24
- [ ] **Create tech debt prioritization rubric** - @Mike - Due: Jan 27
- [ ] **Run user testing on mobile designs** - @Jennifer - Due: Feb 3
- [ ] **Document decision rationale for executives** - @Sarah - Due: Jan 23
- [ ] **Identify 100 beta users for mobile** - @Tom - Due: Feb 1

## Discussion Notes

**Q1 Feature Prioritization**
- Customer retention is #1 company priority this quarter
- Mobile app NPS score is 6.2 (vs 8.1 for web)
- Mobile accounts for 65% of daily active users
- Multi-channel dashboard would take 8 engineering weeks
- Mobile improvements estimated at 6 engineering weeks with higher ROI
- Sales has 3 enterprise deals waiting on dashboard feature

**Resource Constraints**
- Currently 4 engineers available (down from 6 last quarter due to attrition)
- Design team can support both initiatives but at reduced capacity
- QA team needs 2 weeks for thorough testing on mobile
- One engineer on loan to security team through February

**Risk Discussion**
- Delaying dashboard may impact enterprise sales (3 deals waiting)
- Sarah noted: "We can position mobile improvements as foundation for enterprise features"
- Mike raised concern about mobile tech stack stability - addressed through tech debt allocation
- Need to communicate clearly with Sales about timeline change

**Mobile Implementation Plan**
- Week 1-2: Design refinements based on user feedback
- Week 3-4: Engineering implementation
- Week 5: Internal testing
- Week 6: Beta with 100 users
- Week 7: Full rollout

## Open Questions
- **Question**: What's the impact on enterprise pipeline if we delay dashboard?  
  **Owner**: Sarah will check with Sales leadership  
  **By When**: January 23

- **Question**: Can we do a limited beta of dashboard for enterprise customers?  
  **Owner**: Tom will explore MVP scope with Mike  
  **By When**: January 25

- **Question**: What's our plan if mobile improvements don't hit target metrics?
  **Owner**: Tom will create contingency plan
  **By When**: January 27

## Next Steps
1. Tom to send updated roadmap to leadership by EOD Wednesday (Jan 22)
2. Team to begin sprint planning for mobile improvements next Monday (Jan 27)
3. Follow-up meeting on Feb 1 to review progress and validate prioritization
4. Sarah to present decision rationale to executive team on Jan 24

---

**Next Meeting**: February 1, 2026 - Progress Check-in
**Notes Sent**: January 20, 2026 5:30 PM

Deeper Materials

This skill ships with support files — use them when they are available:

• references/decisions-vs-discussion.md — Separating Decisions from Discussion. Apply it while producing the output; it carries the calibration and judgment calls the method summary above compresses.
• templates/notes-skeleton.md — a fill-in version of the deliverable with the quality gates inline. Offer it when the user wants to work the document themselves rather than have it generated.

Scoring Rubric (0–40)

Score any output of this skill before handing it over; 32+ is ship-quality.

Dimension	0	5	10
Action-item accountability	Actions assigned to "the team" or nobody, with no dates	Named owners but vague deadlines ("next week", "soon") or co-owned blobs	Every action has exactly one named owner and a concrete date; shared work split into separately-owned items
Decision traceability	Decisions buried in discussion or recorded without any why	Decisions listed with owners but rationale thin; disagreement invisible	Each decision carries context, owner, and deadline; dissent recorded inside the decision with a revisit condition, not smoothed over
Synthesis over transcript	Verbatim capture of who said what, in order	Trimmed transcript grouped by topic, but still dialogue rather than distillation	Discussion reduced to load-bearing points; quotes appear only where they carry decision weight
Loop closure	Open questions, deferred topics, and escalations silently dropped	Open items listed but ownerless or dateless; deferrals vanish from next steps	Every open question has an owner and by-when; deferred items reappear in next steps with dates; notes sent within the 2-hour window

Quality Checks

• Every action item has a single named owner (not "team")
• Every action item has a concrete deadline
• Decisions include context (why the decision was made)
• Open questions have an owner and a "by when"
• No verbatim transcripts — synthesis only

Anti-Patterns

• Do not assign action items to "the team" or "everyone" — every action item must have exactly one named owner or it will not be completed
• Do not capture verbatim transcript content — meeting notes record decisions and commitments, not the full conversational path to get there
• Do not omit the context for decisions — a decision without its rationale is useless when someone asks "why did we do that?" six months later
• Do not leave open questions without an owner and deadline — an unanswered question with no follow-up assigned is a blocked decision
• Do not delay sending notes beyond 2 hours after the meeting — notes sent the next day miss the window when action item owners can act on commitments while fresh

Notes Distribution

Subject Line Format: "[Meeting Type] Notes - [Date] - [Key Topic]"

Example: "Product Roadmap Review Notes - Jan 20 - Q1 Prioritization"

Recipients:

• All attendees
• Anyone mentioned in action items
• Anyone who requested notes

Follow-Up:

• Send reminder 3 days before action item due dates
• Weekly summary of all open action items
• Mark action items as complete and share updates

Execution

For tool-using agents with connected MCP servers (Notion, Linear/Jira, Slack). Runtimes without tool access ignore this section and deliver the document. See SKILLSPEC.md §5 and connectors/mcp-pairings.md.

Preconditions

• The structured notes above have been shown to the human and explicitly approved, including the destination (which Notion database/page, which tracker project).
• The MCP servers are already connected and authenticated in the agent's environment.
• Action items each have a named owner — unowned items are resolved with the human first, never assigned by guess.

Allowed actions

• Create ONE page in the approved Notion database (or equivalent docs tool) containing the approved notes, verbatim.
• Create one tracker issue per approved action item (title, owner, due date from the notes) in the approved project.
• Post the page link (only the link and a one-line summary) to the approved channel, if the human named one.
• Nothing else: no editing existing pages/issues, no inviting or notifying people beyond the named channel, no calendar writes.

Verification

• Fetch the created page and each created issue; confirm titles, owners, and dates match the approved notes.
• Report every created URL back to the human in one list.

Rollback

• Undo = archive/delete the just-created page and issues, only on explicit human instruction.
• Stop and ask a human if: the destination database/project is not found, any issue creation fails partway (report what WAS created), or an action-item owner does not exist in the tracker.