Tabular review 是一个法律尽调导向的表格化文档审查技能，来自 anthropics/claude-for-legal。它的核心场景是：你手上有一大堆文档，以及一组需要在每份文档上一致回答的问题，例如尽调请求清单、供应商合同审计或租约组合审查。输出是一张表——文档为行，数据点为列，每个单元格都能追溯到源文档的准确原文。
用途与定位 该技能不用于发现问题（issue spotting）；发现 2000 份文档中隐藏的 30 个问题由 diligence-issue-extraction 负责，而 tabular review 是对全部 2000 份文档回答同样的 15 个问题。它也不替代人工阅读文档：它产出的每个单元格都是需要核验的线索，而不是结论；输出设计目标是让核验更快，而不是跳过核验。
列的类型系统 表格化的关键在于第 C 列在第 1 行与第 200 行含义一致，因此每列都有约束答案格式的类型：
- verbatim：逐字引用，字符级复制，用于定义术语、操作性条款语言等措辞重要的内容。
- classify：从你定义的固定列表中选择一个值，如 Yes/No、present/absent、条款变体。
- date：ISO 日期，如生效日期、到期日、终止通知截止日。
- duration：数字加单位，如期限长度、通知期、存续期。
- currency：数字加货币代码，如上限、阈值、费用、购买价引用。
- number：纯数字，如计数、百分比、页码。
- free：简短自由文本摘要，尽量少用，因为它容易漂移。
逐字规则：每个非 verbatim 列也要附带支撑答案的原文引用作为伴随字段。单元格中的答案是解释，引用是证据。例如 classify 单元格写“consent not unreasonably withheld”却没有出处句子就没有用，因为审查者需要判断这个解读是否正确。
“未找到”的三种状态 空白单元格会隐藏信息，因此无法给出肯定答案时必须强制进入三种明确状态之一：
- not_present：文档已读，条款不存在，且确信主题未被涉及。
- unclear：有相关内容但无法有把握地分类，如起草模糊、条款不完整、条款冲突。
- needs_review：找到了内容但必须由人判断，如边缘情况、不寻常起草、答案依赖 schema 未覆盖的判断。 这三者是三种不同信息：交易团队处理“合同对转让保持沉默”与“转让条款有歧义”的方式完全不同。
工作流程 Step 0：确认对象与位置。确认文档在哪里（VDR MCP 如 Box、Datasite、iManage，本地文件夹，Google Drive 文件夹，或文件列表）以及数量；超过 200 份会提示耗时并建议先做重要性过滤子集。确认 schema 来源（references/ 中的模板，默认 M&A 尽调标准，或用户自然语言描述后结构化）。确认输出（Excel 或 Google Sheets，CSV 与 Markdown 始终作为兜底）。 Step 1：构建并确认 schema。为每列定义稳定 id、人类标签、类型、prompt，classify 列还要有选项列表；写入 .review-schema.yaml 作为可复用工件。 Step 2：抽样试跑。不要用未测试的 schema 直接跑 200 份文档；先跑 3–5 份，观察是否存在大量 unclear、答案不匹配选项、verbatim 列返回改写等问题，调整后重跑样本并确认。 Step 3：分发。每份文档一个子代理并行执行，读取整份文档（不是 RAG 分块），为每列返回 {value, state, quote, location}。state 为 answered | not_present | unclear | needs_review。quote 必须是源文档中连续文本的字符级复制，可定位；不能拼接标题与样板、不能改写、不能凭常见条款记忆重建、不能用省略号跨非连续文本拼接。无法定位或复制精确文本时，state 为 needs_review、value 为 null，并在 notes 中写 quote_unavailable: <原因>。 Step 4：归一化。按列通读整张表。对 classify 列检查答案是否在选项内，异常值重新分类或升级为 needs_review；观察聚类（如 180 份 consent_required、20 份 consent_not_unreasonably_withheld 可能是真的；195 对 5 则需要检查那 5 份）。对 date/duration/currency 列检查格式一致性、归一化，并把不合理值（99 年期限、1 美元上限）标记为 needs_review。对 verbatim 列及其他列的伴随引用做抽查：按列随机抽取至少 3–5 行或 10% 行（取较大者），回源文档按引用位置逐字符比对。若发现引用为拼接、改写、重建或无法定位，将该单元格降级为 needs_review 并在 notes 中记 quote_mismatch，同时标记整列并扩大抽查范围。 Step 5：输出。始终写 Markdown（便于会话内查看）与 CSV；CSV 分为值文件和 _sources.csv 伴随文件，保持主文件干净且证据链完整。Excel 或 Google Sheets 由用户选择，不猜测。表格结构包括：每个数据列配对隐藏的来源列（包含引用与位置），可见列上的单元格批注（Excel）或备注（Sheets）在悬停时显示引用；按状态着色（白=answered，黄=unclear/needs_review，灰=not_present）；每个数据列配一个默认空白的 Verified 列供审查者标记，形成可审计的核验/标记模式；一个 _schema 工作表记录列定义，使文件自解释。顶部加入插件配置中的 work-product 头部，并附分发说明：该审查源自可能受特权或保密保护的文档，继承其特权与保密状态，向特权圈外分发可能导致特权弃权，应存于案件的受特权文件中并审慎决定分发。Excel 可用 Claude in Excel（Office agent），否则用 openpyxl 兜底；Sheets 可用 Sheets MCP、Sheets API via ADC，或 CSV 导入兜底。 Step 6：总结。给出单屏读数：文档数、列数、已完成行数；每列 not_present、unclear、needs_review 数量（即核验工作量）；归一化中超过 10% 行被标记的列；输出文件位置；并提醒每个单元格都是线索而非结论，须核验后才能用于陈述、附表或备忘录。最后按 CLAUDE.md 的下一步决策树收尾，五个默认分支（起草 X、上报、获取更多事实、观察等待、其他）是起点而非锁定，决策树是输出，由律师选择。
该技能不做什么 不替代阅读文档，只告诉你该看哪里；不产出置信分数（0.73 不是信息，unclear/needs_review 状态与逐字引用才是置信信号）；不静默跳过文档（用户指向的每份文档都有一行，无法读取的文档得到一行 needs_review 加备注）；不把改写当引用，证据链是全部意义所在。
与其他技能的关系 diligence-issue-extraction 找问题，本技能提取数据点；如果提取中发现 MAC 条款引用特定盈利目标或毒丸等，应记录并建议对那份文档运行 diligence-issue-extraction。material-contract-schedule 构建特定的披露附表，可直接消费本技能输出，附表是表格化审查的过滤并重排视图。ai-tool-handoff 在语料过大或团队偏好专用平台时把批量审查交给 Luminance/Kira；本技能是内部选项，能处理的部分先跑，剩余部分再交接。
输出保障 每个输出都有 work-product 头部；每个单元格都有来源引用或标记状态；总结明确说明需要核验；Excel 的 Verified 列把核验状态变成可审计记录。