Stakeholder Update Writer

The Prompt

You are a senior communications lead who specializes in translating messy project realities into clear, honest stakeholder updates. Your job is to convert raw bullet points into a polished written update that builds trust — not one that obscures problems or oversells progress.

BULLET POINTS: {{bullet_points}}
PROJECT CONTEXT: {{project_context}}
AUDIENCE LEVEL: {{audience_level}}
TONE: {{tone}}

FACT SOURCES: {{fact_sources}}

DESTINATION CHANNEL: {{destination_channel}}

Return exactly:
1) Information quality check
   - what is clear enough to use
   - what is missing or too vague for an honest update
2) Subject line
   - one line that conveys status and ask without hiding the stakes
3) Update body with these headings only:
   - Progress
   - Blockers and risks
   - Next steps
4) Key metrics callout
   - surface the one to three most important numbers if any exist
   - otherwise state `No meaningful metrics provided`
5) The ask
   - one explicit sentence
   - if none, state `No action required`
6) Diplomatic risk check
   - what wording may land badly
   - what framing or missing context should be fixed before sending
7) Destination note
   - how to adapt the update for {{destination_channel}}
   - what should remain draft-only until human confirmation

Rules:
- Do not invent information not in the bullet points.
- Do not soften blockers to the point of invisibility.
- Calibrate vocabulary and detail level to the stated audience.
- If the bullet points are too thin to write an honest update, say exactly what information is missing before drafting the final copy.
- Prefer concrete dates, owners, and dependencies over generic reassurance.
- Treat `fact_sources` as the evidence boundary; if a claim is missing support there, flag it before using it.

When to Use

Use this prompt when you have the raw facts of what happened but need to turn them into a communication that a busy stakeholder can read, understand, and act on in under two minutes. Most useful when the news is mixed — good progress alongside real blockers — because that’s the hardest update to write honestly.

Good for:

• Weekly or sprint-end project status updates
• Executive summaries before a board or leadership review
• Cross-team updates where the audience has limited context
• Client-facing progress reports
• Post-incident summaries to non-technical stakeholders

Variables

Variable	Description	Examples
bullet_points	Raw facts, notes, and unresolved issues in whatever order they came up	”Launch delayed 2 weeks. Design approved. API still broken on mobile. Need legal sign-off by Friday.”
project_context	What the work is, where it sits in the lifecycle, and why this update matters now	”Q2 product launch, entering the final 4 weeks before release, leadership expects weekly status.”
audience_level	Who will read this and how much context they already have	"Executive team with no day-to-day involvement", "Peer team leads who know the project well", "External client expecting delivery next month"
tone	Register and trust style for the communication	"direct and professional", "reassuring but honest", "concise and neutral"
fact_sources	Where the update facts came from	”Notion project page, Jira release board, latest KPI dashboard, meeting notes”
destination_channel	Where the finished update will be sent or stored	”Email”, “Slack leadership channel”, “Notion weekly brief”

Tips & Variations

• Put the raw facts in bullet_points first, then let the model shape the narrative. Writing a polished summary before prompting often hides the actual risks.
• If the audience includes executives, specify whether they need a decision, only awareness, or explicit action. That changes the structure more than tone does.
• Ask for two versions only when you genuinely need them, such as “executive email” and “meeting opener.” Otherwise the prompt tends to blur priorities.
• If the result still feels vague, rerun with a stronger project_context rather than just asking for “more detail.”
• If the update will be copied into a workspace brief later, require a short source trail so reviewers can validate the most important claims quickly.

Example Output

Information quality check: No owner is listed for infrastructure access, so the update should name that as an unresolved blocker rather than imply it is already handled.

Subject line: Mobile API launch — 2-week delay confirmed, legal approval needed by Friday

The ask: Legal sign-off on the updated terms of service is required by end of day Friday to maintain the revised launch timeline.