stakeholder-update

利益相关方进展更新技能

此技能遵循 BLUF（结论先行）原则，为高管和利益相关方撰写有效的状态更新。

必需输入

根据已提供的信息开展工作。如果缺少以下任一项，仍需生成完整内容：用合理假设补足每处缺漏，并标注 (假设，请确认)，同时在末尾列出这些假设。只有在核心主题本身缺失（没有任何内容可写）时，才先提问。

• 正在汇报的项目或产品
• 受众（CEO、董事会、跨职能负责人、投资者——受众不同，内容深度和格式也不同）
• 周期（本周／本冲刺／本月）
• 当前状态（按计划进行／有风险／受阻）
• 关键指标及其当前值与目标值

从 Brain 读取／写入 Brain

如果存在 professional-brain（brain/），提问前先使用：

• **先读取：**相关的 stakeholders/ 文件（每位相关人员关注的事项及其之前的要求）、context.md（表达风格／语气），以及近期的 decisions/，了解上次更新以来发生的变化。
• **之后写入：**将新提出的要求、顾虑或承诺追加到相关的 stakeholders/ 文件，并标注来源（会议中提及但尚未记录的内容标记为 [verbal]）。

深入材料

• references/status-honesty-guide.md — 用于校准 🟢/🟡/🔴 状态（西瓜问题、连续出现 🟡 的规则、如实重新设定基线），以及按事实 → 影响 → 行动 → 请求的顺序表述坏消息。只要状态为 🟡/🔴，或输入中的描述比指标更乐观，就应参考此指南。
• templates/update-skeleton.md — 一页式可填写更新模板，包含质量检查标准和发送前检查清单。可提供给希望自行撰写更新的用户。

更新结构

1. BLUF（结论先行）

首先呈现最重要的信息：

• 状态：🟢 按计划进行 / 🟡 有风险 / 🔴 受阻 / ✅ 已完成
• 关键结论：用一句话概述当前状况
• 需要采取的行动：说明需要利益相关方提供什么支持（如有）

2. 进展摘要

简要概述已取得的成果：

• 本周期交付的内容
• 已达成的里程碑
• 关键指标的变化

最多保留 3-5 个要点。

3. 指标仪表板

关键指标

指标	当前值	目标值	趋势	状态
[指标名称]	[数值]	[目标值]	↑/→/↓	🟢/🟡/🔴

只列出最重要的 3-5 项指标。

4. 风险与阻碍

高优先级问题：

• 问题：简要描述
• 影响：可能造成的后果
• 缓解措施：正在采取的应对措施
• 需要的支持：利益相关方可以提供的帮助（如适用）

只列出对高管层面有重要影响的问题。

5. 后续里程碑

未来 30 天：

• 里程碑（预计日期）
• 里程碑（预计日期）

未来 90 天：

• 重要里程碑（月）
• 重要里程碑（月）

6. 需要做出的决策（如适用）

• 决策：清楚说明决策事项
• 选项：列出 2-3 个选项及其优缺点
• 建议：说明推荐方案及理由
• 时间安排：说明需要作出决策的时间

每次输出都以简短的 假设与缺口 区块结尾：用两到四个要点说明因输入未提及而作出的假设，以及最可能影响本次输出的缺失信息。如果没有任何假设或缺失信息，则用一行说明。

写作指南

语气：专业、简洁、以行动为导向
篇幅：控制在 1 页以内（或 2 分钟阅读时间）
频率：活跃项目每周更新，维护阶段每两周更新

高管沟通原则：

1. 先讲结论，不讲过程

   • ❌“本周我们进行了 5 次实验并分析了数据……”
   • ✅“通过优化，转化率提升了 15%”

2. 聚焦影响，不罗列活动

   • ❌“进行了 12 次客户访谈”
   • ✅“找到了影响用户采用的首要障碍（设置过程复杂）”

3. 尽早暴露问题

   • 不要粉饰风险
   • 提出解决方案，而不只是指出问题
   • 明确说明需要哪些帮助

4. 用数据讲述故事

   • 尽可能量化
   • 展示趋势，而不只是单个时间点的数据
   • 将指标与业务成果联系起来

5. 便于快速浏览

   • 使用标题和项目符号
   • 加粗关键信息
   • 使用视觉标记（🟢🟡🔴、↑→↓）

状态指南

🟢 进展顺利：达到所有目标，没有重大风险
🟡 存在风险：可能影响交付的问题
🔴 受阻：阻碍进展的关键问题，需要介入

更新示例

# Product Update: Customer Onboarding Redesign
**Week of Jan 20, 2026**

## BLUF
**Status**: 🟡 At Risk  
**Key Takeaway**: New onboarding flow is performing well in tests (+35% completion), but launch delayed one week due to integration issues with billing system.  
**Action Needed**: Decision needed on whether to launch onboarding separately or wait for billing integration fix.

## Progress Summary
- Completed user testing with 24 participants (94% positive feedback)
- Implemented first-time user experience improvements
- Resolved 12 of 15 bugs identified in QA
- Engineering allocated resources to billing integration fix

## Key Metrics
| Metric | Current | Target | Trend | Status |
|--------|---------|--------|-------|--------|
| Onboarding Completion | 45% | 60% | → | 🟡 |
| Time to First Value | 4.2 min | 3.0 min | ↓ | 🟢 |
| Setup Support Tickets | 45/week | <30/week | ↓ | 🟢 |
| User Activation Rate | 52% | 65% | → | 🟡 |

## Risks & Blockers

**HIGH: Billing System Integration Delay**
- **Impact**: Prevents users from completing onboarding flow; delays launch by 1-2 weeks
- **Root Cause**: API deprecation by payment processor, requires code rewrite
- **Mitigation**: Engineering team reallocated resources, fix ETA Feb 3
- **Decision Needed**: Launch onboarding without payment integration or wait for fix? (See below)

**MEDIUM: Mobile Testing Coverage**
- **Impact**: Some edge cases on older Android devices not tested
- **Mitigation**: Partnering with QA to expand test matrix; running beta with internal users on diverse devices

## Upcoming Milestones

**Next 30 Days:**
- Resolve billing integration (Feb 3)
- Launch onboarding redesign (Feb 5 or Feb 12 depending on decision)
- Begin measuring impact on conversion (Feb 12)

**Next 90 Days:**
- Iterate based on production data (March)
- Extend to mobile app (April)
- Launch advanced features (May)

## Decision Needed

**Should we launch onboarding separately from billing integration?**

**Option A: Launch Now (Recommended)**
- Pros: Get 35% completion rate improvement to users immediately, gather production data, maintain momentum
- Cons: Users need to complete payment in old flow, slightly disjointed experience
- Timeline: Launch Feb 5

**Option B: Wait for Billing Fix**
- Pros: Fully integrated experience from day one, no technical debt
- Cons: Delays benefits by 2 weeks, Q1 metric targets at risk, team momentum lost
- Timeline: Launch Feb 12

**Recommendation**: Option A. The onboarding improvements are valuable independently, and the old payment flow works fine. Waiting risks missing Q1 targets and delays validated improvements from reaching users.

**Timeline**: Need decision by Jan 22 for Feb 5 launch.

---

**Questions?** Reply to this email or ping me on Slack.

频率指南

每日站会：

• 极简（3 个要点）
• 昨天交付了什么
• 今天将交付什么
• 阻碍因素

每周更新：

• 使用上面的完整模板
• 聚焦进展和风险
• 控制在 1 页以内

每月回顾：

• 深入分析指标
• 战略反思
• 季度目标进展
• 可采用较长格式（2–3 页）

季度业务回顾：

• 全面分析
• 长期趋势
• 战略建议
• 演示文稿格式

按受众调整

面向高管团队

• 先讲业务影响
• 联系公司 OKR
• 聚焦战略和成果
• 尽量减少技术细节

面向产品／工程领导层

• 补充技术背景
• 展示冲刺／里程碑进展
• 讨论架构影响
• 提及技术债务

面向跨职能团队

• 平衡技术和业务背景
• 强调依赖关系
• 指出协作需求
• 明确提出请求

面向董事会／投资者

• 聚焦指标和业务增长
• 竞争定位
• 市场机会
• 财务影响

评分标准（0–40）

提交前，请根据此技能的评分标准为任意输出评分；达到 32 分及以上即可交付。

维度	0	5	10
先结论与状态诚实度	状态被埋没或缺失；更新读起来像活动流水账	开头说明了状态和要点，但表情符号粉饰了指标（外表绿色，内里红色）	前三行给出状态、一句话要点和请求；🟢／🟡／🔴 状态与最差的实质性指标相符，并说明原因
指标背景	只有原始数字，没有目标、趋势或周期对比	有目标，但指标只是与业务成果无关的活动计数	提供 3–5 项指标，每项都有目标、趋势和状态；关键指标与收入、客户或相关目标挂钩
风险可执行性	只列出令人担忧的风险，没有负责人、缓解措施或影响	提出了缓解措施，但影响未经量化，读者是否需要采取行动也不明确	每项风险都有量化影响、附带日期或成功条件的缓解措施，以及明确的“需要帮助”（或“无”）
决策框架	向高管抛出开放式问题，或完全没有提出需要决策的事项	列出了选项，但没有说明成本／权衡，也没有给出建议	每项决策都有 2–3 个列明成本的选项、明确且有理由的建议，以及需要决策的日期，并说明是什么因素决定了该日期

质量检查

• 用 BLUF 更新负责人——在任何细节之前说明状态、关键结论和所需行动
• 每项指标都要与目标进行比较（不能只报原始数字）
• 每项风险都要有缓解措施；如需利益相关者采取行动，还要标明“需要协助”
• 待决策事项要列出具体选项，并给出明确建议
• 总篇幅少于 1 页／阅读时间不超过 2 分钟

反面模式

• 不要把状态评估放在最后——BLUF 意味着最重要的信息要放在最前面
• 不要报告没有目标或前期数据对比的指标——没有上下文的原始数字毫无用处
• 不要只列出风险，却没有缓解措施，也没有明确标示是否需要利益相关者协助
• 不要把待决策事项写成疑问，却不给出明确建议——高管需要的是选项，而不是开放式问题
• 不要让更新超过 1 页——如果需要更多篇幅，应编辑内容，而不是扩写

执行

适用于能够访问团队沟通渠道（Slack、email）的工具型 Agent。发送更新属于对外操作：绝不能自动执行。无法使用工具的运行环境应忽略本节。请参阅 SKILLSPEC.md §5。

前提条件

• 最终更新文本必须逐字展示给人类并获得明确批准，其中包括确切的渠道／收件人列表。
• 渠道或收件人列表必须由用户指定，不能根据历史记录推断。
• 如果状态为 🔴 或包含待决策事项，请确认指定的决策者在收件人之列。

允许的操作

• 将批准的文本原样发布到唯一获批的渠道；或将其作为一封邮件发送给获批的收件人，并使用获批的主题行。
• 将副本保存到用户指定的位置（文档、Brain、仓库文件）。
• 不得执行其他操作：不得安排定期发送（相关操作请参阅 schedule-recipe，并遵守其自身的限制），不得添加获批文本中没有的 @提及，不得跨渠道转发。

验证

• 确认消息已出现在渠道／线程中（获取其永久链接），并将链接发回。
• 确认发送的文本与获批文本逐字节一致。

回滚

• 如果平台允许，只有在人类明确指示时，才可以删除刚发布的消息；否则应发布更正回复。
• 如果找不到渠道、发布部分失败，或即将发送的文本与获批文本不再一致，请停止并询问人类。

示例触发语

• “写一份状态更新。”
• “为领导层写一份进展报告。”
• “为利益相关者写一份项目更新。”
• “写一份高管简报。”