legal-due-diligence git:20260901.1936886B

Immutable. This exact content is served forever at /api/v1/blob/32aaf35cffcb33b8.

---
name: legal-due-diligence
license: Apache-2.0 (adapted from anthropics/claude-for-legal, corporate-legal/skills/tabular-review + corporate-legal/skills/diligence-issue-extraction; complete terms in LICENSE.txt)
description:
  对一批交易/尽调文档做结构化法律尽调：表格式逐份提取字段，或按类别扫描问题。
  每一条结论都标注原文逐字引用和定位，杜绝凭印象复述条款。Use when 用户说
  "帮我做一下尽调""审查这批合同看有没有问题""从这些文件里提取变更控制/转让限制
  条款""给我一张尽调表格""批量审查这些文档""这批材料里有什么问题"等。单份合同
  审查用 `contract-review`；单一争议的论证构建用 `legal-reasoning`。
metadata:
  origin: 字段类型系统、三态"未找到"规则、逐字引用铁律、问题类别清单、严重度分级，
    改编自 anthropics/claude-for-legal 的 corporate-legal/skills/tabular-review 与
    corporate-legal/skills/diligence-issue-extraction（Apache-2.0）；已移除该项目的
    VDR MCP 连接器（Box/Datasite/iManage）、matter-workspace 多矩阵项目管理、
    Office/Sheets 云端集成、律所"house format"配置层，改为读本地文件、顺序逐份处理、
    输出 markdown/csv 的独立方法论
---

# Skill: legal-due-diligence

面对一批文档（合同、公司档案、诉讼记录等）需要系统性审查时，有两种互补的做法：

- **表格式（tabular）**：同样一组字段问遍每一份文档，产出一行一文档、一列一
  字段的表格。适合"这 50 份合同里，变更控制条款分别怎么约定的"。
- **问题提取式（issue extraction）**：按标准类别清单扫描，只把真正有问题的
  文档挑出来写成发现清单。适合"这批材料里有没有埋雷"。

两者可以先后使用：先跑表格式摸清全貌，再对表格里标红/标黄的行做问题提取式深挖。

**这不是替代人工阅读文档。** 每一格/每一条结论都是"线索"，需要人工核实，不是
"定论"。这个技能的目标是让核实变快，不是让核实变得可以跳过。

## 处理规模的现实约束

当前 profile 没有配置并行子代理（sub_agent），本技能按文档**顺序**逐份处理，
不做原始方法论里"每份文档一个并行子代理"的 fan-out。文档量较大（50+）时提前
告知用户这会比较耗时，并建议先用小样本（3-5 份）跑通字段定义再处理全量，避免
字段定义有问题却已经审完几十份文档。

## 逐字引用铁律

这是整个技能最重要的纪律，不是可选项：

**每一条结论（不管是表格里的一个格，还是问题清单里的一条发现）必须配一段来自
原文、逐字复制的引用，以及能让人重新定位到原文的位置信息（章节号/条款号/页码，
文档给了什么就用什么）。**

- 不能把一个标题加常见样板文字拼成"引用"。
- 不能改写后当作逐字引用。
- 不能凭"这类条款通常怎么写"的印象复原一段引用。
- 找不到原文、定位不到，就把这一条标记为"待核实"（见下面的三态规则），value
  留空，并在备注里写清楚原因（文档截断、扫描件识别不清、条款隐含但没写明、
  只看到标题没看到正文等）。绝不能为了让格子显得"已完成"而编一个引用。

这条纪律同样适用于所有字段类型的"配套原文引用"，不只是"逐字类"字段本身——
一个分类判断（比如"需经同意"）如果配的引用是编的，比留空更危险，因为它看起来
更完整、更容易被直接采信。

## 三态"未找到"规则

一个空格子会掩盖信息。凡是给不出正面答案的情况，强制归入以下三种明确状态之一：

| 状态 | 含义 | 使用场景 |
|---|---|---|
| `未涉及` | 读过文档，确认没有这条约定 | 有把握该主题文档确实没提 |
| `不确定` | 文档里有相关内容，但无法确信地分类 | 措辞含糊、条款不完整、内容自相矛盾 |
| `待人工判断` | 找到了内容，但需要人判断怎么归类 | 边缘情形、罕见措辞、答案取决于字段定义没覆盖的判断 |

"合同对此完全没有约定"和"约定含糊看不清楚"是团队会用完全不同方式处理的两种
情况，压缩成一个空格子会丢失这个区别。

## 模式一：表格式提取

### 第一步：定义字段和范围

和用户确认：审哪些文档（本地文件/用户粘贴的文本）、要哪些字段、输出放哪里。

把用户的字段描述整理成结构化 schema，每个字段包含：一个稳定的 `id`、一个人类
可读的 `名称`、一个 `类型`、一个 `提示词`（一个真正在读文档的人会问的问题），
`分类`型字段还需要一个 `选项`列表：

| 类型 | 返回什么 | 用于 |
|---|---|---|
| `逐字` | 原文精确引用，一字不改 | 定义性术语、操作性条款原文、任何措辞本身很关键的地方 |
| `分类` | 从你预定义的固定选项里选一个 | 是/否、有/无、条款变体（如"需经同意"/"同意不得无理拒绝"/"未提及"） |
| `日期` | ISO 日期 | 生效日、到期日、终止通知截止日 |
| `期限` | 数字+单位 | 合同期限、通知期、存续期 |
| `金额` | 数字+币种 | 责任上限、门槛、费用 |
| `数字` | 裸数字 | 数量、百分比、页码引用 |
| `自由文本` | 简短自由文本摘要 | 谨慎使用——这是最容易漂移的类型，其他类型确实不合适时才用 |

**逐字引用规则同样适用于非"逐字"类型的字段**：每个非逐字字段都要配一个"支持
原文"作为配套字段。格子里的答案是解读，配套引用是证据——一个写着"同意不得无
理拒绝"的分类结果，没有对应的原文句子支撑就没有意义，因为核实者的工作就是检
查这个解读对不对。

用小样本（3-5 份文档）先跑一遍，检查：某个字段是不是大部分答案都是"不确定"
（说明提示词本身模糊，需要改写）、"分类"字段的答案是不是经常不落在预设选项里
（需要补充选项或改成自由文本）、"逐字"字段是不是经常返回的是改写而非原文（需要
在提示里再强调一次"必须逐字"）。调整后再确认，避免整批跑完才发现字段定义有问题。

### 第二步：逐份处理

按顺序读完整份文档（不是摘录片段），对每个字段找到对应条款，返回：`值`、
`状态`（已回答/未涉及/不确定/待人工判断）、`原文引用`、`位置`。

### 第三步：归一化检查

全部处理完后，按列（而不是按行）通读一遍表格，这一步专门抓"同一类条款在不同
文档里被判断得不一致"这个常见问题：

- `分类`字段：检查所有"已回答"的值是否都落在选项列表里，离群值重新分类或降级
  为"待人工判断"。检查聚类是否合理（比如 180 份都是"需经同意"、20 份是"同意不
  得无理拒绝"大概率是真实分布；195 份"需经同意"、5 份"可自由转让"，这 5 份值得
  重点看看是真的不同还是分类错了）。
- `日期`/`期限`/`金额`字段：格式是否统一，是否有不合理的极端值（99 年期限、
  1 元责任上限）需要标"待人工判断"。
- 所有字段的原文引用：随机抽查（每列至少 3-5 行，或 10% 取较大值），重新打开
  原文核对引用是否逐字一致。发现编造/改写/定位不到原文的引用：把这一格降级为
  "待人工判断"并注明原因，**同时扩大这一整列的抽查范围**——一个子任务在这份
  文档上编了引用，同一列的其他文档也可能有同样问题，不能假设其余的是干净的。
  一个标着"已回答"但引用对不上的格子，比一个"不确定"格子问题更严重，因为它
  歪曲了证据链，要更果断地降级。

### 输出

Markdown 表格（始终输出，便于当场查看）+ CSV（数值文件 + 一份单独的引用/位置
文件，保持主文件干净同时留住证据链）。用户如果需要 Excel 格式，可以另外加载
`office-xlsx` 技能对生成的 CSV 做进一步整理——本技能不直接依赖它。

结尾给一屏摘要：文档数、字段数、完成行数；每列的"未涉及/不确定/待人工判断"
计数（这就是需要人工核实的工作量）；归一化检查标记超过 10% 异常的列；文件在哪；
提醒每一格是线索不是结论。

## 模式二：问题提取式

### 第一步：盘点范围

列出要审的文档来源、大致数量，按类别（重大合同/公司治理/知识产权/劳动/诉讼等）
分组。数量很大时，和用户确认重要性门槛（比如"只审金额超过 X 的合同"），不要在
没有门槛的情况下试图审查全部文档。

### 第二步：按类别标准清单扫描

对读到的每份文档，对照该类别的标准问题清单检查：

**重大合同类：** 变更控制条款（本次交易是否触发？是否需要同意？）、转让限制
（能否随交易转移？）、排他性/竞业限制（是否限制己方未来业务？）、最惠国条款
（价格约束？）、终止权（对方能否因本次交易解约？）、异常的赔偿/责任约定。

**公司治理类：** 股权结构准确性、未行权期权/认股权证、董事会对本次交易的同意
要求、股东协议限制（拖售权/随售权/优先购买权）、子公司架构与关联交易安排。

**知识产权类：** 权属链条是否完整（创始人/员工的转让文件是否齐全）、产品中是
否使用开源代码（copyleft 风险）、关键知识产权是许可还是自有、是否存在待决/
潜在的知识产权诉讼。

**劳动类：** 变更控制触发的遣散/补偿成本、关键员工留任风险、待决劳动争议、
用工性质认定风险（外包/劳务人员实际按员工管理）。

**诉讼类：** 在诉案件及准备金、潜在索赔、监管调查、批量性诉讼（如消费者集体
诉讼）。

### 第三步：陈述每条发现

每条发现附逐字引用（同上面的逐字引用铁律），格式：

```
问题 #N：[标题]
类别：[所属类别]
严重度：[见下方分级]
文档来源：[文件名/位置]
发现：[原文引用 + 为什么这是个问题]
建议：[价格调整/要求赔偿/需要取得同意/尽调保留意见/其他]
```

**严重度分级：**
- 🔴 **高：** 影响交易价值或结构。变更控制需要重要客户同意、未披露的重大诉讼、
  知识产权权属存在缺口。
- 🟡 **中：** 需要处理但可解决。同意大概率能取得、开源代码需要合规整改、用工
  性质认定风险。
- 🟢 **低：** 记录在案。与已披露信息一致，无需额外行动。

**遇到用户或材料里引用的具体法条/规则，如果你没有把握准确复述：** 不要凭印象
描述这条规则大概是什么意思。要么检索确认原文并引用，要么说"这条我没有把握准确
复述，需要核对原文"。一个自信但错误的法条描述比一个"不确定"更危险——前者会被
写进备忘录直接采信。

**检索/技能返回结果不足时不要悄悄补：** 如果某个发现需要援引的规则/原则，检索
结果覆盖不足，明确说出来并给用户选项（换关键词/换信息源/用网络检索但标注
`[网络检索-待核实]`/直接标记未核实并停下），不要用模型记忆填坑。

### 第四步：按类别汇总

按类别分组，组内按严重度排序，附一段"结论先行"（几个 🔴/🟡 分别多少条，最需要
关注的一件事是什么）。

### 输出安全提示

每次输出都提醒：本审查基于抽样/门槛审阅，未必覆盖全部文档；发现的重要性判断
（是否够得上"重大"）由用户/律师最终拍板，本技能只负责按标准套用门槛；输出内容
可能涉及保密信息，分发前请确认对象范围。

## 边界

- 不做"够不够重大"这类边界情形的最终判断——套用门槛，边界情形交给人工判断。
- 不谈判交易条款、不代替律师出具正式尽调报告——产出的是尽调线索清单，供人工
  复核后写入正式文件。
- 单份合同的深度审查用 `contract-review`；单一争议的论证构建用
  `legal-reasoning`；本技能专注"一批文档"的批量场景。