Menu
从尽调发现构建重大合同披露清单，适用股权收购协议的重大合同定义，并按 协议清单格式排版。当用户说"建合同清单""披露清单""清单 3.X" "重大合同列表"或起草披露清单时使用。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | material-contract-schedule |
| description | 从尽调发现构建重大合同披露清单，适用股权收购协议的重大合同定义，并按 协议清单格式排版。当用户说"建合同清单""披露清单""清单 3.X" "重大合同列表"或起草披露清单时使用。 |
| argument-hint | [股权收购协议路径，或粘贴重大合同定义] |
事项上下文。 检查实务级 CLAUDE.md 中的 ## 事项工作区。如果 Enabled 为 ✗（企业法务用户的默认值），跳过本段其余内容——技能使用实务级上下文，事项机制不可见。如果已启用且无活跃事项，询问："这是哪个事项？运行 /corporate-legal:matter-workspace switch <事项简称> 或说 实务级。"加载活跃事项的 matter.md 获取事项特定上下文和覆盖规则。输出写入事项文件夹 ~/.claude/plugins/config/claude-for-legal/corporate-legal/matters/<事项简称>/。除非 跨事项上下文 为 开，否则绝不读取其他事项的文件。
股权收购协议中有一项陈述与保证："清单 3.X 列明了所有重大合同。"本技能从尽调发现中构建该清单——哪些合同在协议定义下属于重大合同，并以协议要求的格式呈现。
~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md → 重要性阈值（可能与协议定义不同——以协议为准）diligence-issue-extraction 的尽调发现——合同层面的数据从股权收购协议中提取"重大合同"的定义——以收购协议的定义为准。交易结构差异（股权转让 vs. 资产转让 vs. 合并）会改变各触发条件的解释，而受监管行业的叠加层（医疗、国防、金融服务、电信、政府采购）可能增加收购协议之外的同意要求。如果交易涉及上述任何叠加层，检索适用的反垄断法、外商投资安全审查等规则并引用控制性规定 [yuandian检索]。
收购协议定义中常见的触发条件类别如下——这些不能替代阅读收购协议，以收购协议所列清单为准：
以收购协议的定义为检验标准。机械适用——满足收购协议定义中任何一项条件的合同均列入清单。
对尽调中已审阅的每份合同：
| 合同 | 满足条件 | 是否列入 |
|---|---|---|
| [名称] | [年度金额≥X元；含控制权变更条款] | 是 |
| [名称] | [无] | 否 |
需标记由人工判断的边界情形：
对每份列入的合同，清单通常需要：
| 字段 | 来源 |
|---|---|
| 对方当事人名称 | 合同 |
| 合同标题/类型 | 合同 |
| 日期 | 合同 |
| 期限/到期日 | 合同 |
| 年度/总金额 | 合同或管理层数据 |
| 满足哪项重大性条件 | 第2步分析 |
| 交易是否需要对方同意 | 尽调发现 |
| 数据室索引 | 尽调目录 |
从已有的尽调提取中获取。如有字段缺失，标记——不要推测。
披露清单有格式要求——通常为编号列表或表格，有时按合同类型分项。与草案协议中其他清单的格式保持一致。
## 清单 3.[X] — 重大合同
截至签署日，重大合同如下：
### (a) 客户合同
1. [协议标题]，签署日期[日期]，由[目标公司]与[对方当事人]之间订立。
[如格式要求附简述，则添加。]
[数据室：路径]
2. [...]
### (b) 供应商合同
[...]
### (c) 不动产
[...]
[等等——分项按协议的定义结构编排]
单独追踪（不在清单本身中——这是内部用的）哪些已列入的合同需要取得同意。
同意事项叠加层及交付前的任何工作草案来源于受特权保护的尽调材料，并继承其特权和保密状态——向特权保护圈之外分发可能放弃特权。清单本身一旦作为已签署收购协议的附件交付，即为交易文件，不受特权保护；交付前应去除所有内部注释。
| 清单编号 | 对方当事人 | 是否需要同意 | 状态 | 负责人 | 截止日期 |
|---|---|---|---|---|---|
| 3.X(a)(1) | [名称] | 是 — 控制权变更 §12.2 | 已请求 | [姓名] | [日期] |
此项馈入交割检查表。
交付前：
按系统逐一定义AI角色、风险等级和监管义务——判定每个系统是 AI服务提供者还是使用者，分配风险层级，并映射至中国AI法规 的义务要求。适用于建立AI系统清单、进行年度AI审计、或新法 规要求重新分类时。
为AI系统或模型生成风险定级和合规概要评估——涵盖数据、公平性、 透明度、安全性和监管注册表。在用例分类为"附条件-高"后使用， 产品或工程团队提出"我们需要做AI影响评估"时使用，或定期重新 认证已部署系统时使用。采用快速/全面双轨制。
首次运行访谈以建立AI治理实践配置：适用法规、 AI系统清单、红线、审批工作流和输出偏好。 在插件首次安装时自动运行。使用 --redo 可重新运行。
将新的或修订的AI法规与当前AI政策和实践进行差异分析—— 输出差距清单和整改计划，含负责人和日期。适用于新法规 出台、用户询问"[某法规]是否影响我们"、" AI法规差距分析"或粘贴法规文本时。
对提议的AI用例进行分类和风险排序：检索现有注册表、检查红线、 对残余风险进行分级。输出为经核准/附条件/不核准，并附书面理由。 适用于收到新的AI用例提案、产品团队询问"这个AI功能可以上线吗"、 或需要运行AI用例审批委员会流程时。
审查AI供应商条款——重点核查训练数据来源合规性、责任分配、 模型变更通知、合规义务向下传导。适用于审查AI SaaS协议、 AI模型授权、AI API服务条款，或采购团队提出"这个AI供应商 合同有问题吗"时使用。