broomva Stakeholder Update
One set of facts → three audience-specific versions.
Workflow
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
Extract the core — Identify:
- What changed (the facts)
- Why it matters (the impact)
- What's next (the action items)
- Any risks or blockers
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