收到 Slack、邮件、指令或升级请求时…

当收到带压力的 Slack ping、email、mandate、escalation 或 FYI，需要回复或起草下一产出物时，用结构化拆解避免答错问题。

适用场景

解决思路

1. 在回复前，把收到的 Slack ping、email、mandate、escalation 或 FYI 解码成结构化拆解。
2. 以 chief-of-staff 级分析师、产品负责人视角，把字面请求与底层 job-to-be-done 分开，读取发送者权力与利益相关度，并通向回复或下一产出物。
3. 当请求听起来像 feature 或 build order 时，不要按 spec 拆解；先寻找其下的 outcome 和 job-to-be-done。
4. 从粘贴文本、截图、图片、附件或 PDF 中提取完整消息后再分析。
5. 获取并使用发送者身份及其相对你工作的角色、消息所处情境或线程、你想要的下一步（仅分析或还要起草回复）。
6. 把调用时随技能名传入的文本、粘贴的消息、周边备注或附加的 `ARGUMENTS:` 行视为已回答内容；把消息周围的文字视为发送者或情境上下文；已覆盖的信息跳过，不要重复询问。
7. 若只提供消息本身也可处理；当发送者或情境未知且会改变解读时，最多问 3 个针对性问题，每次一个，然后用清楚标注的假设继续。
8. 若消息部分不可读或被截断，明确说明，并基于现有内容继续。
9. 明确区分字面请求（文字要求什么）与 job-to-be-done（发送者真正追求的结果），并在每次拆解中显式分开。
10. 做 Sender Read：判断发送者是谁、相对你工作的角色，是 upstream（设定你的优先级）、peer（需要你配合）还是 downstream（依赖你的产出），并读取权力、利益相关度与潜台词。
11. 区分 success criteria（发送者如何判断结果是否成功：通过或失败标准、指标、完成定义）与 must-haves（交付物中必须包含的硬性要求），不要混为一谈。
12. 只从消息证据推理；每个猜测都标为 inference；绝不把猜测呈现为已陈述事实；所有推断放入 Assumptions to Validate。
13. 将拆解深度与消息匹配：十二个 section 按需折叠或跳过，空 section 在模板要求处标为 「none stated」；不要把琐碎消息硬填满十二节。
14. 遵循 Sticky-Note Rule：拆解中每个 bullet 为 4 到 8 个词，仅用 ASCII，短且可扫读；消息原文直接引用可豁免长度规则。
15. 使用 `workshop-facilitation` 作为本技能的默认交互协议，包括 session heads-up + entry mode（Guided、Context dump、Best guess）、单问题轮次与通俗语言提示、计入内联调用上下文以跳过已回答问题、打断处理与暂停或恢复行为。
16. 对本技能，把粘贴的消息当作 context dump；仅当发送者或情境确实未知且会改变解读时，才最多问 3 个澄清问题，每次一个。
17. 按 Step 1 提取消息：从任何到达形式（截图、图片、文件、PDF 或文本）中拉取完整消息后再分析。
18. 按 Step 2 只补会改变解读的缺口：若发送者身份或情境未知且会改变分析，最多问 3 个针对性问题，每次一个：1）谁发的、其相对你工作的角色？2）消息到达时的情境或线程？3）只要分析，还是也要起草回复？
19. 问完后用清楚标注的假设继续；不要问消息已经回答的问题。
20. 按 Step 3 用 Markdown 和给定结构渲染 breakdown；按消息缩放深度，折叠或跳过空 section；在模板要求处标 「none stated」；应用 Sticky-Note Rule；使用 `template.md` 作为可复制或粘贴的手工填写结构。
21. 渲染 Section 1 Classify：消息类型和渠道，一行；类型包括 meeting prep、feedback、feature request、mandate、escalation、FYI、ask for help、other。
22. 渲染 Section 2 Sender Read：发送者是谁、表面角色、关系 upstream、peer 或 downstream、重要处的权力和利益相关度。
23. 渲染 Section 3 Literal Ask：他们明确想要什么，用平实语言。
24. 渲染 Section 4 Underlying Problem Space：他们试图完成的 job、请求背后的 outcome、区分请求与需求。
25. 渲染 Section 5 Sentiment and Subtext：语气、紧迫性、挫败、热情、政治；若有迹象则引用。
26. 渲染 Section 6 Must-Haves vs Nice-to-Haves：交付物硬性要求与软偏好，清楚分开。
27. 渲染 Section 7 Hard Negatives：他们明确不想要什么；没有则 「None stated」。
28. 渲染 Section 8 Success Criteria：通过或失败标准、指标或完成定义、他们如何判断结果有效；只记录已陈述内容，隐含项标为 inference；没有则 「None stated」。
29. 渲染 Section 9 Hard Constraints：不可推迟日期、预算、不可妥协项；没有则 「None stated」。
30. 渲染 Section 10 Gaps and Ambiguities：承诺前不清楚或缺失什么。
31. 渲染 Section 11 Risks：范围、期望、政治、时间线雷点。
32. 渲染 Section 12 Recommended Next Steps：2 到 4 个具体行动，按顺序。
33. 在末尾列出 Assumptions to Validate：任何推断而非陈述的内容、猜测的 sender read 或意图、隐含的 success criteria 或 constraints。
34. 按 Step 4 渲染后现场开启对话：问 1 到 3 个最尖锐的问题来锐化建议，然后提供恰好 4 个下一步选项：1）起草给发送者的回复（Recommended）；2）为这个请求构建会议议程；3）把请求重构成 discovery framing；4）起草保护 outcome 的反提案。
35. 请用户回复 `1`、`2`、`3`、`4`、`1 and 3` 这样的组合或自定义路径。
36. 避免把 feature-shaped request 当作 build order 并跳到实现任务；始终运行 Section 4，在碰 how 之前命名 outcome 和 job-to-be-done。
37. 不要把 success criteria 和 must-haves 放在同一标题下；保持 Sections 6 和 8 严格分开，自问这是盒子里的东西还是衡量盒子的尺子。
38. 不要把关于发送者动机的猜测呈现得像消息已陈述；每个猜测标为 inference 并放入 Assumptions to Validate。
39. 不要为两句话 FYI 渲染全部十二节；按消息缩放深度，折叠空 section，标 「none stated」，一行 ping 给一段话解读。

适用边界 · 注意事项

• 不适合替代工程规格拆解：当目标是写代码、拆实现任务或生成技术方案时，不要用它找 outcome 来替代 spec。
• 不适合没有具体 incoming message 的泛泛沟通咨询；至少要有消息或可描述的消息内容。
• 不适合对纯 FYI 或一句话通知强行套完整十二节拆解；应直接确认、归档或按需极简回应。