Foundation Meeting Recap

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

Meeting Recap

A meeting recap is a post-meeting topic-segmented summary produced for attendees and light distribution. It organizes content by topic rather than chronology, highlights decisions visually, and captures actions inline (with owner, due date, dependencies) per topic segment, plus a consolidated actions view at the end for scannability.

This skill absorbs what would otherwise be a separate "meeting-actions" skill. Actions in this family live alongside the context that makes them meaningful, not in a sibling artifact.

This skill belongs to the Meeting Skills Family. It conforms to the Meeting Skills Family Contract.

When to Use

• After any internal meeting that produces decisions or actions affecting attendees
• When a sibling foundation-meeting-agenda exists and needs reconciliation (planned vs. actual topics)
• When the team needs a topic-organized reference rather than a chronological transcript dump
• When inputs include a transcript (Zoom, Meet, Otter, Fireflies, Krisp MCP) or mixed notes and transcript

When NOT to Use

• Communicating outcomes to non-attendees. Use foundation-stakeholder-update. recap assumes reader context; stakeholder-update translates to readers without it.
• Cross-meeting synthesis (patterns across multiple meetings). Use foundation-meeting-synthesize.
• Synthesizing user research interviews across participants, not one meeting's attendees. Use discover-interview-synthesis. recap organizes a single meeting by topic; interview-synthesis finds patterns across many research conversations.
• Live meeting note-taking. This skill consumes finished inputs; it does not transcribe live.

Zero-friction execution

Per the family contract, this skill never blocks on interrogation. Default flow:

1. Read all provided inputs (transcript, notes, or hybrid) and note input quality upfront 2. Auto-discover related agenda via filename-prefix match on same-directory *_{title}_agenda.md 3. Run inference: meeting metadata from content, decisions from language markers, actions from imperative-future patterns, owners from attendee context 4. Present a brief inference summary and accept one-word go or corrections 5. Produce the recap

If invoked with --go, skip the inference summary. If the user provides all metadata upfront, no checkpoint appears.

Fabrication prohibition

This skill never fabricates owners, decisions, or actions. When an action lacks an explicit owner, it is captured as [owner: unassigned, needs confirmation] not invented. When a decision is implicit ("it sounded like we decided X"), it is flagged with a confidence marker rather than stated as fact. Trust decay from fabrication is worse than the mild friction of flagging.

Ownership reconciliation threshold (v1.1.0)

When the ratio of unassigned actions to total actions exceeds 0.3 (30%), OR when any high-priority action lacks an owner, the skill surfaces a dedicated ## ⚠ Ownership reconciliation required section at the top of the recap (above the topic segments) listing:

• All unassigned actions
• A suggested next step for each (who should probably own this based on topic context, flagged as inference)
• A recommended follow-up action (Slack thread, 15-min sync, async survey)

The shareable summary also leads with this flag when triggered: ⚠ Ownership reconciliation required: N of M actions lack owners.

The unassigned_action_ratio frontmatter field (float 0.0-1.0) records the ratio for downstream tools.

Rationale: a recap with 60% ownerless actions is "non-fabricated" (per the prohibition above) but operationally broken. a pile of broken tickets. The threshold makes this visible instead of silently shipping.

Instructions

When asked to create a meeting recap, follow these steps:

1. Parse inputs and detect type Transcript (timestamped speaker-attributed lines), notes (bullet or prose), or hybrid. Note input quality upfront. transcript plus structured notes is high; scrappy bullets is low.

2. Auto-discover related agenda Look in the same directory for a file matching the pattern {YYYY-MM-DD}_{HH-MMtimezone}_{title-slug}_agenda.md. If found, load it. its topic list is the recap's topic skeleton and its desired_outcomes drive the meeting-quality reconciliation.

3. Present go-mode inference summary Show detected meeting date, title, attendees (if inferred), input quality assessment. Accept go or corrections.

4. Topic-segment the content

• If agenda was loaded, use its topic list as scaffold (plus any emergent topics)
• If no agenda, identify topics from transcript discourse markers ("moving on to", "the other thing")

5. Per topic segment, extract

• Discussion summary: 2-3 sentences capturing what was discussed
• Decisions made: bold-flagged visually. Never fabricate. if uncertain, flag "appears to have decided X [confidence: medium]"
• Actions: owner + due date + dependencies. Flag missing owners as [owner: unassigned] and missing dates as [due: not specified]. Never invent.
• Open questions: unresolved items with confidence marker on whether they are truly unresolved or simply not re-raised

6. Consolidate actions by owner Regroup all actions under each owner. Enables single-owner scan ("what do I owe after this meeting?").

7. Reconcile agenda (if agenda loaded)

• topics_planned: from agenda topic list
• topics_hit: topics actually discussed
• topics_skipped: planned but not discussed, with brief reason
• topics_emerged: discussed but not on agenda

8. Assess meeting quality signals

• outcomes_achieved: N/M ratio of agenda desired_outcomes met (when agenda present)
• started_on_time / ended_on_time: from timestamps when available; skipped when not
• key_attendees_present: flag if decision-makers were absent

9. Surface next steps When we reconvene, what needs to happen on the critical path before that.

10. Render TEMPLATE.md and validate

• Every action's owner appears in attendees or is explicitly unassigned
• meeting_quality.outcomes_achieved matches N/M pattern when populated
• agenda_reconciliation fields present even when empty lists

Quality checklist

• [ ] Input quality flagged honestly (high / medium / low)
• [ ] Agenda auto-discovery attempted; result noted in Generation context
• [ ] Every topic segment has Discussion / Decisions / Actions / Open questions subsections
• [ ] Decisions are bold-flagged; never invented; confidence marked when inferred
• [ ] Every action has owner (or explicit unassigned) + due date (or explicit not specified)
• [ ] Consolidated actions view regrouped by owner
• [ ] Agenda reconciliation populated when agenda was loaded
• [ ] Meeting quality signals populated with data available; skipped fields flagged
• [ ] Shareable summary 5-6 lines, lead with decisions and top actions
• [ ] Sources and References Generation context notes transcript source and any missing owners/dates

See also

• Meeting Skills Family Contract
• `foundation-meeting-agenda`. upstream: provides topic skeleton and desired-outcomes
• `foundation-meeting-synthesize`. downstream: consumes recaps for cross-meeting synthesis
• `foundation-stakeholder-update`. downstream: translates recap outcomes to non-attendees

foundation-meeting-recap - Version History

1.0.2 (2026-06-14)

Reciprocity patch (C-5): added a "When NOT to Use" body bullet pointing to discover-interview-synthesis, the reciprocal of that skill's existing back-pointer. The 1.0.1 patch added only the description sentence; the C-5 reciprocal-boundary-pointer validator reads the body section, so the body bullet was still missing. Closing it lets the C-5 gate promote advisory -> enforcing. No template or behavior changes.

1.0.1 (2026-06-10)

Description-only patch (F-12 Batch 0, from the 2026-06-09 repo audit): one boundary sentence appended, pointing cross-participant research synthesis to discover-interview-synthesis. No body, template, or behavior changes.

1.0.0 (2026-04-17)

Baseline row for the prior published version; see git history for its changes.

Meeting recap: Search Feature Kickoff

Shareable summary

Search Feature Kickoff | 2026-04-17 Scope and capacity agreed; timeline deferred to a follow-up next week due to emergent vendor-contract question on the search provider.

Key decisions:

• MVP scope: autocomplete + filters IN; saved searches OUT (defer to v2)
• Q2 eng capacity: 8 sprint-weeks committed; alex owns staffing plan

Top actions:

• alex: publish sprint-week staffing plan (Due: 2026-04-24)
• maria: investigate vendor contract constraints on search provider (Due: 2026-04-22)
• jonathan: schedule follow-up for timeline commitment after vendor answer (Due: 2026-04-25)

Full recap below

---

Full recap

Meeting details

• Date: 2026-04-17
• Actual duration: 68 min (overran by 8 min)
• Attendees present: jonathan, maria, alex, sarah
• Attendees absent: none
• Recording: https://meet.example/search-kickoff/recording

Overall summary

Agreed on MVP scope (autocomplete + filters in; saved searches deferred) and Q2 engineering capacity (8 sprint-weeks). Timeline commitment deferred to next week because an emergent question on the search-provider vendor contract needs resolution before a date can be committed. Meeting ran 8 minutes over due to the vendor-contract tangent.

Agenda reconciliation

• Planned topics: scope, capacity, timeline, next-steps
• Topics addressed: scope, capacity (2 of 4)
• Topics skipped: timeline. deferred because vendor contract question blocks commitment; next-steps. absorbed into emergent vendor-contract discussion
• Topics that emerged: vendor-contract-review. alex raised a prior email from the search-provider indicating potential licensing limits on usage; needs investigation before timeline is committable

Topics

Scope

Type: Decision (from agenda)

Discussion

Walked the scope draft together. Autocomplete and filters had clear customer-research backing; saved searches was the contested line. Agreed that saved searches solves a narrower user need and can be deferred without losing the MVP value prop.

Decisions made

• MVP scope: autocomplete IN, filters IN, saved searches OUT (defer to v2). rationale: autocomplete + filters cover 80% of the research-identified user need; saved searches adds complexity (accounts, persistence) that costs Q2 engineering time without proportional customer-value gain

Actions

• [ ] maria: update scope doc to reflect decision; circulate for final sign-off by EOD Friday | Due: 2026-04-18 | Dependencies: none
• [ ] jonathan: add saved-searches to v2 backlog with rationale link | Due: 2026-04-18

Open questions

• None on scope itself; vendor contract issue (see below) may force scope reconsideration if licensing blocks autocomplete

---

Capacity

Type: Decision (from agenda)

Discussion

Alex walked the Q2 capacity model. 8 sprint-weeks available for search; no backfill needed if scope holds. Flagged that saved-searches would have required 3 additional sprint-weeks, reinforcing the scope decision.

Decisions made

• Q2 engineering capacity: 8 sprint-weeks committed to search feature. rationale: fits within scope agreed in prior topic; no backfill required

Actions

• [ ] alex: publish detailed sprint-week staffing plan (who, which sprint) | Due: 2026-04-24
• [ ] alex: flag dependencies on design-system team if any emerge | Due: 2026-04-24

Open questions

• None

---

Vendor-contract-review (emergent)

Type: Discussion (emergent. not on agenda)

Discussion

Alex surfaced a prior email from the search-provider (Algolia) indicating possible licensing limits on query volume at our projected usage. Raised concern that if limits trigger, we could be forced to renegotiate or re-architect. Decision was to investigate before committing to a ship timeline.

Decisions made

• Defer timeline commitment until vendor contract is reviewed [confidence: high]. rationale: committing a date before vendor-licensing risk is known would create rework

Actions

• [ ] maria: investigate vendor contract constraints (read licensing terms; query legal if needed) | Due: 2026-04-22 | Dependencies: legal review if terms are ambiguous
• [ ] jonathan: schedule 30-min follow-up for the week of 2026-04-21 once maria has vendor answer | Due: 2026-04-25

Open questions

• Does vendor licensing support our projected Q2 query volume? [confidence: high. specific question]
• If limits apply, are they negotiable or hard? [confidence: medium. depends on legal review]

---

All actions (consolidated by owner)

maria

• [ ] Update scope doc to reflect decision; circulate for final sign-off | Due: 2026-04-18 | Topic: scope
• [ ] Investigate vendor contract constraints (licensing limits on query volume) | Due: 2026-04-22 | Topic: vendor-contract-review

alex

• [ ] Publish detailed sprint-week staffing plan | Due: 2026-04-24 | Topic: capacity
• [ ] Flag dependencies on design-system team if any emerge | Due: 2026-04-24 | Topic: capacity

jonathan

• [ ] Add saved-searches to v2 backlog with rationale link | Due: 2026-04-18 | Topic: scope
• [ ] Schedule 30-min follow-up for week of 2026-04-21 once vendor answer is in | Due: 2026-04-25 | Topic: vendor-contract-review

Meeting quality signals

• Outcomes achieved: 2 of 3 stated outcomes met (scope, capacity; ship-date deferred pending vendor review)
• Time management: Started on time; ended 8 min over due to emergent vendor-contract discussion
• Key attendee presence: All attendees present; decision-maker (jonathan) engaged throughout

Next steps

• When we reconvene: week of 2026-04-21 (30 min, narrow focus: vendor answer + timeline commitment)
• What needs to happen first: maria completes vendor contract investigation

---

Sources & References

Primary inputs

• Transcript: zoom-recording-2026-04-17 via Otter (68 min, speaker-attributed)
• jonathan's live notes (supplementary, used for context where transcript was ambiguous on speaker attribution)

Referenced artifacts

• Agenda: 2026-04-17_14-00EST_search-feature-kickoff_agenda.md. used for topic skeleton and desired-outcomes reconciliation
• Brief: 2026-04-17_14-00EST_search-feature-kickoff_brief.md (consulted for stakeholder context)
• Prior recaps on this topic: none (this is a kickoff)

External references

• Scope draft
• Capacity model
• Algolia licensing email (internal)

Generation context

• Generated: 2026-04-18T09:15:00Z
• Skill version: 1.0.0
• Input quality: high. transcript plus live notes; all speakers identifiable
• Overall confidence: high. decisions, actions, owners, dates all directly supported in transcript
• Known gaps: None identified
• Inferences applied: topic "vendor-contract-review" emerged during meeting and was not in agenda; labeled as emergent [confidence: high. explicit in transcript]
• Fabrication check: all action owners (maria, alex, jonathan) appear in attendees list; no unassigned actions

Meeting recap: {{Meeting title}}

Shareable summary

[guidance (v1.1.0 errata): 3-5 short lines, no mini-headers, Slack/email copy-safe. Lead with outcome, inline key decisions, inline top actions. Plain prose + simple bullets only. no nested markdown.]

{{Meeting title}} | {{Date}} {{1-sentence accomplishment summary, optionally naming 1-2 key decisions inline.}} Top actions: {{Owner 1}}: {{action}} ({{due}}); {{Owner 2}}: {{action}} ({{due}}); {{Owner 3}}: {{action}} ({{due}}). {{if unassigned_action_ratio > 0.3 or any high-priority action unassigned:}} ⚠ {{N}} of {{M}} actions need owners. see Ownership reconciliation section. Full recap linked below.

---

Full recap

Meeting details

• Date: {{Date}}
• Actual duration: {{Duration}} min
• Attendees present: {{Names}}
• Attendees absent: {{Names or "none"}}
• Recording: {{Link or "none"}}

Overall summary

[guidance: 2-3 sentences capturing what this meeting accomplished in plain language]

{{Summary text}}

Agenda reconciliation

[guidance: explicit report of what was planned vs. what actually happened. If no agenda existed, note "no prior agenda loaded"]

• Planned topics: {{list or "no agenda"}}
• Topics addressed: {{list}} ({{N}} of {{M}})
• Topics skipped: {{list or "none"}}. {{brief reason per skip}}
• Topics that emerged: {{list or "none"}}. {{brief context}}

Topics

{{Topic 1}}

Type: {{Discussion | Decision | Information | Working}} (from agenda, if available)

Discussion

{{Summary of what was discussed}}

Decisions made

• {{Decision 1}}. {{brief rationale}}
• {{Decision 2}}. {{brief rationale}} [confidence: {{level}} if inferred]

Actions

• [ ] {{Owner}}: {{Action}} | Due: {{Date or "not specified"}} | Dependencies: {{any or "none"}}
• [ ] {{Owner or "unassigned"}}: {{Action}} | Due: {{Date or "not specified"}}

Open questions

• {{Unresolved question}} [confidence: {{level}}]

---

{{Topic 2}}

[guidance: repeat structure]

---

All actions (consolidated by owner)

{{Owner 1}}

• [ ] {{Action}} | Due: {{Date}} | Topic: {{Topic}}
• [ ] {{Action}} | Due: {{Date}} | Topic: {{Topic}}

{{Owner 2}}

• [ ] {{Action}} | Due: {{Date}} | Topic: {{Topic}}

Unassigned

• [ ] {{Action}} | Topic: {{Topic}} | Needs owner

Meeting quality signals

[guidance: lightweight signals supporting downstream retrospective use]

• Outcomes achieved: {{N of M or "no agenda outcomes to reconcile"}}
• Time management: {{brief note on start/end and pacing}}
• Key attendee presence: {{brief note on who was needed and whether they were there}}

Next steps

• When we reconvene: {{Date or cadence}}
• What needs to happen first: {{Critical path items}}

---

Sources & References

Primary inputs

• {{Source type}}: {{Source name}} (e.g., "transcript via Otter, 48 minutes")
• {{Source type}}: {{Source name}} (e.g., "user live notes")

Referenced artifacts

• Agenda: {{filename or "none loaded"}}. {{if loaded, note: used for topic skeleton and desired-outcomes reconciliation}}
• Brief: {{filename if applicable}}
• Prior recaps on this topic: {{filenames or "none"}}

External references

• {{Links mentioned in meeting}}

Generation context

• Generated: {{Timestamp}}
• Skill version: 1.0.0
• Input quality: {{high | medium | low}}. {{rationale}}
• Overall confidence: {{high | medium | low}}. {{rationale}}
• Known gaps: {{list of topics with insufficient detail, or "None identified"}}
• Inferences applied: {{list of inferred values with confidence, e.g., "decision on X inferred from 'let's go with X' [confidence: medium]"}}
• Fabrication check: {{"all action owners appear in attendees list or are explicitly unassigned" | or list of failures}}