foundation-stakeholder-update

$npx mdskill add product-on-purpose/pm-skills/foundation-stakeholder-update

Translates meeting outcomes into tailored async stakeholder updates.

  • Solves communicating meeting outcomes to non-attendees and attendees needing reference.
  • Depends on meeting notes, audience metadata, and prior update history.
  • Selects channel and audience variant, then translates technical details to business language.
  • Delivers formatted message with primary CTA and flags translations for user verification.

SKILL.md

.github/skills/foundation-stakeholder-updateView on GitHub ↗
---
name: foundation-stakeholder-update
description: Produces async communication to stakeholders, primarily non-attendees and secondarily some attendees who want a reference. Translates meeting outcomes into what-it-means language for readers, with channel variants (slack, teams, email, notion, exec-memo) and audience variants (engineering, design, leadership, customer-facing, mixed). Surfaces a primary CTA up front, flags technical-to-business translations for user verification, and detects thread continuation from prior updates.
license: Apache-2.0
metadata:
  classification: foundation
  version: "1.1.0"
  updated: 2026-07-05
  category: meeting
  frameworks: [meeting-skills-family]
  author: product-on-purpose
---
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
# Stakeholder Update

A stakeholder update is async communication to readers who need to know the outcomes of a meeting. Primary audience is non-attendees; secondary audience is some attendees who want a reference version (came in late, stepped out, need something to forward).

Distinct from `foundation-meeting-recap` in audience, format, and purpose: the recap is a summary of what happened for people who were in the room; the stakeholder-update is a translation of outcomes into what-it-means for readers (tailored to their role, with technical-to-business translation where the audience warrants it).

Distinct from `/discover-stakeholder-summary`: that skill is about understanding stakeholders (input to the user's work). This skill is about communicating to stakeholders (output from the user's work).

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 a meeting with outcomes affecting teams who were not in the room
- When a decision or commitment needs to propagate to downstream teams async
- When a recap exists and needs to be translated into audience-specific language
- When the user needs something from readers (specific CTA) and cannot afford for it to be buried

## When NOT to Use

- Summarizing what happened for attendees. Use `foundation-meeting-recap`.
- Broadcasting status with no specific audience tailoring. A plain Slack message is sufficient; the skill adds value when translation or CTA framing matters.
- Communicating research findings to stakeholders. Use `/discover-interview-synthesis` plus targeted comms.
- The source is not one meeting's outcomes but a broader artifact (a spec, discovery synthesis, research report, GTM plan, or experiment results) that needs to fan out to several audience-tailored briefings from one canonical master. Use `foundation-stakeholder-briefings`.

## Zero-friction execution

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

1. Load related recap (preferred) or raw meeting notes
2. Detect thread continuation by scanning same directory for prior stakeholder-updates on the same `project`/`topics`
3. Infer channel (if not specified) from audience variant: engineering / design → slack; leadership → email; mixed → notion
4. Present a brief inference summary (detected channel, audience, CTA, thread continuation if any, translation candidates)
5. Accept `go` or corrections
6. Produce the channel-tailored update

If invoked with `--go`, skip the inference summary. The entire output is shareable content (per family contract. no separate summary block needed).

## Instructions

When asked to create a stakeholder update, follow these steps:

1. **Load related recap**
   Parse frontmatter to extract meeting context, decisions, actions, outcomes. If no recap provided, accept raw meeting notes with a lower input-quality flag.

2. **Detect thread continuation**
   Scan same directory for prior `stakeholder-update` artifacts with matching `project` / `topics`. If found, reference the prior update in the frontmatter `thread_continuation_of` field.

3. **Present go-mode inference summary**
   Show inferred channel (if not specified), detected audience, proposed CTA, thread continuation status, translation candidates (flagged jargon or acronyms that may not land).

4. **Distill key outcomes**
   From the recap or notes, select 3-5 outcomes that matter to the target audience. Do not include everything from the recap. filter by audience relevance.

5. **Frame the CTA**
   If action is needed: lead with it, not bury it
   If FYI-only: state explicitly in the TL;DR

6. **Translate technical-to-business**
   Flag jargon and acronyms unlikely to land with the audience. Provide plainer alternatives. Keep a translations-applied log for user verification in the output's Generation context.

7. **Build the channel-tailored variant**

   - **Slack / Teams**: headline (one action-oriented line, optionally one emoji), TL;DR 3 bullets, context sentence, "what this means for [audience]", CTA (bold with marker if action needed; italic "FYI-only" if not), thread-continuation link, more-links footer
   - **Email**: subject line (topic + outcome), greeting ("Hi [audience]"), opening sentence (headline + why they are receiving this), TL;DR, context 2-3 sentences, what was decided / advanced, what this means for your team, what I need from you (with by-when), thread reference, sign-off
   - **Notion**: rich H1/H2/H3 structure, longer context block, collapsible sections for detail, table for decisions and actions
   - **Exec-memo**: TL;DR first (3-4 lines), supporting detail in 3 sections max, asks section upfront, formal tone, no emoji

8. **Render TEMPLATE.md with the selected variant as primary**
   Other variants may be included as collapsible alternates for user flexibility. Remove all guidance blockquotes from the final artifact.

9. **Validate**
   - `channel` is in enum
   - `audience_variant` is in enum
   - `primary_cta` is non-empty (use "FYI-only" if no action needed)
   - `related_recap` is a valid filename reference or flagged as raw-notes input

## Quality Checklist

- [ ] Channel variant matches the specified or inferred channel
- [ ] Audience variant's "what this means for you" is specifically tailored (not generic)
- [ ] CTA is surfaced up front, not buried
- [ ] Technical-to-business translations are logged in Generation context for user verification (INTERNAL. outside shareable boundary)
- [ ] Thread continuation referenced if prior updates exist on the same topic
- [ ] `## Shareable update` section present with channel-tailored body (v1.1.0. replaces "entire output is shareable" from v1.0.0)
- [ ] Explicit boundary marker between Shareable update and internal sections (translations, sources)
- [ ] Sources and References section lists the source recap and any prior updates in thread (INTERNAL)
- [ ] Filename uses v1.1.0 variant pattern: `YYYY-MM-DD_HH-MMtimezone_title_stakeholder-update-{channel}-{audience}.md`

## See also

- [Meeting Skills Family Contract](../../docs/reference/skill-families/meeting-skills-contract.md)
- [`foundation-meeting-recap`](../foundation-meeting-recap/SKILL.md). upstream: primary input source
- [`/discover-stakeholder-summary`](../discover-stakeholder-summary/SKILL.md). distinct purpose (understanding stakeholders, not communicating to them)

More from product-on-purpose/pm-skills

SkillDescription
define-hypothesisDefines 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.
define-jtbd-canvasCreates 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.
define-opportunity-treeCreates 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.
define-prioritization-frameworkRun 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.
define-problem-statementCreates 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.
define-xFixture skill for phase-map and phase-router tests.
deliver-acceptance-criteriaGenerates 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.
deliver-edge-casesDocuments 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.
deliver-launch-checklistCreates a cross-functional pre-launch checklist covering engineering, design, marketing, support, legal, and operations readiness, with owners, dates, and go/no-go criteria so nothing is missed before release. Use for significant or cross-team launches, not a small single-team change. For the customer-facing announcement of what shipped, use deliver-release-notes instead.
deliver-prdCreates a comprehensive Product Requirements Document that aligns stakeholders on what to build, why, and how success will be measured. Use when specifying features, epics, or product initiatives for engineering handoff.