审阅供应商合同时，对照团队 playbook…

当你需要按团队既定立场（而非市场标准）审阅一份供应商 MSA、服务协议或类似合同时，用它逐条比对、定级风险、给出具体替换措辞并确定审批路径。

适用场景

解决思路

1. 先检查实践级 CLAUDE.md 中的 `## Matter workspaces`：若 `Enabled` 为 `✗`（内部用户的默认值）则跳过 matter 机制；若启用且无活跃 matter，询问“Which matter is this for? Run `/commercial-legal:matter-workspace switch <slug>` or say `practice-level`.”；加载活跃 matter 的 `matter.md` 获取上下文与覆盖项；输出写入 `~/.claude/plugins/config/claude-for-legal/commercial-legal/matters/<matter-slug>/`；除非 `Cross-matter context` 为 `on`，否则绝不读取其他 matter 的文件。
2. 输出前做目的地检查：若用户指定了目的地（频道、分发列表、对手方、“everyone”），询问是否在特权圈内；公开频道、全公司列表、对手方/对方律师、供应商、客户（针对工作成果）都会导致保护失效；若目的地看起来在圈外，提示并提供 (a) 仅法务可见的特权版本、(b) 面向更广渠道的脱敏版本、(c) 两者都要——不要悄悄加上特权标头后又帮用户粘贴到标头无法保护的地方。
3. 读合同前先读 `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md`；若缺失或仍是占位符，给出提示：运行 `/commercial-legal:cold-start-interview`（2 分钟）配置画像，或说 “provisional” 按通用默认值审阅。
4. provisional 模式：使用通用默认值（中等风险偏好、律师角色、美国司法辖区、无 playbook，从第一性原理标记常见供应商侧风险——无限责任、无数据泄露除外条款、无上限赔偿、无通知自动续约等），在审阅说明和每个发现块上标注 `[PROVISIONAL]`，并在输出末尾追加提示用户运行 `/commercial-legal:cold-start-interview` 以校准输出。
5. 应用 playbook 前先确定公司在该合同中的立场：对手方是提供商品/服务的供应商/供货方则为采购侧；对手方是购买你产品/服务的客户则为销售侧；若不明显（转售、合作、收入分成），询问“Which side is [company] on for this agreement — vendor or customer?”；读取配置中对应的 `### Sales-side playbook` 或 `### Purchasing-side playbook`；在输出中注明所用立场；若对应侧为 `[Not configured]`，停止并让用户先运行 `/commercial-legal:cold-start-interview --side <side>`。
6. 先检查 playbook 中的“one thing”deal-breaker：若存在，在备忘录顶部用 `## ⛔ DEAL-BREAKER PRESENT` 块标记（含条款号、deal-breaker 内容、建议 push back 的具体替代措辞或 walk away），并停止详细审阅。
7. Step 1 定向：快速通读全文，填写表格回答——协议类型（MSA / SaaS subscription / Professional services / License / Other）、我方身份（Customer / Vendor）、对手方（名称，BigCo 不会谈判还是 startup 会谈判）、金额（年/总合同价值）、期限与续约机制、是否有 DPA（附上/URL 引用/缺失）、是否有订单表单（独立文档还是整合）。
8. 金额处理：若主协议未写明金额（MSA 定条款、Order Form 载价格，属典型情况），在跑升级计算或应用金额阈值前停下来询问：粘贴 Order Form 金额（首选）、告知高于/低于阈值（备忘录标注路由假设）、或保守路由到更高审批人；绝不要静默假设金额并用它驱动路由。
9. DPA 引用处理：若主协议以“available at [URL]”等方式并入 DPA，在定向表和审阅备忘录中明确标注该 DPA 是合同一部分但不在眼前，说明数据保护分析不完整；若装有 `privacy-legal`，主动提出把 DPA URL 交给 `/privacy-legal:dpa-review` 单独审阅，或先抓取并内联阅读再完成 Step 3 的数据保护分析；不要把“缺失 DPA”和“未读 DPA”混为一谈。
10. Step 3 逐条比对：对 playbook 中每个类别找到合同对应条款并比较；每个偏差产出块包含——条款号与问题名、Playbook says（引用配置原文）、Contract says（合同原文引用）、Gap（Missing term / Weaker than standard / Weaker than fallback / Non-standard structure / Unacceptable）、Legal risk（🔴 Critical / 🟠 High / 🟡 Medium / 🟢 Low）、Business friction（🔴 Blocks deals / 🟠 Slows deals / 🟡 Confuses customers / 🟢 Invisible）、Why it matters（一两句大白话说明业务后果）、Proposed redline（可直接粘贴进 markdown 的具体替换措辞）、If they won't move（配置中的 fallback，或“escalate to [person]”）。
11. 严重度校准：🔴 Critical = 不修不能签（在“never accept”清单上或属 deal-breaker）；🟠 High = 强力争取，对方不让就升级（超出 playbook 声明的 fallback 范围）；🟡 Medium = 第一轮争取，若是最后未决项可接受（在 fallback 范围内但未达标准立场）；🟢 Low = 记录但不投入谈判资本（playbook 明确容忍或纯风格偏差）；严重度始终对照配置；若某条款无法清晰映射到 playbook 立场，询问用户归入哪一档并提出记录到配置中。
12. 责任上限决策程序——不要只写一行“对照 playbook 检查责任上限”，逐项明确陈述四个维度：(1) 直接损害 vs 间接/后果性损害：上限适用于全部责任还是仅直接损害？12 个月直接损害上限 + 无上限后果性损害与 12 个月总上限是完全不同的立场，两者都要写明；(2) 上限基数——逐字引用：“12-month cap”可能指索赔前 12 个月已付费用、当前 12 个月应付费用、最后 12 个月使用费用、当前订单表单下费用、历史总费用，差异可达一个数量级；引用原文，若含糊则标记“Cap base is ambiguous — `[quoted language]` — could mean [X] or [Y]. Confirm before signing.”；(3) 上限除外条款交互：10 万美元上限但数据泄露、IP、保密无上限赔偿，对 SaaS 争议中实际发生的索赔而言功能上等于无上限；列举哪些在上限之上（carveouts）、哪些在下限之下（实际被限的），评估被限范围是否有意义；(4) 按维度对照 playbook 立场：直接上限（费用倍数）、间接损害（排除/设限/无上限）、可接受的 carveout 清单、可接受的上限基数定义；若 playbook 只有一个“standard position”字段，建议拆分为 direct/indirect/carveouts/base 以获得更精确审阅。
13. 司法辖区差异检查：playbook 全球适用一个准据法偏好，但可执行性差异很大；对照合同实际准据法检查主要分歧——竞业禁止/禁止招揽（加州 Bus. & Prof. Code §16600 不可执行，许多欧盟辖区受限，其他地区有限度可执行）、自动续约（加州 GBL §17600-17606、纽约 GBL §527-a、伊利诺伊 815 ILCS 601 有特定通知要求）、责任排除（欧盟/英国 UCTA 1977、Consumer Rights Act 2015 限制消费者排除，部分美国州限制重大过失或故意不当行为排除）、赔偿（部分州对赔偿方自身过失的赔偿条款无效）、保密期限（部分辖区将“永久”保密限制在合理期间）；当 playbook 立场与准据法可执行性冲突时标记：“Your playbook prefers [X], but this contract is governed by [Y] law where [X] is [unenforceable / restricted / subject to statutory override]. `[jurisdiction — verify]`”。
14. Step 4 列出两份短清单：Better than our standard（供应商给得比我们要求的更多，可作为谈判交换筹码）和 Missing entirely（完全缺失的标准条款，最常见：转让限制、审计权、不可抗力、保险要求）。
15. Step 5 升级路由：对照配置中的升级矩阵，结合合同金额、是否存在 🔴 critical 问题、任何自动升级触发条件（无限责任、IP 转让等），明确写出谁需要批准：`## Approval routing` 块列出 [Name/role] approval（原因）和 Business owner sign-off（应介入的具体商业条款），并给出推荐下一步（向对手方发红线 / 回复前升级给 GC / 法务回复前先获取业务对商业条款 X 的意见）。
16. 向对手方发送红线前，读配置 `## Who's using this`：若 Role 为 Non-lawyer，提示“Sending redlines is a legal act — the counterparty will treat every edit as our negotiating position. Have you reviewed this with an attorney?”，生成一页纸简报（对手方、协议类型、拟提红线、每条背后的 playbook 立场、fallback、发件前应向律师询问什么），并告知可通过职业监管机构（美国州律师协会、英格兰及威尔士 SRA/Bar Standards Board、苏格兰/北爱/爱尔兰/加拿大/澳大利亚 Law Society 或辖区对等机构）获取转介；未获明确 yes 不得越过此关。
17. 红线粒度：默认做最小可行编辑——先改词再改短语（“twelve (12)” → “twenty-four (24)”），先改短语再改句子（“paid by the Buyer” → “paid and payable by the Buyer”），先重构子条款再替换整句（加 “(a)” 和 “(b)” 拆分复合条件），先替换句子再替换整条；只有当对手方版本离我方立场太远、外科手术式编辑比重新起草更难读时才整条替换，并在传送说明中写明“We've replaced §8.2 rather than marking it up because the changes were extensive. Happy to walk you through the delta.”；拿不准时选更小的改动。
18. Step 6 组装备忘录：按配置 `## Outputs` 加上工作成果标头（因用户角色而异，见 `## Who's using this`）；备忘录和底层协议可能受特权/保密保护，输出继承该状态，仅在特权圈内分发、存放在特权材料所在处、对外交付前（如对手方红线、利益相关方摘要）剥离工作成果标头；注明所应用的 playbook 立场反映配置中 `Governing law and venue` 记录的辖区，若交易涉及不同准据法或法律选择问题则在备忘录中标记。
19. 无静默补充：若对配置的法律研究工具查询某规则（限制条款可执行性、赔偿范围、准据法选择）返回很少或无结果，报告所找到的内容并停止；不要未经询问就用网络搜索或模型知识填补，应说“The search returned [N] results from [tool]. Coverage appears thin for [rule / jurisdiction]. Options: (1) broaden the search query, (2) try a different research tool, (3) search the web — results will be tagged `[web search — verify]` and should be checked against a primary source before relying, or (4) flag as unverified and stop. Which would you like?”。
20. 来源标注：备忘录引用法规、规章或案例时打标签——`[Westlaw]`、`[statute / regulator site]` 或法律研究连接器的 MCP 工具名；网络搜索用 `[web search — verify]`；训练数据回忆用 `[model knowledge — verify]`；对手方草稿或内部文件用 `[user provided]`；带 verify 的引用伪造风险更高应优先核查；绝不剥离或合并标签。
21. 按模板组装备忘录：工作成果标头、标题 `# Vendor Agreement Review: [Counterparty] [Agreement Type]`、Reviewed 日期、Contract value、Our role: Customer、`## Bottom line`（两句话：能否签、先改什么；法律风险与商业摩擦各按 🔴🟠🟡🟢 计数；Approval needed from）、`## Deal-breaker check`（✅ Clear 或 ⛔ Present）、`## Issues by severity`（Step 3 的偏差块按 Critical → Low 分组）、`## Favorable terms`、`## Missing provisions`、`## Approval routing`、`## Redline package`（如被要求，汇总所有拟改的 markup-ready 措辞）。
22. 若连接了 CLM MCP，审阅后：检查该对手方是否已有与我方的协议（可能影响谈判姿态，如“上次交易已给过 24 个月上限”）、拉取匹配该协议类型的工作流模板、提出创建 CLM 记录并附上审阅备忘录、预路由审批人。
23. 若连接了 DocuSign MCP 且协议已可签（全绿或所有问题已接受），提出生成 envelope 并按升级矩阵以正确顺序路由签署人；没有明确指示绝不发送任何待签文件——“Ready to sign” 是律师的判断不是你的。
24. 生成签署 envelope 或路由会签前，读配置 `## Who's using this`：若 Role 为 Non-lawyer，提示“This step has legal consequences (signing binds the company to the whole agreement). Have you reviewed this with an attorney?”，生成一页纸简报（对手方、合同金额、发现的问题及解决方式、律师接受的风险、envelope 发出前应向律师询问什么），并告知可通过职业监管机构获取转介；未获明确 yes 不得越过此关。
25. 输出格式：默认完整备忘录（放入 CLM 记录或配置 house-style 部分的 Drive 文件夹）；Slack 版摘要两行加链接，格式如 `[Counterparty] [type] — NEEDS WORK. 1🔴 (uncapped liability §8.2), 2🟠. Full review: [link]. Needs [GC] approval.`；若用户要求红线文档，用 docx skill 输出带修订痕迹的 .docx，每条修改的批注引用 playbook 立场。
26. 交付前质量检查：配置已加载并引用（非通用市场立场）、deal-breaker 已先检查、每个问题都有具体替换措辞、风险等级已校准（不是所有都是 Critical）、审批人有名有姓（不是“escalate to legal”）、已考虑对手方背景（BigCo vs. startup 影响哪些值得争）。
27. 以下一步决策树收尾：按 CLAUDE.md `## Outputs` 给出决策树，选项按本次产出定制——五个默认分支（draft the X、escalate、get more facts、watch and wait、something else）是起点而非锁定；决策树即输出，由律师选择。

适用边界 · 注意事项

• 尚未配置实践画像（`~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md` 缺失或仍是占位符）且用户不愿用 provisional 模式时——此时无法按团队真实 playbook 审阅。
• 合同对应侧（销售侧或采购侧）在配置中为 `[Not configured]` 时——必须先运行 `/commercial-legal:cold-start-interview --side <side>`。
• 用户角色为 Non-lawyer 且未获律师审阅时——不得越过发送红线或生成签署 envelope 的关卡。