Decision Memo Builder 是一个生成单页决策备忘录的技能，其核心目标是强制读者做出决定，而非状态更新、简报或知会。
用途 它用于撰写一份能让读者清楚知道自己被要求批准什么、何时批准以及为什么的单页备忘录。适用于领导层决策请求（自建/采购、招聘、裁撤、转型）、路线图决策（发布/延期/删减）、范围权衡（砍掉 X 以节省 Y）、战略转型，以及任何需要同级或高管给出“是/否”答复的时刻。
核心要求：备忘录 DNA 每份决策备忘录必须通过以下四条硬性要求，任何一条不达标就须重写：
- 极端简洁：1 页、约 400 字以内，每句话都要证明自己的价值，否则删除。
- 叙事线清晰（SCP）：按情境（Situation）→ 冲突（Complication）→ 解决（Resolution）展开，读者不会问“那又怎样？”。
- 强制决策：最后一行必须是带负责人和日期的“是/否”请求，绝不能写“需要进一步分析”。
- 证据密度：每个论点都由数字、引述或来源支撑，不靠形容词承担论证重量。
结构 备忘录按以下固定结构撰写：
- 标题（≤10 词）：命名决定，而非话题。如“Sunset legacy reporting engine by Q3”，而非“Reporting strategy update”。
- 情境（3–4 句）：请求之前的世界状态，只陈述事实和基线数字，不做宏大历史铺垫。
- 冲突（2–3 句）：说明变化或若不立即决定的风险，并给出使其紧迫的数字。
- 选项（2–3 个，每个 1–2 行）：彼此互斥，每个选项包含名称、一行描述、最重要的单一权衡（成本、时间或风险），不得在此偷藏建议。
- 建议（1 个短段落）：说明所选选项及它为何在关键决策标准上胜出，引用扭转判断的证据。
- 风险与缓解（≤3 条）：列出最可能出问题的三件事，各配一行缓解措施，不是风险清单。
- 请求（1 行）：具体的“是/否”请求，含负责人和日期。如“Approve sunset by EOD Friday; Sarah owns migration plan by 5/1.”，而非“Let's discuss next steps.”。
使用方式（流程）
- 起草前先访谈：询问读者是谁（CEO、VP、同级）、需要做什么决定、截止时间、真实的 2–3 个选项及哪个胜出、有哪些证据（数字、引述、基准）。
- 按备忘录 DNA 顺序起草：标题→情境→冲突→选项→建议→风险→请求。
- 四项测试：逐节确认是否满足备忘录 DNA，标出不达标之处。
- 删减 30%：初稿总是太长，去掉形容词、模糊措辞（如“potentially”“may”“could possibly”）和铺垫。
- 压力测试请求：读者仅凭备忘录能否回答“是/否”，若不能则继续锐化。
文档中的两个示例
- 工具迁移：建议将工程和产品团队从 Jira 迁移到 Linear，给出成本、迁移工作量、试点团队验证的生产力收益等依据及风险缓解。
- 范围削减：建议从 v2 发布中砍掉 AI-tagging，论证发布日期优先于该功能，并给出风险缓解。
反面模式 应避免：没有叙事线的要点堆砌；“我们应考虑……”式的回避决策措辞；缺失数字的模糊表述（“显著影响”“重大风险”“强信号”）；把建议泄漏进选项部分；请求只是“讨论下一步”；超过 1 页（若需更多，拆成备忘录+附录）。
限制与不适用场景 不适用于知会类更新（应使用状态说明）、头脑风暴（应使用 issue-tree-builder）、更广泛的战略叙事（应使用 scpr-framework）、演示文稿（应使用 storyline-builder）；评审后质量检查可搭配 mckinsey-critic。该技能的具体安装方式、收费模式、支持平台与运行环境等事实暂未提供。