# Stakeholder Update Writer

> 当需按受众与节奏撰写干系人更新（高管周报/月报、发布公告、风险升级，或把同一进展改写成高管简报/工程明细/对客版本）时使用；产出含状态灯（绿/黄/红）、TL;DR、进展、风险与诉求的分受众结构化更新草稿；不适用于对外客服回复、营销文案或纯财务建模；触发词：干系人更新、状态汇报、周报、月报、发布公告、风险升级、stakeholder update

- Skill: `findscripter/stakeholder-update-writer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add findscripter/stakeholder-update-writer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/findscripter/stakeholder-update-writer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- License: Apache-2.0
- Author: findscripter (https://skillmd.com/u/findscripter)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/findscripter/stakeholder-update-writer

---

## 何时使用

当需要把一段工作进展，按**受众**和**节奏**整理成一条得体的干系人更新时使用。典型场景：

- 周期性汇报：给领导/团队的周报、月报。
- 发布公告：功能或产品上线，说明范围、影响与反馈渠道。
- 风险升级：把某个风险或阻塞点向上抛出，明确诉求。
- 一次性更新：转向、重大决策、需要拍板的事项。
- 同一进展改写多版：高管简报版 / 工程明细版 / 跨职能版 / 对客版。

不该用（负边界）：

- 对客户**对外**回复（用客户回复类技能）。
- 纯营销/落地页/获客文案（用营销文案类技能）。
- 纯财务模型搭建或三表预测（那是数据准备，本技能聚焦「如何讲清楚」）。
- 本技能只产出**草稿**，数字与承诺发送前仍需人工核验。

## 步骤

1. **定更新类型**：周报（进展/阻塞/下一步）/ 月报（趋势/里程碑/战略对齐）/ 发布公告 / 一次性（升级/转向/决策）。
2. **定受众**：高管（结果导向、战略框定、极简）/ 工程团队（技术细节、阻塞、待定决策）/ 跨职能伙伴（共同目标、依赖）/ 客户外部（收益导向、清晰时间线、零黑话）/ 董事会（指标驱动、聚焦风险、极简）。
3. **拉取背景**：从可用来源补齐——项目跟踪（路线图/里程碑状态、自上次更新已完成项、在险/受阻项、迭代进度）、团队聊天（讨论与异步决策、暴露的阻塞）、会议记录/转录（决策与行动项）、知识库（决策文档、设计评审）。无可用工具时，向用户索取四要素：**自上次更新完成了什么 / 当前阻塞与风险 / 已做或待定的决策 / 接下来做什么**。
4. **按受众生成**：套用下方对应模板与状态/风险框架。
5. **复核交付**：主动问是否调语气、详略或侧重；按渠道排版（邮件/聊天贴/文档/幻灯片）；需要时直接代写可发送的消息。

## 指令

**核心原则**：

- **别埋导语**——开头就讲最重要的那件事；有坏消息**先讲**，别藏在好消息后面。
- **状态灯反映真实判断**，不是对方爱听的话。黄不是失败，是良好的风险管理。
- **诉求必须具体可执行**——「需要支持」不是诉求，「周五前对 X 拍板」才是。
- 对高管一律用**结果与目标**框定，不堆活动与任务（「我们上线 X 并拉动了 Y 指标」，而非「开了 14 次站会、关了 23 个工单」）。
- 长度匹配受众注意力：高管几条要点；工程给到所需细节。

**状态灯（绿/黄/红）判据**：

- **绿（On Track）**：按计划推进、无重大风险、能如期兑现承诺。真的顺利才用绿，别当默认值。
- **黄（At Risk）**：进度慢于计划或风险已出现，缓解进行中但结果不确定；不干预可能误期。**越早标黄，可选项越多。**
- **红（Off Track）**：显著落后、有重大阻塞且无清晰缓解，不重大干预（砍范围/加资源/延期）必误期。真正需要求助时才用红，别等到来不及。

**改灯规则**：见到风险**首个**苗头即转黄（而非确定变坏时）；自己手段用尽、需要升级时转红；风险**真正解除**才转回绿（仅暂停不算）；每次改灯都注明「因 X 转黄」。

**ROAM 风险框架**：Resolved（已解除，记录如何解的）/ Owned（有人正在管，写明 owner 与缓解计划）/ Accepted（已知但选择不缓解，记录理由）/ Mitigated（已降到可接受，记录所做动作）。

**讲清一个风险的五步**：①清晰陈述「存在 X 风险，因为 Y」→ ②量化影响「若发生，后果是 Z」→ ③说明概率「这件事可能/也许/不太可能，依据是…」→ ④给出缓解「我们正用 … 应对」→ ⑤提出诉求「需要你给 … 来进一步降低风险」。常见错误：把风险埋进好消息、含糊（不说清是什么/多久/为何）、只报风险不给缓解、拖太久（早报是规划输入，晚报是救火）。

**输出规范**：保持可扫读，关键点加粗、列表用要点。高管更新控制在 **200–300 字以内**；工程更新可长，但仍要分块便于略读。

## 示例

**高管 / 领导版**（结果导向，<200 字）：

```
状态: [绿 / 黄 / 红]

TL;DR: [一句话——最该知道的事]

进展:
- [已达成结果，挂到目标/OKR]
- [里程碑及其影响]
- [关键指标变动]

风险:
- [风险]: [缓解计划]。[如需，附诉求]。

待定决策:
- [决策]: [选项 + 推荐]。需在 [日期] 前。

下一里程碑:
- [里程碑] —— [日期]
```

**工程团队版**（多给链接，便于点进细节）：

```
已交付:
- [功能/修复] — [PR/工单链接]。[如有，影响]。

进行中:
- [事项] — [Owner]。[预计完成]。[如有，阻塞]。

决策:
- [已定]: [理由]。[ADR 链接（如有）]。
- [待定]: [背景]。[选项]。[推荐]。

优先级变化:
- [变了什么、为什么]

接下来:
- [下批事项] — [为何是这些]
```

**对客 / 外部版**（按收益讲，零内部黑话，无工单号）：

```
新功能:
- [功能] — [对客户意味的收益]。[如何使用/链接]。

即将推出:
- [功能] — [预计时间]。[为何与你相关]。

已知问题:
- [问题] — [状态]。[绕行方案（如有）]。

反馈:
- [如何反馈或提需求]
```

源命令：`/stakeholder-update <更新类型与受众>`。调用示例：「给领导写一份本周状态更新」「升级这个阻塞风险」「把这版进展改写成对客版本」。

## 注意事项

- 草稿仅供发送前参考：所有数字、时间线、承诺均须人工核验，不得超出授权。
- 严防外泄不可对外的路线图、内部口径或敏感信息（尤其对客版）。
- 对客版只在「影响客户且已有解决计划」时才提已知问题；时间线宁可写「本季度晚些」也别承诺一个可能错过的日期。
- 高管版只列「需要他们帮忙」的风险；已在自己掌控中的风险，除非必须知会，否则不必列。
- 状态灯宁可提前标黄，也别用绿色粉饰；这是风险沟通，不是乐观表态。

## 互见

- related：`board-meeting-prep` —— 高风险对抗式董事会/投资人审查的备会演练，本技能聚焦常规分受众进展更新
- related：`adr-writer` —— 更新中「已定决策」可链接到正式 ADR 留痕
- related：`meeting-transcript-analyzer` —— 从会议转录提取决策与行动项，作为更新的输入
- combines_with：`board-deck-builder` —— 把更新内容沉淀为面向董事会/高管的演示材料

---

采编自 anthropics/knowledge-work-plugins（Apache-2.0）。