合同审查完成后需要向业务干系人写非法律摘要时用：把完整审查压…

当合同审查已完成、需要给业务方/采购/部门负责人等非法律受众一份关于能否签署、注意什么、要做什么的简短摘要时使用。

适用场景

解决思路

1. 【Matter 上下文】检查 practice-level CLAUDE.md 中的 `## Matter workspaces`。
2. 如果 `Enabled` 为 `✗`（in-house 用户默认），跳过本段其余内容；技能使用 practice-level context，matter 机制不可见。
3. 如果已启用且没有 active matter，询问：Which matter is this for? Run `/commercial-legal:matter-workspace switch <slug>` or say `practice-level`。
4. 加载 active matter 的 `matter.md`，获取 matter 特定上下文和覆盖项。
5. 将输出写入 matter 文件夹：`~/.claude/plugins/config/claude-for-legal/commercial-legal/matters/<matter-slug>/`。
6. 除非 `Cross-matter context` 为 `on`，绝不读取另一个 matter 的文件。
7. 【目的地检查】生成输出前检查它要去哪里。
8. 如果用户指定了目的地（频道、分发表、相对方、everyone），询问它是否在特权圈内。
9. 公开频道、公司全员列表、相对方/对方律师、供应商、客户（针对 work product）会放弃保护。
10. 当目的地看起来在特权圈外时，标记并给出选项：(a) 仅供法务使用的特权版本，(b) 供更大范围频道的脱敏版本，(c) 两者都提供；不要静默套上特权头，然后帮助粘贴到该头无法保护的地方。
11. 参见本插件 CLAUDE.md 中的 canonical `## Shared guardrails → Destination check`。
12. 【目的】把已完成的审查转成业务负责人要的答案：能否签署、有什么坑、需要做什么。
13. 【哪一侧】沿用底层审查 memo 的 sales-side 或 purchasing-side 框架。
14. purchasing-side 摘要告诉业务负责人：我们得到什么、同意了放弃什么；sales-side 摘要告诉业务负责人：我们卖什么、我们承担什么责任。
15. 检查审查 memo 顶部标注的是哪一侧，并匹配语气；如果无法从 memo 明显看出，先问律师再总结。
16. 【受众校准】读取 `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md` → `## House style` → 谁阅读 stakeholder summaries、应多长。
17. 如果未指定，默认：面向 procurement 或部门负责人，最多两段，不使用法律术语。
18. 按受众选择要点：Procurement 关心价格、续约机制、审批路径；不关心责任上限结构。
19. Department head（预算负责人）关心团队能否使用、出错会怎样、成本；不关心赔偿范围。
20. Finance 关心总体拥有成本、续约价格风险、表外承诺；不关心管辖法律。
21. Security / IT 关心数据处理、子处理商、SOC 2、数据存放地点；不关心其他内容。
22. Executive sponsor 关心是否会让公司难堪、法务是否成为阻碍；不关心细节。
23. 如果从上下文看不出给谁看，询问受众。
24. 【长度上限：强制执行】摘要包含：一段 verdict 和这是什么（业务条款、plain English）。
25. 一段 catch——如果现在不告诉干系人、以后会让他们意外的事。
26. 一个 2-3 项 checklist，列出干系人实际需要做什么（最多三项；如果想加第四项，说明前三项不够精炼）。
27. 一行 close，包含审批时机。
28. 总计低于 200 词。如果写更多，就是在包含干系人不需要的细节；完整备忘录里有那些细节，这份是在干系人回复前快速读的内容。
29. 如果 close 需要第三段，把它折进 checklist；不要让 close 长成第四个块。
30. 【引用范围纪律】引用合同条款时（在摘要、catch 段或 checklist 中），引用完整的条件句，不要截断。
31. 例如：条款写 “Except as expressly provided in the Order Form, renewal of promotional or one-time priced subscriptions resets to list price”（大意：除 Order Form 明确约定外，促销价或一次性定价订阅的续约恢复到 list price），不能截成 “renewal resets to list price”（续约恢复到 list price）；截断会丢掉条件并歪曲条款作用。
32. 如果完整条件引用不符合长度上限，改为转述而不是截断。例如 “For promotional pricing, renewal resets to list”（对于促销定价，续约恢复到 list price）是公平转述；“renewal resets to list”（续约恢复到 list price）不是，因为它把例外提升成规则。
33. 【格式】从 `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md` 的 `## Outputs` 前置 work-product header（按用户角色不同）。
34. 使用给定 Markdown 模板：header；如果转发到法务特权圈外（如业务干系人、相对方、供应商），移除上方 header；转发前确认你所在司法辖区和事项的正确标记。
35. 标题行格式：`**[Counterparty] [Agreement type]** — [READY TO SIGN | NEEDS CHANGES | BLOCKED]`（可签署/需要修改/受阻）。
36. 第一段用业务语言说明协议做什么；不要写“提供基于云的分析的 Master Services Agreement”，而要写“这是市场团队想要的仪表盘工具的合同”。
37. 第二段写干系人需要知道的内容：catch（如果有）、以后没人告诉就会让他们意外的事。例如「提醒：这份合同每年自动续约，必须在到期前 60 天取消。我已加入 tracker，但你应该知道。」或「合同干净，没有意外，可以签署。」
38. 不要声称「我已加入 tracker」，除非已确实为该合同运行 `renewal-tracker`。
39. 【断言前验证 tracker 条目】在摘要写「我已加入 tracker」或等价表述（「已在 tracker 中」「已跟踪」「已设置提醒」）前，验证 `renewal-tracker` 已为该合同运行。
40. 在 outputs 文件夹或 matter 文件夹检查是否有命名了该 counterparty / agreement 的 `renewal-tracker` 输出。
41. 如果没有：要么先为该合同运行 `renewal-tracker` 再写摘要；要么写摘要时不断言 tracker 条目，并加入行动项：「加入 renewal tracker——尚未完成。」
42. 声称不存在的 tracker 条目比省略该保证更糟；干系人会信任一个永远不会触发的提醒。如果真实情况是「已跟踪」，就运行 tracker；如果是「你应该自己加入日历——我没有记录」，就照实说。
43. 包含 `**What you need to do:**`（你需要做什么）checklist：行动项，如「确认团队能接受数据存放在 EU」或「无需行动——我会走签署流程」。
44. 包含 `**Approval:**`（审批）：谁审批、预计何时。
45. 【要翻译的内容】把法律发现翻译成业务语言：“责任上限为 12 个月费用” → “如果对方造成损失，我们最多只能追回已支付的一年费用。”
46. “无便利终止权” → “一旦签署，整个期限内被锁定——即使不再使用也不能随便取消。”
47. “自动续约且需提前 60 天通知” → “每年自动续约；要取消，必须在续约日前两个月通知对方。”
48. “无 IP 赔偿” → “如果有人起诉我们称这个工具侵犯其专利，供应商没有义务替我们抗辩。”
49. “未披露子处理商列表” → “我们不知道还有哪些公司会通过他们访问我们的数据。”
50. “终止后 30 天内删除数据” → “取消后，他们会在一个月内删除我们的数据。需要导出的东西要在此之前导出。”
51. “SLA 抵扣上限为月费的 10%” → “如果服务宕机，我们只能拿回一点抵扣；它覆盖不了宕机对业务造成的成本。”
52. 【不要包含】不要包含 section numbers。
53. 不要包含引号内的 defined terms。
54. 不要使用「indemnification」（赔偿）一词；改说「他们会在……时为我们兜底」/「我们会在……时为他们兜底」。
55. 不要使用「notwithstanding」（尽管有……）一词。
56. 不要使用带彩色点的风险矩阵，除非该干系人之前明确要求过。
57. 不要加入「这不是法律建议」之类的免责声明——干系人知道是谁发来的。
58. 【审查发现问题时】如果审查有 🔴 或 🟠 问题，摘要仍然需要两段；但第二段是「我们在反对什么以及为什么」。
59. 使用问题版模板：header（转发到特权圈外则移除）；标题 `**[Counterparty] [Agreement type]** — NEEDS CHANGES`（需要修改）。
60. 第一段写这是什么。
61. 第二段写：在准备好前，我们会就 [N] 件事回去找他们。主要一项：[用大白话写关键问题——例如「他们想用我们的数据改进产品，这意味着竞争对手的实例会因为我们的数据而变聪明」]。我们已要求删除该条。[现实评估：「他们很可能会同意」/「这可能是卡点——会持续同步。」]
62. 包含 `**What you need to do:**`（你需要做什么）：- [ ] 暂时无需行动——等对方回复后我会告诉你。或 - [ ] [业务决策：「如果他们在 X 上不让步，你能接受 Y，还是我们放弃？」]。
63. 【Handoffs】来自 `vendor-agreement-review` / `saas-msa-review`：这些技能产出一份完整 memo；本技能读取 memo 并压缩。
64. 不要重新审查合同——读取 review。
65. 发给干系人：通过 `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md` 指定的渠道。
66. 如果走 Slack，保持在 150 词以内；如果走 email，上面格式可原样使用。
67. 【Escalation-fan-out reconciliation】上游 review 是一对多生产者：它可能在不同发现中命名五个 escalation targets（Deputy GC、CISO、Privacy Officer、CFO、business owner）。`escalation-flagger` 一次路由一个发现。没有 reconciliation 步骤，Deputy GC 会看到 memo，而其他四个 approver 永远看不到。
68. 在生成摘要前，读取上游 review memo 并清点 escalations：
69. 1. 清点 review 命名的 escalation targets。查看 review 末尾的 routing / escalation block，或每个 finding 的“升级给 [X]”标签。按 approver 名字去重——同一个 reviewer 在两个 finding 中被命名只算一次。
70. 2. 清点实际已路由的 escalations。读取 review 文件夹（或 matter 文件夹）中自 review 写成后由 `escalation-flagger` 产出的 `escalation-*.md` 草稿。每份草稿命名一个 approver。
71. 3. Reconcile：如果命名了 N 个 approvers 且存在 M 份草稿，则 (N − M) 个 escalations 尚未路由。
72. 在摘要中包含简短 reconciliation block：位于 checklist 上方、catch 段下方。
73. 模板：`**Escalation status:** [M] of [N] escalation targets routed. The following have not been routed and require action:` 后接 `- [Approver name] — [one line on the finding that named them]`。
74. 如果全部 N 个都已路由：`**Escalation status:** [N] of [N] escalation targets routed.`
75. 如果上游 review 未出现 escalations，省略该 block。
76. 不要因为干系人不认识名字就把某个被命名的 approver 从 reconciliation 中省略。业务干系人常常不知道 Privacy Officer 或 CISO 是谁。Reconciliation 是内部面向的——它告诉发送摘要的律师路由是否都完成了，而不是给干系人看。
77. 如果面向干系人的摘要需要保持简短，reconciliation 可放在 “routing status” footer 或附注中——但它必须存在。暗示路由已完成而实际未完成，比没有摘要更糟。
78. 【词数例外】escalation reconciliation block 不受 200 词上限约束。摘要正文继续遵守长度纪律；reconciliation 是 housekeeping，不是叙述。
79. 【没有 escalation-flagger 草稿时】如果上游 review 命名了 approvers 且文件夹中没有草稿，则 M = 0。Reconciliation block 把所有 N 列为未路由。这就是发现。
80. 【语气注意】干系人记住法务的两件事：有没有挡住我、有没有讲得通。这个技能就是让法务讲得通。
81. 像在咖啡桌旁向聪明同事解释一样写，不要像写给档案的 memo。
82. 如果诚实的摘要就是「这没问题，签吧」，就这么说。不要把干净的审查硬撑成三段来显得周全。

适用边界 · 注意事项

• 不适用于尚未完成合同审查的场景；本技能只读取并压缩已有 review memo，不重新审查合同。
• 不适用于需要完整法律备忘录或逐条法律分析的场景；那是 `vendor-agreement-review` / `saas-msa-review` 的产出。
• 不适用于直接把带特权头的版本发到特权圈外；公开频道、公司全员列表、相对方/对方律师、供应商、客户等目的地需先标记并改发脱敏版或仅供法务版本。