Stakeholder Update

# Stakeholder Update

> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).

Generate a stakeholder update tailored to the audience and cadence.

## Usage

``` /stakeholder-update $ARGUMENTS ```

## Workflow

### 1. Determine Update Type

Ask the user what kind of update: - **Weekly**: Regular cadence update on progress, blockers, and next steps - **Monthly**: Higher-level summary with trends, milestones, and strategic alignment - **Launch**: Announcement of a feature or product launch with details and impact - **Ad-hoc**: One-off update for a specific situation (escalation, pivot, major decision)

### 2. Determine Audience

Ask who the update is for: - **Executives / leadership**: High-level, outcome-focused, strategic framing, brief - **Engineering team**: Technical detail, implementation context, blockers, decisions needed - **Cross-functional partners**: Context-appropriate detail, focus on shared goals and dependencies - **Customers / external**: Benefits-focused, clear timelines, no internal jargon - **Board**: Metrics-driven, strategic, risk-focused, very concise

### 3. Pull Context from Connected Tools

If **~~project tracker** is connected: - Pull status of roadmap items and milestones - Identify completed items since last update - Surface items that are at risk or blocked - Pull sprint or iteration progress

If **~~chat** is connected: - Search for relevant team discussions and decisions - Find blockers or issues raised in channels - Identify key decisions made asynchronously

If **~~meeting transcription** is connected: - Pull recent meeting notes and discussion summaries - Find decisions and action items from relevant meetings

If **~~knowledge base** is connected: - Search for recent meeting notes - Find decision documents or design reviews

If no tools are connected, ask the user to provide: - What was accomplished since the last update - Current blockers or risks - Key decisions made or needed - What is coming next

### 4. Generate the Update

Structure the update for the target audience using the templates and frameworks below.

**For executives**: TL;DR, status color (G/Y/R), key progress tied to goals, decisions made, risks with mitigation, specific asks, and next milestones. Keep it under 300 words.

**For engineering**: What shipped (with links), what is in progress (with owners), blockers, decisions needed (with options and recommendation), and what is coming next.

**For cross-functional partners**: What is coming that affects them, what you need from them (with deadlines), decisions that impact their team, and areas open for input.

**For customers**: What is new (framed as benefits), what is coming soon, known issues with workarounds, and how to provide feedback. No internal jargon.

**For launch announcements**: What launched, why it matters, key details (scope, availability, limitations), success metrics, rollout plan, and feedback channels.

### 5. Review and Deliver

After generating the update: - Ask if the user wants to adjust tone, detail level, or emphasis - Offer to format for the delivery channel (email, chat post, doc, slides) - If **~~chat** is connected, offer to draft the message for sending

## Update Templates by Audience

### Executive / Leadership Update Executives want: strategic context, progress against goals, risks that need their help, decisions that need their input.

**Format**: ``` Status: [Green / Yellow / Red]

TL;DR: [One sentence — the most important thing to know]

Progress: - [Outcome achieved, tied to goal/OKR] - [Milestone reached, with impact] - [Key metric movement]

Risks: - [Risk]: [Mitigation plan]. [Ask if needed].

Decisions needed: - [Decision]: [Options with recommendation]. Need by [date].

Next milestones: - [Milestone] — [Date] ```

**Tips for executive updates**: - Lead with the conclusion, not the journey. Executives want "we shipped X and it moved Y metric" not "we had 14 standups and resolved 23 tickets." - Keep it under 200 words. If they want more, they will ask. - Status color should reflect YOUR genuine assessment, not what you think they want to hear. Yellow is not a failure — it is good risk management. - Only include risks you want help with. Do not list risks you are already handling unless they need to know. - Asks must be specific: "Decision on X by Friday" not "support needed."

### Engineering Team Update Engineers want: clear priorities, technical context, blockers resolved, decisions that affect their work.

**Format**: ``` Shipped: - [Feature/fix] — [Link to PR/ticket]. [Impact if notable].

In progress: - [Item] — [Owner]. [Expected completion]. [Blockers if any].

Decisions: - [Decision made]: [Rationale]. [Link to ADR if exists]. - [Decision needed]: [Context]. [Options]. [Recommendation].

Priority changes: - [What changed and why]

Coming up: - [Next items] — [Context on why these are next] ```

**Tips for engineering updates**: - Link to specif