Stakeholder update

Skill broomva/skills/skills/cadence/stakeholder-update

Takes one set of project facts and generates three versions: technical for engineering, business-impact for leadership, and customer-facing for success teams. Use when the user says "stakeholder update", "write an update", "communicate this to different audiences", "translate for leadership", "customer-facing version", or needs to communicate the same information to different audiences.From its SKILL.md

Install

npx -y skills add broomva/skills --skill stakeholder-update

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.8 KB, 571 tokens by cl100k_base, as published. Nobody here has run it

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

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most operations skills give in 571 tokens

Counted across 483 of the 484 authors here whose files we hold, read 2026-08-07

Collect monitoring data throughout the simulationin 14 of 483, across 6 files
Set the random seed for reproducibilityin 14 of 483, across 6 files
Validate simulations against analytical solutionsin 12 of 483, across 4 files
Clarify goals, constraints, and inputsin 11 of 483, across 2 files
Implement contract tests for integration pointsin 11 of 483, across 2 files
Implement strangler fig infrastructure with API gatewayin 11 of 483, across 2 files
Audit modernized components for security vulnerabilitiesin 11 of 483, across 2 files
Avoid Python blocking calls in processesin 10 of 483, across 3 files
Use resource context managers for automatic cleanupin 9 of 483, across 2 files
Maintain consistent time unitsin 9 of 483, across 2 files
Validate outcomes against success criteriain 8 of 483, across 1 file
Analyze the legacy codebase for technical debtin 8 of 483, across 1 file

Said here and by no other author read

accept raw project facts from the user
identify what changed, impact, action items, and risks
generate a technical version for engineering
generate a business-impact version for leadership
generate a customer-facing version for success teams
make each version stand alone

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.