审查 SaaS/订阅协议：逐项核查自动续约、涨价、数据退出…

在检测到 SaaS 或订阅协议并需要按团队 playbook 做购买方或销售方法律审查时使用。

适用场景

解决思路

1. 1. 检查 practice-level `CLAUDE.md` 的 `## Matter workspaces`；若 `Enabled` 为 `✗`（in-house 用户默认），跳过该段其余内容；若启用且无 active matter，询问：「Which matter is this for? Run `/commercial-legal:matter-workspace switch <slug>` or say `practice-level`.」；加载 active matter 的 `matter.md` 获取 matter 特定上下文和覆盖项；将输出写到 `~/.claude/plugins/config/claude-for-legal/commercial-legal/matters/<matter-slug>/`；除非 `Cross-matter context` 为 `on`，否则永不读取另一个 matter 的文件。
2. 2. 运行 `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md` 中的标准 playbook 检查，并叠加 SaaS 特定审查层，覆盖自动续约、涨价、数据可携带、正常运行时间 SLA、子处理者、服务变更/弃用等。
3. 3. 管辖假设：套用 `CLAUDE.md` 中记录的团队立场；若协议选择不同 governing law，或交易跨越有法定覆盖的司法辖区（如 EU 用户、California 消费者），标记该分析可能不按书面内容迁移。
4. 4. 无静默补充：若对配置的法律研究工具（`Westlaw` 或 firm platform）的研究查询返回很少或无结果，且可能涉及法定覆盖（自动续约法、数据可携带命令、消费者保护规则），报告找到什么并停止；不要未经询问用 web search 或模型知识填补空白；提供选项：(1) 扩大搜索查询，(2) 换研究工具，(3) web search（结果标 `[web search — verify]`，依赖前核对一手来源），(4) 标为未验证并停止；由律师决定是否接受较低置信来源。
5. 5. 来源标注：引用法条、法规或案例时打标签：`[Westlaw]`、`[statute / regulator site]` 或从法律研究连接器检索的 MCP 工具名；web search 用 `[web search — verify]`；训练数据用 `[model knowledge — verify]`；来自对方草案或所内文件用 `[user provided]`；标记 `verify` 的引文伪造风险更高，应优先核对；永不剥离或合并标签。
6. 6. 判断 side：若对方是向你销售平台的 SaaS 供应商，为 purchasing-side；若你是 SaaS 供应商且对方是客户，为 sales-side；若不明显（转售、白标），询问：「Which side is [company] on for this agreement — vendor or customer?」；从配置读取匹配的 `### Sales-side playbook` 或 `### Purchasing-side playbook`；在输出中注明所用 side；若匹配 side 为 `[Not configured]`，停止并告诉用户先运行 `/commercial-legal:cold-start-interview --side <side>`。
7. 7. 先读取 `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md`；匹配 side 的通用 playbook（责任、赔偿、终止、管辖法律）完全适用；运行 vendor-agreement-review skill 的全部标准检查。
8. 8. 查找 `## Playbook` → 匹配 side → `SaaS positions` 节；该节记录团队对自动续约通知窗口、可接受价格递增、数据导出权、SLA 阈值、子处理者批准权、弃用通知的立场；本技能不提供默认值。
9. 9. 若 `CLAUDE.md` 未覆盖审查中出现的 SaaS 特定条款，询问团队立场并记录到 `CLAUDE.md`，然后继续。
10. 10. SaaS 特定叠加：对每个类别，列出合同中发现的条款并对照 `CLAUDE.md` 中团队立场；不要套用本技能硬编码阈值。
11. 11. 自动续约机制：检查续约期限长度（与初始期相同、更长、多年自动转换）；检查取消通知窗口（续约前多少天）；检查通知方式（email、书面通知 legal、仅 portal、挂号信）；检查续约价格（相同、CPI 封顶、then-current list、无上限自由裁量）；并对照团队 `SaaS positions`。
12. 12. 无论是否有项目被标记，提取并记录准确续约日期和通知窗口，供 renewal-tracker 使用。
13. 13. 价格递增：检查年度递增（固定百分比、CPI、无上限等）；检查使用量超额定价（公布费率卡、溢价费率、未指定）；检查「费用」范围（仅订阅 vs. 广义定义的「附加服务」）；对照 `CLAUDE.md`。
14. 14. 数据可携带和退出：检查导出格式（开放/标准、专有但有文档、「commercially reasonable」）；检查导出可用性（自助随时、期限内应请求、仅终止时）；检查终止后访问（终止后多少天可导出）；检查导出成本（免费、T&M、按 GB 或按记录）；检查删除认证（应请求认证、无、供应商保留衍生数据）；对照 `CLAUDE.md`。
15. 15. 供应商保留「匿名化」或「聚合」衍生数据是重大立场；确认团队立场并无论如何标记。
16. 16. 正常运行时间和 SLA：仅在业务实际依赖该服务可用时检查；若是 nice-to-have 工具则跳过本节，不要为 SLA 花谈判资本；对照 `CLAUDE.md` 检查正常运行时间承诺（百分比或「commercially reasonable efforts」）；检查测量周期（月、季、年）；检查补救（服务信用如何计算、是否封顶、是否唯一救济）；检查计划维护排除（定义窗口、提前通知、无限）；检查 credit-as-sole-remedy 与责任上限的交互。
17. 17. 子处理者：检查当前列表（公布、应请求提供、不可获得）；检查变更通知（提前通知期或无）；检查反对权（阻止、通知并终止、仅通知、无）；对照 `CLAUDE.md`。
18. 18. 服务变更和弃用：检查重大不利变更（重大降级时终止权、仅通知、无限制）；检查团队依赖功能的弃用通知期；检查替代功能的 feature parity（同价格层、更高层）；对照 `CLAUDE.md`。
19. 19. AI/ML 数据权决策程序：不要只检查 AI 训练条款是否存在；按七维工作。
20. 20. 明确授权：合同是否明确授予供应商使用 Customer Data / Customer Content / Usage Data 进行 AI 训练、模型改进或 ML 开发的权利；purchasing-side 通常为 NO；sales-side 是收入但滥用有声誉风险。
21. 21. 通过政策隐式授权：合同是否以引用方式纳入供应商隐私政策或服务条款；供应商能否通过单方政策更新增加训练权；检查「The parties agree to the Provider's Privacy Policy as updated from time to time」；也注意「service improvement」或「analytics」兜底，以及把日志/遥测从 Customer Data 定义中切出的「usage data」定义。
22. 22. 匿名化标准：若供应商声称仅训练「匿名化」或「聚合」数据，标准是什么；无定义的「匿名化」很弱；是否符合 GDPR Recital 26 / HIPAA Safe Harbor / 指定标准；是否可逆。
23. 23. 竞争污染：供应商是否服务你的竞争对手；若是，训练你的数据可能把竞争情报泄漏到竞争对手看到的输出；是否有竞争隔离承诺。
24. 24. 选择退出范围与持久性：若有 opt-out，是否覆盖所有 AI 用途还是部分；是否在续约和 TOS 更新后继续有效；是按用户还是按组织；检查合同是否明确默认。
25. 25. 输出所有权：若 SaaS 产品本身由 AI 生成（起草、摘要、分析），谁拥有输出；供应商能否把你的输出当训练样本；检查第三方 AI 子处理者；供应商可能把客户数据发给第三方 LLM（OpenAI、Anthropic、Google），子处理者列表/数据流中会显示。
26. 26. 下游监管链：供应商把你的数据用于 AI 是否给你造成监管暴露；EU AI Act deployer 义务、FTC §5 未披露数据共享暴露（见 FTC v. Humor Rainbow/OkCupid）、州 AI 法律。
27. 27. 将每一维匹配到 playbook 立场；实践 profile 的 `## AI/ML training rights` 节应有每维立场；若协议对七维全部沉默，仍属发现：协议对 AI/ML 训练权沉默——要求明确禁止或针对上述七个维度分别定义例外。
28. 28. 责任上限决策程序：上限金额是上限中最不重要的部分；不要只做单条 playbook 检查。
29. 29. 直接 vs 间接/后果性损害赔偿：上限是否适用于所有责任，还是仅直接损害赔偿；12 个月直接赔偿上限加上不封顶后果性赔偿与 12 个月总上限完全不同；明确陈述两种处理。
30. 30. 上限基数——逐字引用：「12-month cap」可能指 (a) 索赔前 12 个月已付费用，(b) 当前 12 个月期间应付费用，(c) 过去 12 个月使用费用，(d) 当前 order form 下费用，(e) 迄今总费用；数量级可能不同；引用准确语言；若模糊则标记：上限基数模糊——`[the quoted language]`——可能指 [X] 或 [Y]。签署前确认。
31. 31. 上限与 carveout 交互：$100K 上限加上数据泄露、IP、保密不封顶，对 SaaS 实际争议而言功能上不封顶；枚举在上限之上的（carveouts）和之下的（实际被封顶的），评估被封顶表面是否有意义：上限覆盖 [general contract breach]；数据泄露、IP 赔偿和保密被 carve out 且不封顶；对该供应商风险画像，被封顶表面是 [meaningful / nominal]。
32. 32. 每维 playbook 立场：实践 profile 应有直接上限（费用倍数）、间接损害赔偿（排除/封顶/不封顶）、carveout 清单（可接受上限之上内容）、上限基数（接受哪个定义）；若 playbook 只有一个标准立场字段，注明：你的 playbook 只有一个 cap 立场——考虑拆分为 direct/indirect/carveouts/base 以做更精确审查。
33. 33. 司法辖区差异检查：playbook 全球适用一个管辖法律偏好，但可执行性差异大；在接受 playbook 立场前检查实际 governing law 与主要差异。
34. 34. 非招揽/竞业禁止：在 CA 不可执行（`Bus. & Prof. Code §16600`）；许多 EU 司法辖区受限；其他地方有限制但可执行；`[jurisdiction — verify]`。
35. 35. 自动续约：`CA GBL §17600-17606`、`NY GBL §527-a`、`IL 815 ILCS 601` 有特定消费者/B2B 通知要求；其他州不同；`[jurisdiction — verify]`。
36. 36. 责任排除：EU 和 UK 不公平合同条款规则（`UCTA 1977`、`Consumer Rights Act 2015`）约束消费者排除；一些美国州限制排除重大过失或故意不当行为；`[jurisdiction — verify]`。
37. 37. 赔偿：一些州对被赔偿人自身过失的赔偿无效；`[jurisdiction — verify]`。
38. 38. 保密期限：一些司法辖区把「永久」保密限制在合理期间；`[jurisdiction — verify]`。
39. 39. 当 playbook 立场与合同 governing-law 可执行性冲突，标记：你的 playbook 偏好 [X]，但本合同受 [Y] 法管辖，而 [X] 在该法下 [unenforceable / restricted / subject to statutory override]。`[jurisdiction — verify]`。
40. 40. 红线粒度：以尽量小的粒度编辑；红线是谈判工件，不是重写。
41. 41. 默认最小编辑实现 playbook 立场：先替换 word 再 phrase（如「twelve (12)」→「twenty-four (24)」）；先替换 phrase 再 sentence（如「paid by the Buyer」→「paid and payable by the Buyer」）；先重构 subclause 再替换 sentence（加「(a)」「(b)」拆分复合条件）；先替换 sentence 再替换 clause；仅当对方版本离你的立场太远，外科手术式编辑比新草稿更难读时，才替换 whole clause，并在 transmittal 中说明：我们替换了 §8.2 而非逐条标记，因为改动较多；乐意带你过一遍差异；有疑问时更小。
42. 42. 输出：使用 vendor-agreement-review memo 结构，在标准 playbook 检查后添加 SaaS 特定节；memo 已带 privilege header。
43. 43. 双严重度：每个 SaaS 特定发现同时有法律风险（🔴 Critical | 🟠 High | 🟡 Medium | 🟢 Low）和业务摩擦（🔴 Blocks deals | 🟠 Slows deals | 🟡 Confuses customers | 🟢 Invisible）；数据退出、自动续约、价格递增发现最可能为 🟢 legal / 🔴 business；按业务摩擦严重度呈现，而非法律严重度。
44. 44. 输出模板：Bottom line [Can you sign / Need to fight for X first / Walk — one-sentence why]；AI and machine learning rights [标记 explicit ML training clauses、service improvement catch-alls、usage data definitions、output ownership、third-party AI subprocessors、opt-out vs opt-in；若沉默写「协议对 AI/ML 训练权沉默——要求明确禁止或定义例外。」]；SaaS-specific findings：Auto-renewal（Renewal date、Notice window、Renewal price mechanism、Playbook fit、Flag for renewal-tracker）；Price escalation；Data exit；SLA（或「Skipped — service is not business-critical per [stakeholder]」）；Subprocessors；Service changes。
45. 45. Handoff 到 renewal-tracker：发现续约日期和通知窗口时移交；renewal-tracker register 期望字段（见 `skills/renewal-tracker/references/renewal-register.yaml` 完整 schema）：counterparty、agreement、signed_date、initial_term_end、renewal_mechanism、notice_period_days、cancel_by_effective（initial_term_end 减 notice_period_days）、price_on_renewal、annual_value、business_owner、clm_id、status；若字段无法从合同或上下文确定，留空并说明缺失字段供人工填写；`clm_id`、`annual_value`、`business_owner` 尤其可能需要人工输入。
46. 46. Handoff 到 escalation-flagger：若任何 SaaS 特定检查命中 `CLAUDE.md` 中团队的「never accept」或 escalation-trigger 清单，escalation-flagger skill 负责路由。
47. 47. 关于争什么：SaaS 供应商，尤其大厂，像航空公司谈判票价一样不愿谈其纸面条款；按团队 playbook 选择战斗；`SaaS positions` 节应区分团队总会争的条款、仅重大交易争的条款、可放过的条款；若 playbook 未划线，询问；根据合同价值和切换成本校准；$5K/年且替代品容易的工具比 $500K/年且要基于其构建的平台轻触。
48. 48. 以 next-steps decision tree 收尾：按 `CLAUDE.md` `## Outputs` 结束；根据本技能产出定制选项；五个默认分支（draft the X、escalate、get more facts、watch and wait、something else）是起点而非锁定；tree 是输出，律师选择。

适用边界 · 注意事项

• 当服务不是业务关键（如 nice-to-have 的调查工具）时，不适用 SLA 审查，也不应为其投入 SLA 谈判资本。
• 当团队 playbook 未配置对应 side（sales-side 或 purchasing-side）时，不适用；需先运行 `/commercial-legal:cold-start-interview --side <side>`。
• 当协议选择不同 governing law，或交易涉及有法定覆盖的司法辖区（如 EU 用户、California 消费者）时，不能直接套用团队立场，必须标记并可能先做法律研究。