tabular-review

/tabular-review

1. 加载 ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md → 尽调结构、阈值、内部格式。
2. 确认：有哪些文档、需要哪些列、输出放在哪里。
3. 构建类型化架构。编写 .review-schema.yaml。与用户确认。
4. 试运行（3–5 份文档）。调整架构。确认。
5. 并行分派——每份文档由一个子 Agent 处理。每个单元格包含：值 + 状态 + 原文引述 + 位置。
6. 标准化处理。标记异常值和不一致之处。
7. 输出：.xlsx 或 Google Sheets（询问用户选择哪种），并始终提供 .csv + _sources.csv + Markdown。添加工作成果标头。
8. 总结：核验工作量（按列统计 not_present / unclear / needs_review），标记存在问题的列，说明文件所在位置，并提醒用户每个单元格都是线索，而非结论。

/corporate-legal:tabular-review
/corporate-legal:tabular-review --schema .review-schema.yaml --docs ./vdr/02-Contracts/
/corporate-legal:tabular-review --template ma-diligence

--schema <path>： 使用现有架构文件，而非从头构建。适用于重新运行和增量添加。

--template <name>： 从 references/ 中的模板开始。目前有：ma-diligence。

--docs <path>： 文档来源。可以是本地文件夹、Drive 文件夹 ID 或 VDR 路径。若未提供，则询问用户。

--output <xlsx|gsheets|csv>： 输出格式。若未提供，则询问用户。

--sample <n>： 架构检查的抽样数量。默认为 5。

---

事项背景

事项背景。 检查 practice-level CLAUDE.md 中的 ## Matter workspaces。如果 Enabled 为 ✗（in-house 用户的默认设置），则跳过本段其余内容——技能使用 practice-level 上下文，事项处理机制不可见。如果已启用且没有活动事项，则询问：“这属于哪个事项？运行 /corporate-legal:matter-workspace switch <slug>，或输入 practice-level。”加载活动事项的 matter.md，获取事项专属背景和覆盖设置。将输出写入事项文件夹 ~/.claude/plugins/config/claude-for-legal/corporate-legal/matters/<matter-slug>/。除非 Cross-matter context 为 on，否则切勿读取其他事项的文件。

---

用途

你有一批文档，以及一份需要在每份文档中统一回答的问题清单。可以是尽调请求清单、供应商合同审计，也可以是租赁组合审查。输出是一张表：每行对应一份文档，每列对应一个数据点，每个单元格都能追溯到来源中的确切文字。

这不是问题排查。diligence-issue-extraction 会从 2,000 份文档中找出 30 个隐藏的问题。此技能则会针对全部 2,000 份文档回答相同的 15 个问题。两者都有用，但解决的是不同问题。

它也不能替代人工阅读文档。此技能生成的每个单元格都是需要核验的线索，而非结论。输出旨在加快核验，而非省略核验。

加载上下文

• ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md → 尽调结构、重要性阈值、内部格式偏好
• 如果正在处理特定交易，则加载 ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[code]/deal-context.md
• 如果用户已有架构文件，则加载该文件（.review-schema.yaml）

列类型系统

让表格审查有用的关键在于：第 1 行的 C 列和第 200 行的 C 列含义相同。自由文本会逐渐偏离，类型则能保持一致。

每列都有一个类型，用于约束答案格式：

类型	返回内容	适用场景
verbatim	文档中的原文引述，逐字逐字符一致	定义术语、具有约束力的条款措辞，以及任何措辞本身很重要的内容
classify	从你定义的固定列表中选取一个值	是/否、存在/不存在、条款变体（例如“仅需同意”/“不得无理拒绝同意”/“未提及”）
date	ISO 日期	生效日期、到期日期、终止通知截止日期
duration	数字 + 单位	期限、通知期、存续期
currency	数字 + 货币代码	上限、阈值、费用、购买价格相关内容
number	纯数字	数量、百分比、页码引用
free	简短的自由文本摘要	谨慎使用——这种类型最容易偏离。只有其他类型确实不适用时才使用。

**原文引述规则：**每个非 verbatim 列也会捕获支持答案的精确原文引述，作为配套字段。单元格中的答案是解读；引述是证据。classify 单元格若写着“不得无理拒绝同意”，却没有对应的原句，就毫无用处，因为审阅者需要核实这种解读是否正确。

“未找到”的三种状态

空白单元格会隐藏信息。当无法给出肯定答案时，必须明确使用以下三种状态之一：

状态	含义	使用时机
not_present	已阅读文档，但其中没有该条款	你确信文档未涉及此主题
unclear	文档中有相关内容，但你无法有把握地分类	起草内容含糊、条款不完整、规定相互冲突
needs_review	你找到了相关内容，但需要由人工作出判断	边缘情况、特殊起草方式，或答案取决于架构未涵盖的判断

这三种状态代表三种不同的信息。对于“合同未提及转让”和“转让条款含糊”，交易团队的处理方式截然不同。将它们都合并为空白单元格，就会丢失这种区别。

工作流

步骤 0：内容和位置

确认：

1. 文档。 文档在哪里？VDR MCP（Box、Datasite、iManage）、本地文件夹、Google Drive 文件夹，还是文件列表？有多少份？如果超过 200 份，请提醒用户这会耗费一些时间，并提出先从按重要性筛选的子集中开始。
2. 架构。 有哪些列？有两种方式：
   • 用户从 references/ 中选择模板（默认使用 M&A 尽职调查标准模板）
   • 用户用自然语言描述列，由你将其整理成有类型的架构
3. 输出。 使用 Excel（.xlsx）还是 Google Sheets——询问团队使用哪种。始终同时生成 CSV 和 Markdown 作为备用格式。输出保存到交易文件夹、Drive，或用户指定的位置。

步骤 1：构建并确认架构

将用户提供的列清单转换为结构化架构。每列应包含：稳定的 id、便于理解的 label、type、prompt（审阅者阅读文档时会提出的问题），以及 classify 列的 options 列表。

将架构写入输出文件旁边的 .review-schema.yaml。这个文件是可重复使用的产物——用户可以编辑它、添加列，并针对新文档重新运行。将其展示给用户，并在批量处理前确认。

schema:
  name: "M&A Diligence — Project [Code]"
  created: 2026-05-07
  columns:
    - id: counterparty
      label: "Counterparty"
      type: verbatim
      prompt: "Who is the contracting party other than the target?"
    - id: effective_date
      label: "Effective Date"
      type: date
      prompt: "When did the agreement become effective?"
    - id: change_of_control
      label: "Change of Control"
      type: classify
      options: [silent, consent_required, consent_not_unreasonably_withheld, automatic_termination, notice_only]
      prompt: "Does the agreement address a change of control of the target? What does it require?"
    - id: assignment
      label: "Assignment Restrictions"
      type: classify
      options: [silent, consent_required, consent_not_unreasonably_withheld, freely_assignable, assignable_to_affiliates]
      prompt: "Can the target assign this agreement? What restrictions apply?"
    # ... more columns

步骤 2：抽样运行

不要在未经测试的架构上对 200 份文档进行批量处理。先运行 3–5 份文档。向用户展示结果行。检查以下问题：

• 大多数答案都为 unclear 的列——提示词含糊，需要重写
• 答案不符合选项的 classify 列——添加选项，或改为 free
• 返回释义而非原文的 verbatim 列——进一步强调必须逐字逐字符一致

调整架构，重新运行样本并确认。这样可以避免用户必须丢弃完整运行结果。

步骤 3：分派任务

每份文档由一个子 Agent 并行处理。每个子 Agent：

1. 阅读整份文档（不是 RAG 分块，而是完整文档）。
2. 针对每一列，查找相关条款。
3. 返回结构化行：每列包含 {value, state, quote, location}。
   • value 是类型化答案（如果 state 不是 answered，则为 null）
   • state 是 answered | not_present | unclear | needs_review
   • quote 是逐字引用的支持文本（必须精确；不得改写；句子中不得使用省略号；如果截取，须按句子边界截断并标明）
   • location 是引用所在位置（章节编号、标题、页码等，按文档提供的信息填写）

引用不可省略，逐字引用要求是硬性规则，而非倡议。 在返回 state: answered 的单元格之前，每个子 Agent 必须遵守以下所有要求：

• quote 必须是源文档中连续文本的逐字复制，且可在子 Agent 标注的 location 处找到。不要把章节标题与预期会出现的标准条款拼成一段引用。不要将改写内容称为逐字引用。不要根据对此类条款的“通常”表述的记忆还原引用。不要用省略号拼接源文中不连续的文本。
• location 必须足够具体，以便规范化阶段能重新打开文档并重新阅读同一段内容——应提供章节编号、标题或页码等审核者可导航到的位置。
• 如果子 Agent 无法找到并复制确切文本（源文档被截断、OCR 内容错误、条款只是暗示而未明确写出、仅加载了章节标题而未加载正文），则单元格状态为 needs_review，value 为 null，并且 notes 必须包含 quote_unavailable: <原因>。绝不可使用拼接或还原的引用设置 state: answered。
• 同样的规则适用于 verbatim 类型的列，以及附带支持性源文引用的 classify / date / duration / currency / number / free 单元格。支持性引用与单元格值承担同样的逐字引用义务。

步骤 4 的规范化阶段会通过在标注的 location 处重新阅读源文档，并将保存的 quote 与源文逐字比对，进行抽查。如果不匹配，则将单元格降级为 needs_review，在备注中添加 quote_mismatch，并标记整列以进行更大范围的抽查——如果某个子 Agent 拼接了引用，同一轮运行中的其他子 Agent 也可能如此。

第 4 步：规范化

完成分发处理后，按列通读整张表。这一步旨在发现所有表格审查工具都会遇到的问题：同一条款在不同文档中被解释得不一致。

对于每个 classify 列：

• 检查每个 answered 值是否都在选项列表中。异常值应重新分类或改为 needs_review。
• 检查是否存在聚类：如果 180 份文档写的是 consent_required，20 份写的是 consent_not_unreasonably_withheld，这可能是实际情况。如果 195 份写的是 consent_required，5 份写的是 freely_assignable，请检查这 5 份——它们要么确实不同，要么分类有误。

对于每个 date / duration / currency 列：

• 检查格式是否一致，并进行规范化。
• 将不合常理的值（例如 99 年的期限、1 美元的上限）标记为 needs_review。

对于每个 verbatim 列以及其他每一列对应的来源引文：

• 抽取随机样本，通过引用的 location 重新打开来源文档进行抽查（每列至少抽查 3–5 行，或抽查该列行数的 10%，取较大者），并逐字比对存储的 quote 与来源内容。
• 如果任何引文是拼接、转述、重构的，或无法在引用的跨度范围内找到：将该单元格降级为 needs_review，并在备注中写入 quote_mismatch；同时标记整列——将抽查范围扩大到该列其余部分，不要假设其他行都没有问题。有一条伪造引文，就足以证明有必要扩大检查范围。
• state: answered 的单元格若引文不匹配，其严重程度高于 unclear 或 needs_review 单元格——它会歪曲证据链。应积极降级。

第 5 步：输出

以三种格式编写表格：

Markdown（始终提供，用于会话内审查）：

| Document | Counterparty | Effective Date | Change of Control | Assignment | ⚠️ Flags |
|---|---|---|---|---|---|
| Vendor MSA — Acme | Acme Corp | 2023-04-01 | consent_required | consent_required | — |
| Supply Agmt — Beta | Beta LLC | 2021-11-15 | ⚠️ unclear | silent | CoC ambiguous §14.2 |

CSV（.csv，始终提供）： 一个文件存放值，一个配套文件存放引文和位置（_sources.csv）。这样主文件保持整洁，同时证据链完整。

Excel（.xlsx）或 Google Sheets——根据用户使用的工具决定。请询问，不要猜测。两者都遵循相同的工作簿结构（参见 references/excel-output.md 和 references/gsheets-output.md）。对于 Excel：如有可用的 Claude in Excel（Office agent），则使用；否则使用 openpyxl。对于 Sheets：如有可用的 Sheets MCP，则使用；否则通过 ADC 调用 Sheets API，或回退到 CSV 导入。在电子表格输出中：

• 每个数据列都配有一个隐藏的来源列，其中包含引文和位置。在可见列的单元格上悬停时，会显示批注（Excel）或备注（Sheets）中的引文。
• 按状态着色：白色 = answered，黄色 = unclear 或 needs_review，灰色 = not_present。
• 每个数据列都配有一个 Verified 列，默认留空，由审查者填写。这种验证/标记模式使表格可审计——交易团队可以一目了然地看到哪些内容经过了人工核查。
• 设置 _schema 工作表，其中包含列定义，让文件能够自我说明。

在表格顶部添加插件配置 ## Outputs 中的工作成果标题行。并附上以下分发说明：

本次审查基于可能受特权保护、保密或两者兼具的来源文档。本次审查继承来源文档的特权和保密状态——向特权圈子以外分发可能导致特权被放弃。请与该事项受特权保护的文件一同保存，并谨慎决定是否分发。

第 6 步：摘要

写好表格后，向用户提供一屏内可读的摘要：

• 文档数量、列数、已完成的行数
• 每列中 not_present、unclear、needs_review 的数量——这就是待核查的工作量
• 规范化步骤标记出超过 10% 行的列
• 输出文件的位置
• 提醒：每个单元格都只是线索，而非结论。在其内容用于陈述、附表或备忘录之前，必须先行核查。

以“后续步骤决策树”结尾

按照 CLAUDE.md ## Outputs 中的要求，以“后续步骤决策树”结尾。根据本技能刚刚生成的内容定制选项——五个默认分支（起草 X、升级处理、补充事实、观察等待、其他事项）只是起点，并非固定选项。决策树就是输出；由律师做出选择。

本技能不做什么

• 它不能取代阅读文档。 它会告诉你去哪里查找。
• 它不会生成置信度分数。 0.73 不代表任何信息。unclear / needs_review 状态和逐字引文就是置信度信号——如果引文无法支持相应值，请标记出来。
• 它不会悄悄跳过文档。 用户指定的每份文档都要有一行记录。无法读取的文档也要有一行，标记为 needs_review 并附上说明。
• 它不会把释义冒充成引文。 证据链才是重点。

与其他技能的关系

• diligence-issue-extraction 用于发现问题；本技能用于提取数据点。如果提取过程中发现问题（例如引用特定收益目标的 MAC 条款、毒丸条款），请注明，并建议对该文档运行 diligence-issue-extraction。
• material-contract-schedule 用于构建一张特定的表（披露清单）。它可以直接使用本技能的输出——该清单是对表格审阅结果进行筛选和重新排版后的视图。
• 当语料库过大或团队更倾向于使用专用平台时，ai-tool-handoff 会将批量审阅交给 Luminance/Kira。本技能是可自行处理事项的内部方案——先运行本技能，再移交剩余部分。

输出保障措施

每份输出都要包含工作成果标头。每个单元格都要有来源引文或标记状态。摘要必须明确说明需要核实。Excel 中的 Verified 列可让核实状态接受审计。这不是一个让你跳过阅读的工具，而是一个让阅读更快的工具。