stakeholder-update-writer

Name: stakeholder-update-writer
Author: krzysztofsurdy

18installs1forks

How to install stakeholder-update-writer?

krzysztofsurdy/code-virtuoso/stakeholder-update-writer

$npx -y skills add krzysztofsurdy/code-virtuoso --skill stakeholder-update-writer

Installs into the current project.

Summary

Write a stakeholder Slack/email update message. Use when the user wants to communicate project status, blockers, decisions, or release readiness to stakeholders.

Files · 1

View on GitHub

SKILL.md

1	# Stakeholder Update Message
2
3	Write a concise, professional stakeholder update message for Slack or email.
4
5	## Process
6
7	### 1. Gather context
8
9	Understand what the user wants to communicate. The source can be anything:
10	- An epic or set of tickets from your ticket tracker or project management tool (fetch via your project tracker integration if available)
11	- A conversation summary or decision outcome
12	- A project milestone, blocker, or risk
13	- A release status or go/no-go decision
14	- Anything the user describes or provides
15
16	If the context is about tracked work (epic, sprint, tickets), fetch the relevant data to understand the full picture. If it's about a decision, event, or general update, work from what the user provides.
17
18	### 2. Understand the audience and purpose
19
20	Before drafting, identify:
21	- Who is receiving this (team, management, cross-functional stakeholders, external partners)
22	- What they need to know (status, decision, blocker, request for input, FYI)
23	- What action is expected from them (none, approval, input, awareness)
24
25	If unclear, ask the user briefly before drafting.
26
27	### 3. Draft the message
28
29	Tone: Professional, direct, confident. Not corporate fluff. Written as a real person talking to colleagues.
30
31	Structure: Flowing text with minimal formatting. Use bold for section headers only when they add clarity. Avoid:
32	- Bullet-point walls
33	- Listing every ticket or task individually
34	- Project management jargon (sprint velocity, story points, epics)
35	- Over-explaining what's obvious
36
37	Content flow:
38	1. One-line context - what this is about
39	2. Background - what led to this update (kept brief, only what the reader needs)
40	3. The substance - grouped by theme, not by ticket or task. Summarize what matters in plain language. Keep it to 3-4 groups max.
41	4. Framing - set expectations on effort, timeline, or impact
42	5. Dependencies or asks - who needs to do what
43	6. Next steps - where to find details, when to expect the next update, offer to discuss
44
45	Key principles:
46	- Lead with the conclusion, not the process
47	- Group by business theme, not by task or ticket
48	- Say what needs to happen, not what the task title says
49	- Name people/teams who own dependencies
50	- One link to a tracking board or document is enough - don't link every item
51	- Keep it under 200 words if possible
52
53	### 4. Iterate with the user
54
55	Expect the user to refine. Common feedback patterns:
56	- "Too many details" - consolidate, remove granularity
57	- "More professional" - drop casual language, tighten sentences
58	- "Less bullet points" - convert to flowing paragraphs
59	- "Add context about X" - weave it in naturally, don't bolt on a section
60	- "Shorter" - cut to the essentials, assume more shared context
61
62	When iterating, apply the feedback and present the full updated message. Don't ask clarifying questions unless the feedback is genuinely ambiguous.
63
64	## Example output style
65
66	> Hey - update on [topic].
67	>
68	> We've [done what / looked into what / decided what], and here's where we are.
69	>
70	> Theme A - what's happening, what needs to happen. Who's on it.
71	>
72	> Theme B - what's happening. What we need from [person/team].
73	>
74	> Theme C - what's happening.
75	>
76	> [Effort/timeline framing]. [Key dependency or ask].
77	>
78	> [Where to find details]. [Next checkpoint]. Happy to discuss.
79
80	## Anti-patterns to avoid
81
82	- Starting with "I hope this message finds you well" or similar filler
83	- Restating an entire document or epic description
84	- Including task/ticket IDs inline (a single link is enough)
85	- Writing a wall of bullet points that reads like a board export
86	- Over-qualifying statements ("we believe", "it seems like", "potentially")
87	- Adding a summary section at the end that repeats the message
88	- Using project management jargon the audience doesn't care about
89
90	## Integration with Other Skills
91
92	\| Situation \| Recommended Skill \|
93	\|---\|---\|
94	\| When generating a full project report instead of a message \| `report-writer` \|
95	\| When writing a PR description, not a stakeholder message \| `pr-message-writer` \|
96	\| When planning sprint goals to reference in the update \| `scrum` \|

People who liked this also viewed

6 picks

Type

stakeholder-update-writer

18installs1forks

View on GitHub

How to install stakeholder-update-writer?

krzysztofsurdy/code-virtuoso/stakeholder-update-writer

$npx -y skills add krzysztofsurdy/code-virtuoso --skill stakeholder-update-writer

Installs into the current project.

Summary

Write a stakeholder Slack/email update message. Use when the user wants to communicate project status, blockers, decisions, or release readiness to stakeholders.

Files · 1

View on GitHub

SKILL.md

1	# Stakeholder Update Message
2
3	Write a concise, professional stakeholder update message for Slack or email.
4
5	## Process
6
7	### 1. Gather context
8
9	Understand what the user wants to communicate. The source can be anything:
10	- An epic or set of tickets from your ticket tracker or project management tool (fetch via your project tracker integration if available)
11	- A conversation summary or decision outcome
12	- A project milestone, blocker, or risk
13	- A release status or go/no-go decision
14	- Anything the user describes or provides
15
16	If the context is about tracked work (epic, sprint, tickets), fetch the relevant data to understand the full picture. If it's about a decision, event, or general update, work from what the user provides.
17
18	### 2. Understand the audience and purpose
19
20	Before drafting, identify:
21	- Who is receiving this (team, management, cross-functional stakeholders, external partners)
22	- What they need to know (status, decision, blocker, request for input, FYI)
23	- What action is expected from them (none, approval, input, awareness)
24
25	If unclear, ask the user briefly before drafting.
26
27	### 3. Draft the message
28
29	Tone: Professional, direct, confident. Not corporate fluff. Written as a real person talking to colleagues.
30
31	Structure: Flowing text with minimal formatting. Use bold for section headers only when they add clarity. Avoid:
32	- Bullet-point walls
33	- Listing every ticket or task individually
34	- Project management jargon (sprint velocity, story points, epics)
35	- Over-explaining what's obvious
36
37	Content flow:
38	1. One-line context - what this is about
39	2. Background - what led to this update (kept brief, only what the reader needs)
40	3. The substance - grouped by theme, not by ticket or task. Summarize what matters in plain language. Keep it to 3-4 groups max.
41	4. Framing - set expectations on effort, timeline, or impact
42	5. Dependencies or asks - who needs to do what
43	6. Next steps - where to find details, when to expect the next update, offer to discuss
44
45	Key principles:
46	- Lead with the conclusion, not the process
47	- Group by business theme, not by task or ticket
48	- Say what needs to happen, not what the task title says
49	- Name people/teams who own dependencies
50	- One link to a tracking board or document is enough - don't link every item
51	- Keep it under 200 words if possible
52
53	### 4. Iterate with the user
54
55	Expect the user to refine. Common feedback patterns:
56	- "Too many details" - consolidate, remove granularity
57	- "More professional" - drop casual language, tighten sentences
58	- "Less bullet points" - convert to flowing paragraphs
59	- "Add context about X" - weave it in naturally, don't bolt on a section
60	- "Shorter" - cut to the essentials, assume more shared context
61
62	When iterating, apply the feedback and present the full updated message. Don't ask clarifying questions unless the feedback is genuinely ambiguous.
63
64	## Example output style
65
66	> Hey - update on [topic].
67	>
68	> We've [done what / looked into what / decided what], and here's where we are.
69	>
70	> Theme A - what's happening, what needs to happen. Who's on it.
71	>
72	> Theme B - what's happening. What we need from [person/team].
73	>
74	> Theme C - what's happening.
75	>
76	> [Effort/timeline framing]. [Key dependency or ask].
77	>
78	> [Where to find details]. [Next checkpoint]. Happy to discuss.
79
80	## Anti-patterns to avoid
81
82	- Starting with "I hope this message finds you well" or similar filler
83	- Restating an entire document or epic description
84	- Including task/ticket IDs inline (a single link is enough)
85	- Writing a wall of bullet points that reads like a board export
86	- Over-qualifying statements ("we believe", "it seems like", "potentially")
87	- Adding a summary section at the end that repeats the message
88	- Using project management jargon the audience doesn't care about
89
90	## Integration with Other Skills
91
92	\| Situation \| Recommended Skill \|
93	\|---\|---\|
94	\| When generating a full project report instead of a message \| `report-writer` \|
95	\| When writing a PR description, not a stakeholder message \| `pr-message-writer` \|
96	\| When planning sprint goals to reference in the update \| `scrum` \|

People who liked this also viewed

6 picks

Type