foundation-meeting-recap
This Claude Code skill produces a post-meeting summary organized by topic rather than chronological order, automatically highlighting decisions and capturing action items with owners and due dates inline under relevant topics, plus a consolidated action list at the end. Use it after internal meetings that produce decisions or actions, especially when a related meeting agenda exists for reconciliation, or when you have transcripts from Zoom, Meet, Otter, Fireflies, Krisp, or manual notes that need structured synthesis for attendees.
git clone --depth 1 https://github.com/product-on-purpose/pm-skills /tmp/foundation-meeting-recap && cp -r /tmp/foundation-meeting-recap/skills/foundation-meeting-recap ~/.claude/skills/foundation-meeting-recapSKILL.md
<!-- 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](../../docs/reference/skill-families/meeting-skills-contract.md).
## 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
- Setting the pre-meeting structure attendees will see (topics, owners, time boxes) before the meeting happens. Use `foundation-meeting-agenda`. recap summarizes what happened after a meeting; agenda sets expectations before it.
- Preparing the user's private strategic positioning before a meeting that matters. Use `foundation-meeting-brief`. recap is a shared post-meeting record; brief is pre-meeting tactical prep never shown to attendees.
- 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`:Run an ad-hoc ordered chain of pm-skills with shared context (ephemeral; routes to the pm-workflow-orchestrator)
Defines a testable hypothesis with clear success metrics and a validation approach. Use when forming assumptions to test or aligning a team on what success looks like, before any experiment is designed. To design the A/B test or experiment that will validate the hypothesis, use measure-experiment-design.
Creates a Jobs to be Done canvas capturing the functional, emotional, and social dimensions of a customer job. Use when deeply understanding customer motivations, designing for jobs, or reframing product positioning.
Creates an opportunity solution tree connecting a desired outcome to customer opportunities and candidate solutions, preventing solution-first jumps in continuous discovery. Use when structuring scattered feature ideas or communicating how the roadmap traces to outcomes. For ranking an existing flat list of candidates, use define-prioritization-framework instead; this skill discovers the list, it does not score one.
Run applicable prioritization frameworks (RICE, ICE, MoSCoW, Weighted Scoring, Kano) against a list of features or initiatives. Produces a comparison table showing where rankings agree and diverge across frameworks, and an executive summary with recommendation. Framework applicability is filtered by data availability; Kano requires customer research. Refuses to fabricate scores; produces an estimation scaffold when input data is missing.
Creates a clear problem framing document with user impact, business context, and success criteria. Use when starting a new initiative, realigning a drifted project, or communicating up to leadership.
Generates structured Given/When/Then acceptance criteria for a user story or feature slice, covering the happy path, key failure scenarios, and non-functional expectations in testable form. Use when turning requirements into verifiable scenarios for engineering handoff and QA sign-off. For a dedicated catalog of boundary conditions, error states, and recovery paths across a feature, use deliver-edge-cases; to write the stories themselves, use deliver-user-stories.
Documents edge cases, error states, boundary conditions, race conditions, and recovery paths for a feature - the systematic catalog of what can go wrong and the failure modes to design for. Use during specification to map the failure surface and ensure comprehensive coverage, or during QA planning to identify boundary and limit scenarios to test. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the whole-feature edge-case catalog.