broomva/skills/stakeholder-update

Stakeholder Update

One set of facts → three audience-specific versions.

Workflow

1. Gather the facts — Accept raw project facts from the user. These can be:

• A list of bullet points
• A technical doc or PR description
• A conversation summary
• A vault note path

1. Extract the core — Identify:

• What changed (the facts)
• Why it matters (the impact)
• What's next (the action items)
• Any risks or blockers

1. Generate three versions:

Version 1: Technical (Engineering)

• Lead with what changed technically
• Include relevant code/architecture details
• Reference PRs, commits, or technical docs
• Use precise technical language
• Focus on: implementation details, technical debt, performance metrics

Version 2: Business Impact (Leadership)

• Lead with business outcome
• Translate technical changes to business metrics
• Include timeline and resource implications
• Use clear, jargon-free language
• Focus on: revenue impact, risk reduction, strategic alignment, timeline

Version 3: Customer-Facing (Success Teams)

• Lead with user benefit
• Explain changes in terms of user experience
• Include any action items for customers
• Use friendly, accessible language
• Focus on: what's better for users, when they'll see it, what they need to do

Output Format

## Stakeholder Update: [Topic]
 
**Date**: [YYYY-MM-DD]
**Author**: [name]
 
---
 
### Technical Version (Engineering)
 
**TL;DR**: [one sentence]
 
[2-4 paragraphs with technical detail]
 
**Action items**:
-[ ] [engineering action]
 
---
 
### Business Version (Leadership)
 
**TL;DR**: [one sentence focused on business outcome]
 
[2-3 paragraphs, no jargon]
 
**Key metrics**:
-[metric]: [before] → [after]
 
**Action items**:
-[ ] [leadership action]
 
---
 
### Customer-Facing Version (Success Teams)
 
**TL;DR**: [one sentence focused on user benefit]
 
[2-3 paragraphs, friendly tone]
 
**Customer action required**: [yes/no + details]
 
**Talking points for support**:
1.[key point to communicate]
2.[key point to communicate]

Behavior

• Never invent facts — only reframe what's provided
• If the input is too sparse for three versions, ask for more context
• Each version should stand alone — a reader shouldn't need the other versions
• Match the formality level to the audience
• Save to vault if requested: vault/updates/stakeholder-[topic]-[YYYY-MM-DD].md