Help us improve
Share bugs, ideas, or general feedback.
From rampstack-skills
Communicates technical updates effectively to stakeholders across functions and seniority levels. Use for status reports, executive reviews, managing up, or communicating bad news.
npx claudepluginhub rampstackco/claude-skills --plugin rampstack-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/rampstack-skills:stakeholder-communicationThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Get the right information to the right people at the right time, in a form they can act on. Stack-agnostic. Applies to any team operating with cross-functional stakeholders.
Generates stakeholder updates tailored to audience (executives, engineering, customers) and cadence (weekly/monthly status, launch announcements, risk escalations). Pulls from connected tools.
Generates structured stakeholder updates with TL;DR headlines, progress trends, risks, and clear asks for status reports and executive summaries.
Creates executive stakeholder updates using BLUF framework with status, progress summary, metrics dashboard, risks, blockers, and milestones. Use for status updates, progress reports, or executive summaries to leadership.
Share bugs, ideas, or general feedback.
Get the right information to the right people at the right time, in a form they can act on. Stack-agnostic. Applies to any team operating with cross-functional stakeholders.
incident-response)documentation-strategy)Before any stakeholder communication, answer:
Specifically. "Leadership" is too vague. The CFO and the VP of Engineering have different concerns.
For each named audience:
If they read only one sentence, what should they take away?
The headline goes first. Always. The narrative supports it; the data confirms it.
This is the biggest gap in most stakeholder communication: people start with context and build to a conclusion. Stakeholders want the conclusion first.
Stakeholders ask "and?" implicitly. Answer it explicitly.
The so-what makes the information actionable.
Communications generally have one of these requests:
State which. Don't bury the request.
For most updates: async written. Save sync time for actual discussion.
Stakeholder communication reads like a news article, not an essay.
Headline (one sentence)
The "so what" and the request (one paragraph)
Status / progress (the body)
Risks and asks (what we need)
Detail / appendix (what curious readers want)
Cut from the bottom. If your update gets shortened, the top survives.
**Project:** [Name]
**Status:** [On track / At risk / Off track]
**Headline:** [One-sentence summary]
**This week:**
- [Specific accomplishment]
- [Specific accomplishment]
- [Specific accomplishment]
**Next week:**
- [Specific plan]
- [Specific plan]
**Risks / blockers:**
- [Risk + what we're doing about it / what we need]
**Metrics:**
- [Metric: value vs target]
- [Metric: value vs target]
The status indicator (on track / at risk / off track) is essential. Stakeholders scan for it.
**Headline:** [The summary, one sentence]
**Key points:**
1. [Point with one supporting sentence]
2. [Point with one supporting sentence]
3. [Point with one supporting sentence]
**Decisions needed:**
- [Decision A: options and recommendation]
- [Decision B: options and recommendation]
**Asks:**
- [Specific request]
**Detail:** [Linked doc or appendix]
Executives skim. They click into detail when interested.
The hardest update to write well.
**Headline:** [The bad news, plainly stated]
**What happened:**
[Specific facts, no euphemisms]
**Impact:**
[Who's affected, how much, by when]
**What we're doing:**
[Specific actions and owners]
**What we need:**
[Specific asks, if any]
**Timeline:**
[When the next update will land]
Don't soften the headline. Soft headlines on bad news erode trust faster than the news itself.
**Decision:** [What needs to be decided]
**Context:** [The minimum needed to understand]
**Options:**
1. [Option A: description, pros, cons]
2. [Option B: description, pros, cons]
3. [Option C: description, pros, cons]
**Recommendation:** [Option X, because...]
**Need by:** [Date]
**Decision rights:** [Who decides]
Recommendation matters. Not making one is putting the work back on the decider.
| Audience | Tone | Detail | Length |
|---|---|---|---|
| Direct manager | Candid, briefer | Mid | Medium |
| Skip-level / VP | Polished, sharper | Low | Short |
| Cross-functional peer | Collaborative, specific | Mid-high | Medium |
| Executive / board | Headlines, confident | Low (with detail available) | Short |
| Team / IC stakeholders | Detailed, direct | High | Long |
Before writing, answer Q1-Q5 above. Often this clarifies the message before any drafting.
One sentence. The takeaway. If you can't write the headline, you don't know yet what you're communicating.
Headline, so-what, body, asks, detail.
A first draft is usually 30-50% too long.
Reread. Is the ask clear? Is it specific? Is the deadline named?
Imagine the recipient reading. Will they understand the headline? Have you skipped context they need? Have you given context they don't need?
After sending:
Different audiences need different cadences.
The right cadence is what's needed, not what fills the calendar. Update people when there's something new; don't manufacture updates.
Long preamble before the point. Three paragraphs of context, then the one sentence that mattered. Lead with the point.
Status: yellow. Same status three weeks in a row. Yellow with no change is red. Be honest about progress.
Update without a clear ask. "We're working on it." OK, what do you want? If nothing, say "no action needed."
Sandwiching bad news in good news. "We've done X and Y, and unfortunately Z is delayed, but we've also done W." The bad news gets lost. Lead with it if it's the headline.
Walls of text. Too long, unread. Cut to the structure.
Activity vs outcome. "Met with team. Reviewed plan. Updated tickets." So what? "Cut scope to hit launch date" is an outcome.
Different update for every audience. Maintaining 5 versions doubles work. Have one core update; tailor the framing.
Status update that's actually a request. Buries an ask in a wall of status. Pull the ask out. Make it visible.
Optimistic projections. "We'll be back on track next week." Then we're not. Then again. Trust erodes. Be honest about the path.
No follow-up on asks. Asked for a decision; didn't get one; moved on. Now the project is stuck. Follow up.
Communicating bad news only when forced to. Stakeholders find out from someone else, or from a missed deadline. Lose trust. Communicate proactively.
Performative comms for the audience of one. Every update reads like a sales pitch to the boss. Stakeholders see through it. Be direct.
No comms when no news. Silence is worse than "no change this week." Set expectations on cadence and stick to it.
A communication plan for a project includes:
For individual communications:
references/update-templates.md: Ready-to-use templates for the most common stakeholder communications, with annotated examples.