stakeholder-summary

利益相关者摘要

事项背景

事项背景。 查看实践级 CLAUDE.md 中的 ## Matter workspaces。如果 Enabled 为 ✗（内部用户的默认设置），跳过本段其余内容——技能会使用实践级背景，事项机制不可见。如果已启用但没有活跃事项，请询问：“这是关于哪个事项的？运行 /commercial-legal:matter-workspace switch <slug>，或回复 practice-level。”加载活跃事项的 matter.md，以获取事项专属背景和覆盖设置。将输出写入事项文件夹 ~/.claude/plugins/config/claude-for-legal/commercial-legal/matters/<matter-slug>/。除非 Cross-matter context 为 on，否则切勿读取其他事项的文件。

---

目的地检查

生成输出之前，先检查内容要发送到哪里。如果用户指定了目的地（某个频道、分发列表、交易对手方、“所有人”），请询问该对象是否属于特权圈。公开频道、全公司列表、交易对手方／对方律师、供应商，以及作为工作成果接收方的客户，都会放弃保护。当目的地看起来位于特权圈之外时，请明确指出，并提供以下选项：(a) 仅供法务使用的享有特权版本；(b) 可在更广泛频道分享的脱敏版本；或 (c) 两者兼备——不要默默加上特权标头，然后又协助将内容粘贴到标头无法提供保护的地方。请参阅本插件 CLAUDE.md 中的规范部分 ## Shared guardrails → Destination check。

目的

请律师审阅合同的业务负责人不想要法律备忘录。他们想知道：能不能签、有什么隐患，以及自己需要做什么。此技能会将已完成的审阅转化为他们想要的内容。

哪一方？

底层审阅备忘录依据销售方或采购方的作业手册编写。摘要应延续相应的视角。采购方摘要要告诉业务负责人“我们获得了什么，以及同意放弃了什么”；销售方摘要要告诉他们“我们要出售什么，以及要承担哪些义务”。确认审阅所依据的一方（应在审阅备忘录开头注明），并采用相应的语气。如果从备忘录中看不出来，请先询问律师，再撰写摘要。

受众校准

阅读 ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md → ## House style → 了解谁会阅读利益相关者摘要，以及摘要应有多长。如果未作说明，默认受众为采购人员或部门负责人，最多两段，不使用法律术语。

不同受众需要不同的摘要：

受众	关心的内容	不关心的内容
采购人员	价格、续约机制、审批流程	责任上限结构
部门负责人（预算负责人）	团队能否使用、出问题时会怎样、成本	赔偿范围
财务	总拥有成本、续约价格风险、表外承诺	管辖法律
安全／IT	数据处理、子处理方、SOC 2、数据存储位置	其他所有内容
执行发起人	这会不会让我们难堪、法务是否会阻碍进度	细节

如果无法从上下文中判断受众，请询问摘要是写给谁看的。

摘要

长度上限——严格执行

摘要包括：

• 一段说明结论和事项内容（业务条款，使用通俗语言）
• 一段说明隐患——如果现在没人告知利益相关者，日后会让他们感到意外的内容
• 一份 2-3 项的清单，列出利益相关者实际需要做的事（最多三项；如果想加第四项，说明前三项还不够精简）
• 一句话的结尾，说明审批时间

总字数少于 200 词。 如果写得更多，就包含了利益相关者不需要的细节——他们可以查看备忘录。此摘要是利益相关者点击回复前快速浏览的内容。

如果结尾需要第三段，就将其并入清单。不要让结尾扩展成第四个区块。

引用范围 — 严谨

在引用合同条款时（无论是在摘要、「关键点」段落还是清单中），都要引用完整的条件句，不能截断。例如，条款写着「除订单表格明确规定的情形外，促销订阅或一次性定价订阅续订时将恢复为标价」，这与「续订时将恢复为标价」含义不同——截断后丢掉了条件，也歪曲了条款的实际作用。

如果完整的条件句引用超出摘要的长度上限，请改用释义，而不要截断。「对于促销定价，续订时将恢复为标价」是合理的释义；「续订时将恢复为标价」则不合理——它把例外说成了规则。

格式

在最前面加上 ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md 中 ## Outputs 下的工作成果页眉（具体内容因用户角色而异——参见 ## Who's using this）。

[WORK-PRODUCT HEADER — per plugin config ## Outputs]


**[Counterparty] [Agreement type]** — [READY TO SIGN | NEEDS CHANGES | BLOCKED]

[One paragraph: what this agreement does, in business terms. Not "Master Services
Agreement for the provision of cloud-based analytics" — "this is the contract
for the dashboard tool the marketing team wants."]

[One paragraph: what the stakeholder needs to know. The catch, if there is one.
The thing that will surprise them later if nobody tells them now. E.g., "Heads
up: this auto-renews every year and we have to cancel 60 days out. I've added
it to the tracker but you should know." Or: "Clean agreement, no surprises,
cleared to sign."]



**Verify tracker entries before asserting them.** Before the summary says "I've added it to the tracker" (or any equivalent — "it's in the tracker," "tracked," "set a reminder"), verify that `renewal-tracker` has been run for this contract. Check the outputs folder or the matter folder for a `renewal-tracker` output that names this counterparty / agreement. If there isn't one:

- Either run `renewal-tracker` for this contract first, then write the summary.
- Or write the summary without asserting the tracker entry, and include an action item: "Add to renewal tracker — not yet done."

Claiming a tracker entry exists when it does not is worse than omitting the reassurance. The stakeholder then trusts the reminder that will never fire. If the truthful statement is "tracked," the skill runs the tracker. If it's "you should add this to your calendar — I haven't logged it," say that.

**What you need to do:**
- [ ] [Action item, if any — "confirm the team is okay with data living in EU"
  or "nothing — I'll route for signature"]

**Approval:** [who's approving and expected timing]

翻译内容

法律结论	业务说明
「责任上限为 12 个月的费用」	「如果他们造成损失，我们最多只能追回相当于一年服务费的金额。」
「不得为便利而终止」	「签约后，我们就必须履行整个合同期限——即使不再使用，也不能直接取消。」
「提前 60 天通知的自动续约」	「合同每年自动续约。要取消，我们必须在续约日期前两个月通知他们。」
「不承担知识产权侵权赔偿责任」	「如果有人起诉我们，声称这个工具侵犯了他们的专利，供应商没有义务为我们辩护。」
「未披露次级处理方名单」	「我们不知道还有哪些公司会通过他们访问我们的数据。」
「终止后 30 天内删除数据」	「取消后，他们会在一个月内删除我们的数据。请在此之前导出所需内容。」
「SLA 抵扣额上限为月费的 10%」	「如果服务中断，我们只能获得少量抵扣。这无法弥补服务中断给业务造成的损失。」

不要包含的内容

• 条款编号
• 加引号的定义术语
• 「赔偿」一词（改说「如果……他们会保障我们」／「如果……我们会保障他们」）
• 「尽管有前述规定」
• 带彩色圆点的风险矩阵（除非该利益相关方之前明确要求过）
• 关于这不是法律建议的免责声明——利益相关方知道是谁发来的

审查发现问题时

如果审查发现了 🔴 或 🟠 问题，摘要仍应写成两段——但第二段要说明「我们正在反对什么，以及原因」。

[WORK-PRODUCT HEADER — per plugin config ## Outputs]


**[Counterparty] [Agreement type]** — NEEDS CHANGES

[What it is, one paragraph.]

We're going back to them on [N] things before this is ready. The main one:
[the critical issue in plain English — "they want the right to use our data
to improve their product, which means our competitors' instance gets smarter
from our data"]. We've asked them to strike it. [Realistic assessment: "They'll
probably agree" / "This might be a sticking point — will keep you posted."]

**What you need to do:**
- [ ] Nothing yet — I'll let you know when it's back from them.
  OR
- [ ] [Business decision they need to make: "If they won't budge on X, are you
  okay with Y, or do we walk?"]

交接

**来自 vendor-agreement-review / saas-msa-review：**这些技能会生成完整备忘录。本技能读取备忘录并精简内容。不要重新审查合同——阅读审查结果即可。

**发给利益相关方：**通过 ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md 指定的渠道。如果是 Slack，请控制在 150 字以内。如果是电子邮件，上述格式可以直接使用。

升级分派对账

上游审查是一个一对多的生成方：它可以在不同发现中列出五个升级对象（副总法律顾问、CISO、隐私官、CFO、业务负责人）。escalation-flagger 一次只处理一个发现。如果没有对账步骤，副总法律顾问会看到备忘录，而其他四位审批人都看不到。

生成摘要前，先阅读上游审查备忘录并统计升级事项：

1. 统计审查中列出的升级对象。 查找审查末尾的路由／升级部分，或各项发现中的“升级给 [X]”标签。按审批人姓名去重——同一位审查人对应两项发现，只计一次。
2. 统计实际完成路由的升级事项。 在审查文件夹（或事项文件夹）中查找 escalation-*.md 草稿，这些草稿由 escalation-flagger 在审查撰写后生成。每份草稿对应一位审批人。
3. 进行对账。 如果列出了 N 位审批人，而存在 M 份草稿，则有 (N − M) 项升级尚未完成路由。

在摘要中加入一个简短的对账区块，放在核对清单上方、承接段落下方：

**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]
- [Approver name] — [one line]

如果 N 项均已完成路由：

**Escalation status:** [N] of [N] escalation targets routed.

如果上游审查没有发现任何升级事项，则省略此区块。

不要因为利益相关方不认识某位审批人，就在对账中省略其姓名。 业务利益相关方往往不知道隐私官或 CISO 是谁。对账内容面向内部——它是告诉发送摘要的律师路由是否全部完成，而不是告诉利益相关方。如果面向利益相关方的摘要需要保持简洁，对账可以放在“路由状态”页脚或随附说明中，但必须存在。如果摘要暗示路由已完成，而事实并非如此，那比没有摘要更糟。

字数限制豁免。 升级对账区块不受 200 字上限约束。摘要正文仍须遵守篇幅限制；对账是例行事项，不是叙述内容。

没有 escalation-flagger 草稿时。 如果上游审查列出了审批人，但文件夹中没有草稿，则将 M 视为 0。对账区块应将全部 N 位审批人列为尚未完成路由。这就是发现的问题。

关于语气的说明

利益相关方对法律事务记得两件事：有没有挡住我的事，以及讲得有没有道理。这项技能就是让法律事务讲得明白。写得像是在喝咖啡时向聪明的同事解释，而不是像在写归档备忘录。

如果真实的总结是“没问题，签吧”，就直说。不要为了显得全面，把一份没有问题的审查硬凑成三段。