需要按受众和节奏写周报、月报、发布公告或风险升级时…

把同一进展翻译成高管简报、工程细节、跨职能协作或客户外部版本的干系人更新。

适用场景

解决思路

1. 使用 /stakeholder-update $ARGUMENTS 生成干系人更新；遇到不熟悉的占位符或需检查已连接工具时查看 CONNECTORS.md。
2. 工作流1：询问用户要写哪种更新类型。
3. 更新类型 Weekly：写常规节奏的进度、阻塞项和下一步更新。
4. 更新类型 Monthly：写更高层总结，包含趋势、里程碑和战略对齐。
5. 更新类型 Launch：写功能或产品发布公告，包含细节和影响。
6. 更新类型 Ad-hoc：写针对特定情况的一次性更新，如风险升级、转向、重大决策。
7. 工作流2：询问更新面向谁。
8. 受众 Executives / leadership：写高层、结果导向、战略框架且简短的版本。
9. 受众 Engineering team：写技术细节、实现背景、阻塞项和所需决策。
10. 受众 Cross-functional partners：写适合上下文的细节，聚焦共同目标和依赖。
11. 受众 Customers / external：写利益导向、时间线清晰且无内部术语的版本。
12. 受众 Board：写指标驱动、战略、风险导向且非常简洁的版本。
13. 工作流3：若 ~~project tracker 已连接，从中拉取上下文。
14. 从 ~~project tracker 拉取 roadmap 项和里程碑状态。
15. 从 ~~project tracker 识别自上次更新以来完成的事项。
16. 从 ~~project tracker 暴露处于风险或阻塞的事项。
17. 从 ~~project tracker 拉取 sprint 或 iteration 进度。
18. 若 ~~chat 已连接，从中搜索相关团队讨论和决策。
19. 从 ~~chat 查找频道中提出的阻塞项或问题。
20. 从 ~~chat 识别异步做出的关键决策。
21. 若 ~~meeting transcription 已连接，拉取最近会议记录和讨论摘要。
22. 从 ~~meeting transcription 查找相关会议中的决策和行动项。
23. 若 ~~knowledge base 已连接，搜索最近会议记录。
24. 从 ~~knowledge base 查找决策文档或设计评审。
25. 若无工具连接，要求用户提供自上次更新以来完成的内容。
26. 若无工具连接，要求用户提供当前阻塞项或风险。
27. 若无工具连接，要求用户提供已做或需要做出的关键决策。
28. 若无工具连接，要求用户提供接下来要做什么。
29. 工作流4：按目标受众使用下方模板和框架组织更新。
30. 为高管生成：包含 TL;DR、状态颜色 G/Y/R、与目标绑定的关键进展、已做决策、带缓解措施的风险、具体请求和下一里程碑；控制在 300 词以内。
31. 为工程团队生成：包含已发布内容（带链接）、进行中内容（带负责人）、阻塞项、所需决策（带选项和建议）以及下一步。
32. 为跨职能伙伴生成：包含即将影响他们的内容、需要他们做什么（带截止日期）、影响其团队的决策以及开放征求意见的领域。
33. 为客户生成：包含新内容（以利益表述）、即将推出、带 workaround 的已知问题和反馈方式；不要使用内部术语。
34. 为发布公告生成：包含发布了什么、为何重要、关键细节（范围、可用性、限制）、成功指标、发布计划和反馈渠道。
35. 工作流5：生成更新后，询问用户是否调整语气、细节程度或重点。
36. 工作流5：主动提供按交付渠道格式化的版本，如 email、chat post、doc、slides。
37. 工作流5：若 ~~chat 已连接，主动提供可发送的消息草稿。
38. 高管/领导模板：写 Status: [Green / Yellow / Red]。
39. 高管/领导模板：写 TL;DR: [一句话，最重要的事]。
40. 高管/领导模板 Progress：写达成并绑定 goal/OKR 的结果。
41. 高管/领导模板 Progress：写达到的里程碑及其影响。
42. 高管/领导模板 Progress：写关键指标变化。
43. 高管/领导模板 Risks：写 [Risk]: [Mitigation plan]. [Ask if needed].。
44. 高管/领导模板 Decisions needed：写 [Decision]: [Options with recommendation]. Need by [date].。
45. 高管/领导模板 Next milestones：写 [Milestone] — [Date]。
46. 高管更新技巧：先给结论，不要讲过程；写成「we shipped X and it moved Y metric」而不是「we had 14 standups and resolved 23 tickets」。
47. 高管更新技巧：控制在 200 词以内；他们想要更多会主动问。
48. 高管更新技巧：状态颜色反映你自己的真实判断，而不是你认为他们想听的；Yellow 不是失败，是良好的风险管理。
49. 高管更新技巧：只包含你想寻求帮助的风险；已经在处理且他们无需知道的风险不要列出。
50. 高管更新技巧：请求必须具体，例如「Decision on X by Friday」而不是「support needed」。
51. 工程团队模板 Shipped：写 [Feature/fix] — [Link to PR/ticket]. [Impact if notable].。
52. 工程团队模板 In progress：写 [Item] — [Owner]. [Expected completion]. [Blockers if any].。
53. 工程团队模板 Decisions：写 [Decision made]: [Rationale]. [Link to ADR if exists].。
54. 工程团队模板 Decisions：写 [Decision needed]: [Context]. [Options]. [Recommendation].。
55. 工程团队模板 Priority changes：写 [What changed and why]。
56. 工程团队模板 Coming up：写 [Next items] — [Context on why these are next]。
57. 工程更新技巧：链接到具体 tickets、PRs 和 documents，方便工程师点开看细节。
58. 工程更新技巧：优先级变化时解释原因，工程师理解原因后更投入。
59. 工程更新技巧：明确说明什么在阻塞他们，以及你正在做什么来解除阻塞。
60. 工程更新技巧：不要用不影响他们工作的信息浪费他们的时间。
61. 跨职能伙伴模板 What's coming：写 [Feature/launch] — [Date]. [What this means for your team].。
62. 跨职能伙伴模板 What we need from you：写 [Specific ask] — [Context]. By [date].。
63. 跨职能伙伴模板 Decisions made：写 [Decision] — [How it affects your team].。
64. 跨职能伙伴模板 Open for input：写 [Topic we'd love feedback on] — [How to provide it].。
65. 客户/外部模板 What's new：写 [Feature] — [Benefit in customer terms]. [How to use it / link].。
66. 客户/外部模板 Coming soon：写 [Feature] — [Expected timing]. [Why it matters to you].。
67. 客户/外部模板 Known issues：写 [Issue] — [Status]. [Workaround if available].。
68. 客户/外部模板 Feedback：写 [How to share feedback or request features]。
69. 客户更新技巧：不用内部术语、ticket 编号或技术实现细节。
70. 客户更新技巧：一切从客户现在能做什么来表述，而不是你构建了什么。
71. 客户更新技巧：时间线要诚实但不要过度承诺；「Later this quarter」比可能错过的日期更好。
72. 客户更新技巧：只有客户可感知且已有解决计划的已知问题才提及。
73. 状态报告 Green（On Track）：按计划推进。
74. 状态报告 Green：没有重大风险或阻塞。
75. 状态报告 Green：有望达成承诺和截止日期。
76. 状态报告 Green：只在确实进展顺利时使用，不要把它当默认值。
77. 状态报告 Yellow（At Risk）：进度慢于计划，或风险已发生。
78. 状态报告 Yellow：缓解措施正在进行但结果不确定。
79. 状态报告 Yellow：若不加干预或调整范围，可能无法达成承诺。
80. 状态报告 Yellow：主动使用，越早标记风险，可选方案越多。
81. 状态报告 Red（Off Track）：显著落后于计划。
82. 状态报告 Red：存在没有明确缓解措施的重大阻塞或风险。
83. 状态报告 Red：若不做重大干预（砍范围、加资源、延时间线），将无法达成承诺。
84. 状态报告 Red：在确实需要帮助时使用，不要等到太晚。
85. 状态变更：在出现风险的第一时间改为 Yellow，而不是等确定情况变坏。
86. 状态变更：当你已用尽自己的选项且需要升级时改为 Red。
87. 状态变更：只有当风险真正解决时才改回 Green，而不只是暂停。
88. 状态变更：改变状态时记录变化原因，例如「Moved to Yellow because [reason]」。
89. 风险沟通 ROAM Resolved：风险不再是问题，记录如何解决。
90. 风险沟通 ROAM Owned：风险已被承认且有人积极管理，写明负责人和缓解计划。
91. 风险沟通 ROAM Accepted：风险已知但选择不缓解继续推进，记录理由。
92. 风险沟通 ROAM Mitigated：行动已将风险降到可接受水平，记录做了什么。
93. 有效沟通风险第1步：清楚陈述风险，例如「There is a risk that [thing] happens because [reason]」。
94. 有效沟通风险第2步：量化影响，例如「If this happens, the consequence is [impact]」。
95. 有效沟通风险第3步：说明可能性，例如「This is [likely/possible/unlikely] because [evidence]」。
96. 有效沟通风险第4步：给出缓解措施，例如「We are managing this by [actions]」。
97. 有效沟通风险第5步：提出请求，例如「We need [specific help] to further reduce this risk」。
98. 风险沟通常见错误：不要把风险埋在好消息里；重要时要先讲风险。
99. 风险沟通常见错误：不要含糊说「There might be some delays」，要具体说明什么、多久、为什么。
100. 风险沟通常见错误：不要只提风险不给缓解措施；每个风险都应附带计划。
101. 风险沟通常见错误：不要等待太久；早沟通的风险是规划输入，晚沟通的风险是救火。
102. ADR 格式：写 # [Decision Title]。
103. ADR 格式：写 ## Status，值为 [Proposed / Accepted / Deprecated / Superseded by ADR-XXX]。
104. ADR 格式：写 ## Context，说明需要决策的情况和正在起作用的力量。
105. ADR 格式：写 ## Decision，清楚直接地陈述决定了什么。
106. ADR 格式：写 ## Consequences，列出影响。
107. ADR 格式 Consequences：写正面结果。
108. ADR 格式 Consequences：写负面结果或接受的权衡。
109. ADR 格式 Consequences：写这会启用或阻止未来什么。
110. ADR 格式：写 ## Alternatives Considered，列出评估过的其他选项；每个写是什么以及为何被拒绝。
111. 写 ADR 时机：战略性产品决策，如目标市场细分、支持平台。
112. 写 ADR 时机：重大技术决策，如架构选择、供应商选择、build vs buy。
113. 写 ADR 时机：有争议且人们不同意的决策，记录理由供未来参考。
114. 写 ADR 时机：会限制未来选项的决策，如选择技术、签署合作。
115. 写 ADR 时机：预期未来会被质疑的决策，趁上下文新鲜时记录。
116. ADR 技巧：在决策做出后尽快写，不要拖数周。
117. ADR 技巧：记录谁参与决策以及谁做最终决定。
118. ADR 技巧：充分记录上下文，未来读者没有今天的上下文。
119. ADR 技巧：可以记录事后看是错误的选择，添加「superseded by」链接。
120. ADR 技巧：保持简短，一页比五页好。
121. Stand-up / Daily Sync：每人分享自上次同步以来完成了什么。
122. Stand-up / Daily Sync：每人分享接下来在做什么。
123. Stand-up / Daily Sync：每人分享什么在阻塞他们。
124. Stand-up 引导技巧：控制在 15 分钟；出现讨论就转到线下。
125. Stand-up 引导技巧：聚焦阻塞项，这是站会最高价值的部分。
126. Stand-up 引导技巧：跟踪阻塞项并跟进解决。
127. Stand-up 引导技巧：如果没有什么可同步就取消站会，尊重大家时间。
128. Sprint / Iteration Planning：Review 上一个 sprint 发布了什么、顺延了什么、砍掉了什么。
129. Sprint / Iteration Planning：Priorities 确定本 sprint 最重要的目标。
130. Sprint / Iteration Planning：Capacity 确定团队能承担多少，考虑 PTO、on-call、会议。
131. Sprint / Iteration Planning：Commitment 从 backlog 选择符合容量和优先级的事项。
132. Sprint / Iteration Planning：Dependencies 标记跨团队或外部依赖。
133. Sprint 规划引导技巧：带着建议的优先级顺序来，不要问团队从零开始排序。
134. Sprint 规划引导技巧：反对过度承诺；少承诺并可靠交付更好。
135. Sprint 规划引导技巧：确保每个事项有明确负责人和明确验收标准。
136. Sprint 规划引导技巧：标记范围不足或隐藏复杂度的事项。
137. Retrospective：Set the stage，提醒团队目标并建立心理安全。
138. Retrospective：Gather data，收集什么做得好、什么不好、什么令人困惑。
139. Retrospective：Generate insights，识别模式和根因。
140. Retrospective：Decide actions，选择 1-3 个下个 sprint 要尝试的具体改进。
141. Retrospective：Close，感谢大家诚实反馈。
142. Retro 引导技巧：创造心理安全，人们必须感到安全才能诚实。
143. Retro 引导技巧：聚焦系统和流程，不要针对个人。
144. Retro 引导技巧：限制为 1-3 个行动项；超过这个数量就什么都不会改变。
145. Retro 引导技巧：跟进上次 retro 的行动项；如果从不跟进，人们会停止参与。
146. Retro 引导技巧：偶尔改变 retro 形式以防陈旧。
147. Stakeholder Review / Demo：Context，提醒干系人目标和上次他们看到的内容。
148. Stakeholder Review / Demo：Demo，展示构建出的东西；用真实产品，不要用 slides。
149. Stakeholder Review / Demo：Metrics，分享任何早期数据或反馈。
150. Stakeholder Review / Demo：Feedback，安排结构化时间提问和输入。
151. Stakeholder Review / Demo：Next steps，说明接下来是什么以及下次评审何时进行。
152. Demo 引导技巧：尽可能演示真实产品；slides 不是 demo。
153. Demo 引导技巧：框架化收集反馈；「What feedback do you have on X?」比「Any thoughts?」更好。
154. Demo 引导技巧：可见地记录反馈，并承诺处理它或解释为何不处理。
155. Demo 引导技巧：设定预期，说明此阶段什么样的反馈可操作。
156. 输出格式：保持更新可扫读；用 bold 标关键点，用 bullets 列清单。
157. 输出格式：高管更新控制在 300 词以内。
158. 输出格式：工程更新可以更长，但仍要结构化以便略读。
159. 通用技巧：最常见错误是埋没重点；从最重要的事开始。
160. 通用技巧：状态颜色反映现实而非乐观；Yellow 不是失败，是良好的风险沟通。
161. 通用技巧：请求要具体且可执行；「We need help」不是请求，「We need a decision on X by Friday」才是。
162. 通用技巧：对高管，一切用结果和目标表述，而不是活动和任务。
163. 通用技巧：如果有坏消息，先讲坏消息，不要藏在好消息后面。
164. 通用技巧：按受众注意力匹配长度；高管给几条 bullets，工程给所需细节。

适用边界 · 注意事项

• 面向客户/外部更新时不要使用内部术语、ticket 编号或技术实现细节。
• 不要把最重要信息或坏消息埋在好消息后面。
• 不要用乐观判断粉饰 Green/Yellow/Red 状态；风险未真正解决时不要改回 Green。