从尽调发现构建重大合同披露附表（按购买协议定义与格式）

当需要根据购买协议中的“重大合同”定义和附表格式，从尽调发现中生成披露附表时使用。

适用场景

解决思路

1. 加载购买协议，提取“Material Contract”定义和附表格式。
2. 检查实践级 CLAUDE.md 中的 `## Matter workspaces`：若 `Enabled` 为 `✗`（内部用户的默认值），跳过其余事项机制，使用实践级上下文；若启用且无活跃事项，询问“Which matter is this for? Run `/corporate-legal:matter-workspace switch <slug>` or say `practice-level`.”；加载活跃事项的 `matter.md` 获取事项特定上下文和覆盖项；将输出写入事项文件夹 `~/.claude/plugins/config/claude-for-legal/corporate-legal/matters/<matter-slug>/`；除非 `Cross-matter context` 为 `on`，否则绝不读取其他事项的文件。
3. 加载上下文：购买协议草案（用于“Material Contract”定义和附表格式）、`~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md` 中的重要性阈值（可能与协议定义不同——以协议为准）、来自 diligence-issue-extraction 的尽调发现（合同级数据）。
4. 第1步：从购买协议中提取“Material Contract”定义——以 PA 定义为准。注意交易结构差异（stock vs. asset vs. merger）可能改变某一条款的解释方式，受监管行业叠加（healthcare、defense、financial services、telecom、government contracting）可能增加 PA 之外的同意要求；若涉及这些叠加，研究适用的 anti-assignment 或 novation 规则（例如 federal contracts、government contracting novation、sector-specific consent statutes）并引用控制规则。
5. 在 PA 定义中查找常见条款类别（不能替代阅读 PA，以 PA 使用的列表为准）：金额阈值（年度或累计）、期限长度、控制权变更或反转让条款、排他性或竞业禁止、前 N 大客户或供应商合同、不动产租赁、IP 许可（in-bound 和 out-bound）、关联方协议、政府合同、日常业务之外的合同。PA 的定义是测试标准——机械地应用它：任何满足 PA 定义中任一条款的合同都列入附表。
6. 第2步：对每份尽调审查的合同，用表格应用定义：Contract | Meets prong(s) | Include，例如 [name] | [$X+ annual value; CoC provision] | Yes 或 [name] | [none] | No。标记边缘情况供人工决定：合同金额为 $X-1（刚好低于阈值）但对业务重要；合同满足某条款但将被终止；口头协议或 side letters 可能算也可能不算。
7. 第3步：为每份纳入的合同收集附表数据：Counterparty name（来源：Contract）、Contract title/type（Contract）、Date（Contract）、Term / expiration（Contract）、Annual/total value（Contract 或 management data）、Which materiality prong it meets（第2步分析）、Consent required for the deal（Diligence finding）、VDR reference（Diligence inventory）。从现有尽调提取中拉取；若字段缺失，标记出来——不要猜测。
8. 第4步：按协议格式排版。披露附表有固定格式——通常是编号列表或表格，有时按合同类型分小部分。匹配草案协议中其他附表的格式。示例：`## Schedule 3.[X] — Material Contracts`，`The following are the Material Contracts as of the date hereof:`，`### (a) Customer Contracts`，`1. [Agreement Title], dated [date], between [Target] and [Counterparty].`，`[Brief description if the format calls for it.]`，`[VDR: path]`，`### (b) Supplier Contracts`，`### (c) Real Property`，`[etc. — sub-parts per the agreement's definition structure]`。
9. 第5步：单独（不在附表本身中——这是内部文件）跟踪哪些已列入附表的合同需要同意。注意：同意叠加层和任何交付前工作草案源自特权尽调材料，继承其特权和保密状态——在特权圈之外分发可能放弃特权；附表本身一旦作为已执行 PA 的附件交付，即为交易文件，不享有特权；交付前删除任何内部注释。跟踪表：Schedule # | Counterparty | Consent required | Status | Owner | Due，例如 3.X(a)(1) | [name] | Yes — CoC §12.2 | Requested | [name] | [date]。此表馈入 closing-checklist。
10. 交付前交叉检查：每份满足条款的合同都在附表上（完整性）；没有不满足条款的合同在附表上（不过度披露——这是陈述，不是数据转储）；附表与其他陈述一致（Schedule 3.X 上产生留置权的合同也应出现在留置权附表上）；每个条目都有 VDR 引用，以便买方律师找到底层文件。
11. 交接：来自 diligence-issue-extraction——合同级发现是输入；到 closing-checklist——同意事项列入清单。
12. 本技能不做：不决定重要性定义——那在购买协议中；不获取同意——只跟踪需要哪些；不起草陈述——只填充陈述所引用的附表。

适用边界 · 注意事项

• 不适用于决定重要性定义——该定义在购买协议中，本技能只应用它。
• 不适用于获取同意——本技能只跟踪哪些同意需要获取。
• 不适用于起草陈述——本技能只填充陈述所引用的附表。