commercial-stakeholder-summary

Imported from CSlawyer1985/legal-skillhub (skills/commercial-stakeholder-summary/SKILL.md). Install upstream with npx skills add CSlawyer1985/legal-skillhub --skill commercial-stakeholder-summary. Copyright stays with the author.

利益方摘要

事项上下文

事项上下文。 检查业务领域级 CLAUDE.md 中的 ## 事项工作区。如果 Enabled 为 ✗（法务用户的默认值），跳过本段其余内容——技能使用业务领域级上下文，事项机制不可见。如果已启用且没有活动事项，询问："这是哪个事项的？运行 commercial-matter-workspace switch <slug> 或说 practice-level。"加载活动事项的 matter.md 获取事项特定上下文和覆盖设置。将输出写入事项文件夹。除非 跨事项上下文 为 on，否则绝不读取其他事项的文件。

发送对象检查

生成输出前检查发送对象。如果用户指定了发送对象（频道、分发列表、对方当事人、"所有人"），询问是否在保密特权范围内。公共频道、全公司列表、对方当事人/对方律师、供应商和客户均放弃保护。当发送对象在圈外时，标注并给出 (a) 仅限法务查看的保密版本，(b) 适用于更广泛渠道的脱敏版本，或 (c) 两者。参见本插件 CLAUDE.md 中的 ## 共享安全机制 → 发送目的地检查。

目的

要签这份合同的业务负责人不想要法律备忘录。他们想知道：能签吗？有什么坑？需要我做什么？本技能将完成的审查转化为这样的回答。

哪一方？

底层审查备忘录是针对销售方还是采购方审查指引运行的。相应延续该框架。采购方摘要告诉业务负责人"我们能得到什么以及同意放弃什么"；销售方摘要告诉他们"我们卖的什么以及需要承担什么义务"。核查审查是针对哪一方运行的（通常在备忘录顶部标注），并匹配相应的表述口吻。如果从备忘录中看不出来，在撰写摘要前询问律师。

受众校准

阅读 $LEGAL_AGENT_PROFILE_HOME/commercial-legal/profile.md → ## 行文风格 → 利益方摘要面向哪些读者、篇幅要求。如未指定，默认为：采购或部门负责人，最多两段，无法律术语。

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

如果不清楚，询问这是给谁的。

摘要

篇幅上限——强制执行

摘要为：

• 一段 给出结论和这是什么的说明（商业用语）
• 一段 说明需要注意的地方——利益方如果没人告知会在事后感到意外的那件事
• 2-3项清单 列出利益方实际需要做的事（最多三项；如果想加第四项，说明前三项还不够精炼）
• 一行收尾 附审批时间

总计不超过200字。 如果超过，说明你包含了利益方不需要的细节——他们有备忘录可以查。这是利益方点击回复前的快速阅读。

如果收尾部分需要第三段，将其折入清单而非另起一段。不要让收尾扩展成第四块内容。

引用纪律

在摘要中引用合同条款（无论在"需注意"段还是在清单中），须引用完整的附条件句子，而非截断版本。"除订单表单另有明确规定外，促销价或一次性定价订阅的续约价格恢复标准价"与"续约价格恢复标准价"含义不同——截断删去了前提条件，歪曲了该条款的实际效果。

如果完整附条件引用不符合篇幅上限，用转述代替截断。"促销价格的续约恢复标准价"是合理转述；"续约恢复标准价"则不是——它将例外提升成了规则。

格式

在输出前加上工作成果文件头（参见插件配置 ## 输出规范，根据使用者角色有所不同——参见 ## 使用者）。

[工作成果文件头 — 按插件配置 ## 输出规范]
<!-- 如需转发至保密特权圈外（例如业务利益方、对方当事人或供应商），
请移除上方页眉。在转发前，请确认适用法域和具体事项的正确标注方式。 -->

**[对方当事人] [协议类型]** — [可以签字 | 需要变更 | 受阻]

[一段：本协议在商业用语中是什么。不是"提供基于云的分析平台主服务协议"——
而是"这是市场团队想要的仪表盘工具的合同。"]

[一段：利益方需要知道的事。如果有需要注意的地方——"注意：每年自动续约，
必须在到期60天前取消。已加入追踪器，但你应该知道。"或者："干净的协议，
无意外，可以签字。"]

<!-- 在摘要中表述"已加入追踪器"之前，须核实续约追踪器已实际
针对本合同运行——见下方"核实追踪器条目"说明。 -->

**你需要做的：**
- [ ] [操作事项，如有——"确认团队同意数据存放在境外"或"无需操作——我将安排签署"]

**审批：** [谁在审批及预期时间]

核实追踪器条目再表述。 在摘要表述"已加入追踪器"（或等效说法——"已追踪""已设提醒"）之前，核实续约追踪器已针对本合同实际运行。检查输出文件夹或事项文件夹中是否存在以该对方当事人/协议为对象的renewal-tracker输出。如果不存在：

• 先针对本合同运行renewal-tracker，再撰写摘要；
• 或撰写不含追踪器表述的摘要，并列入操作事项："添加至续约追踪器——尚未完成。"

在不存在追踪器条目的情况下声称其存在，比省略该说明更糟糕。利益方会信赖一个永远不会触发的提醒。如果真实情况是"已追踪"，技能运行追踪器；如果真实情况是"你需要自己记到日历——我还没登记"，如实告知。

转化参考

不包含什么

• 条款编号
• 带引号的定义术语
• "赔偿"这个词（说"他们兜底我们"或"我们兜底他们"）
• "尽管有"这个词
• 带颜色圆点的风险矩阵（除非该利益方之前明确要求过）
• 关于这不构成法律意见的保留说明——利益方知道是谁发的

审查发现有问题时

如果审查有 🔴 或 🟠 问题，摘要仍然只写两段——但第二段是"以下是我们要推回的内容及原因"。

[工作成果文件头 — 按插件配置 ## 输出规范]
<!-- 如需转发至保密特权圈外，请移除上方页眉。 -->

**[对方当事人] [协议类型]** — 需要变更

[这是什么，一段。]

我们在签字前需要就[N]项内容与对方沟通。最主要的一项：
[用普通话描述关键问题——"他们要求使用我们的数据来改进其产品，这意味着我们竞争对手的系统会从我们的数据中变得更聪明"]。我们已要求他们删除该条款。[现实评估："他们可能会同意"/"这可能是个难点——会及时更新进展。"]

**你需要做的：**
- [ ] 暂时无需操作——等他们回复后通知你。
  或
- [ ] [需要业务方作出的决定："如果他们在X上不让步，你能接受Y吗，还是我们走？"]

上报扇出对账

上游审查是一对多产出：它可能针对不同发现点名五个上报对象（副总法律顾问、CISO、隐私官、CFO、业务负责人）。escalation-flagger每次路由一个发现。如果没有对账步骤，副总法律顾问收到了备忘录，其他四个审批人却不知情。

在生成摘要前，阅读上游审查备忘录并统计上报情况：

1. 统计审查点名的上报对象数量。 查看审查末尾的路由/上报块，或逐条发现的"上报给[X]"标注。按审批人姓名去重——被两项发现点名的审批人只计一次。
2. 统计实际已路由的上报数量。 检查输出文件夹（或事项文件夹）中，审查完成后由escalation-flagger生成的escalation-*.md草稿。每份草稿点名一个审批人。
3. 对账。 如果点名了N个审批人，存在M份草稿，则(N − M)个上报未完成。

在摘要的清单上方、需注意段落下方，加入简短的对账块：

**上报状态：** [N]个上报对象中已路由[M]个。以下尚未路由，需要处理：
- [审批人姓名] — [点名该审批人的发现，一行说明]
- [审批人姓名] — [一行说明]

如果全部N个已路由：

**上报状态：** [N]个上报对象中已路由[N]个。

如果上游审查未涉及任何上报，省略该块。

不得因为利益方不认识某位审批人的名字而将其从对账中省略。 对账是内部导向的——它告诉发送摘要的律师所有路由是否已完成。如果面向利益方的摘要需要保持简洁，对账可以放在"路由状态"页脚或附注中——但必须存在。

字数豁免。 上报对账块豁免于200字上限。摘要正文的篇幅纪律保持不变；对账是管理事务，不是叙述内容。

当不存在escalation-flagger草稿时。 如果上游审查点名了审批人但文件夹中没有草稿，将计数视为M = 0。对账块列出全部N个为未路由。这就是发现本身。

交接

来自供应商协议审查/SaaS审查： 这些技能产出完整备忘录。本技能读取备忘录并压缩。不要重新审查合同——读审查结果。

至利益方： 通过审查指引中指定的渠道发送。如果是飞书/企业微信，控制在150字以内。如果是邮件，上述格式即可直接使用。

语气说明

利益方记住关于法务的两件事：是否阻碍了我，是否讲清楚了。本技能是法务如何讲清楚。写得像在咖啡旁向聪明同事解释一样。

如果诚实的摘要是"没问题，签吧"，就这样说。不要把干净的审查写成三段来显得详尽。