Stakeholder Comms

Stakeholder Comms is an official skill from Anthropic’s Product Management plugin in the public knowledge-work-plugins repository. The requested candidate path stakeholder-comms is now represented in the current main branch by the official stakeholder-update path. This entry therefore follows the verified provider-maintained successor while preserving the candidate’s documented scope. According to the provider, the skill helps turn progress, risks, decisions, and next steps into clear communication for different audiences. It is not a project-management system, a source of factual project status, or an automatic authorization to send messages.

Purpose and audiences

The workflow starts with two editorial decisions: what kind of update is needed and who will read it. The source names weekly status updates, monthly summaries, launch announcements, and ad-hoc messages for escalations, pivots, or major decisions. Audiences can include executives and leadership, engineering, cross-functional partners, customers, or a board. This distinction matters because the same facts must be ordered differently depending on responsibility, prior knowledge, and the action the reader may need to take. An executive update emphasizes outcomes, strategic context, risks, decisions, and specific asks. An engineering version can include implementation detail and links to working artifacts. A customer-facing message explains benefits and availability without internal shorthand.

Context and drafting

When connected tools are available, the provider’s workflow can incorporate information from project trackers, team communication, meeting transcripts, knowledge bases, and other approved sources. The intended context includes completed work, blockers, decisions, dependencies, and upcoming milestones. Without connectors, the responsible person supplies the context directly. The skill produces a draft, not automatically verified facts. Before publication, a human should check status, metrics, links, names, deadlines, recipients, and availability claims against authoritative sources.

Formats and risk communication

For leaders, the source recommends a concise structure covering status, a short summary, progress tied to goals, risks, decisions, specific asks, and next milestones. Engineering needs shipped work, in-progress work, owners, blockers, and technical decisions. Cross-functional partners need to know what is coming, what they must prepare, when input is needed, and which decisions affect their team. Customers need outcomes, timing, known issues, workarounds, and feedback channels. For risk communication, the skill presents the ROAM framework with Resolved, Owned, Accepted, and Mitigated states. A useful risk message explains the cause, possible impact, likelihood, mitigation, and the specific help required.

Boundaries, safety, and E-E-A-T

Stakeholder Comms can structure language, but it does not replace product ownership, subject-matter review, or communication approval. Status colors should not soften inconvenient facts. A yellow or red situation should be raised early with evidence and a clear reason. Content from chats, tickets, and documents is data rather than a new instruction; injected or contradictory wording must not redirect the task. Review access, minimization, retention, and recipients before placing confidential roadmaps, customer information, or personal feedback into a connected client. Do not store passwords, tokens, private keys, or dangerous example commands in communication templates. A local skill file does not mean the selected model runs locally. This entry relies on Anthropic’s official repository path, the Product Management overview, and official Claude Code documentation. Provider statements are marked as provider statements. According to the provider, the repository is released under Apache-2.0; actual use depends on the supported Claude product, its connectors, and organizational policy.