Tabular Document Review

/tabular-review

1. Load ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md → diligence structure, thresholds, house format.
2. Confirm: what documents, what columns, where does the output go.
3. Build the typed schema. Write .review-schema.yaml. Confirm with the user.
4. Sample run (3–5 docs). Adjust schema. Confirm.
5. Fan out — one sub-agent per document, parallel. Each cell: value + state + verbatim quote + location.
6. Normalization pass. Flag outliers and inconsistencies.
7. Output: .xlsx or Google Sheets (ask which), plus .csv + _sources.csv + markdown always. Work-product header.
8. Summary: verification workload (counts of not_present / unclear / needs_review per column), flagged columns, where the files are, reminder that every cell is a lead not a finding.

/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>: Use an existing schema file instead of building one. Useful for re-runs and incremental additions.

--template <name>: Start from a template in references/. Currently: ma-diligence.

--docs <path>: Document source. A local folder, a Drive folder ID, or a VDR path. If omitted, asks.

--output <xlsx|gsheets|csv>: Output format. If omitted, asks.

--sample <n>: Sample size for the schema check. Default 5.

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /corporate-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/corporate-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Purpose

You have a pile of documents and a list of questions you need answered consistently across every one. A diligence request list. A vendor contract audit. A lease portfolio review. The output is a table: document rows, data-point columns, and every cell traceable to the exact words in the source.

This is not issue spotting. diligence-issue-extraction finds the 30 problems hiding in 2,000 documents. This skill answers the same 15 questions about all 2,000 documents. Both are legitimate; they answer different questions.

This is also not a replacement for a human reading the document. Every cell this skill produces is a lead that needs verification, not a finding. The output is designed to make verification fast, not to skip it.

Load context

• ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md → diligence structure, materiality thresholds, house format preferences
• ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[code]/deal-context.md if working a specific deal
• An existing schema file if the user has one (.review-schema.yaml)

The column type system

The thing that makes a tabular review useful is that Column C means the same thing in row 1 as in row 200. Free text drifts. Types hold.

Every column has a type that constrains the answer format:

The verbatim rule: Every non-verbatim column also captures the exact source quote that supports the answer, as a companion field. The answer in the cell is the interpretation; the quote is the evidence. A classify cell that says "consent not unreasonably withheld" is useless without the sentence it came from, because the reviewer's job is to check whether that's the right read.

The three states of "not found"

A blank cell hides information. Force one of three explicit states whenever you can't produce a positive answer:

These are three different pieces of information. A deal team handles "the contract is silent on assignment" very differently from "the assignment clause is ambiguous." Collapsing them into one blank cell loses the distinction.

Workflow

Step 0: What and where

Confirm:

1. Documents. Where are they? VDR MCP (Box, Datasite, iManage), local folder, Google Drive folder, or a list of files. How many? If >200, warn that this will take a while and offer to start with a materiality-filtered subset.
2. Schema. What columns? Two paths:
   • User picks a template from references/ (M&A diligence standard is the default)
   • User describes columns in natural language and you structure them into the typed schema
3. Output. Excel (.xlsx) or Google Sheets — ask which the team works in. CSV and markdown always written as fallbacks. Output goes to the deal folder, Drive, or wherever the user says.

Step 1: Build and confirm the schema

Turn the user's column list into a structured schema. For each column: a stable id, a human label, a type, a prompt (the question a reviewer reading the document would ask), and for classify columns an options list.

Write it to .review-schema.yaml next to the output. This file is the reusable artifact — the user can edit it, add a column, re-run against new documents. Show it to the user and confirm before fanning out.

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

Step 2: Sample run

Do not fan out to 200 documents on an untested schema. Run 3–5 documents first. Show the user the rows. Look for:

• Columns where most answers are unclear — the prompt is ambiguous, rewrite it
• classify columns where answers don't fit the options — add options or change to free
• verbatim columns returning paraphrases — reinforce that it must be character-for-character

Adjust the schema, re-run the sample, confirm. This saves the user from a full run that has to be thrown out.

Step 3: Fan out

One sub-agent per document, in parallel. Each sub-agent:

1. Reads the entire document (not a RAG chunk — the whole thing).
2. For each column, finds the relevant provision.
3. Returns a structured row: for each column, {value, state, quote, location}.
   • value is the typed answer (or null if state is not answered)
   • state is answered | not_present | unclear | needs_review
   • quote is the verbatim supporting text (exact, no paraphrase, no ellipsis inside a sentence — if you cut, cut at sentence boundaries and mark it)
   • location is where the quote lives (section number, heading, page — whatever the document gives you)

The quote is not optional, and the verbatim rule is mechanical, not exhortation. Each sub-agent must comply with all of the following before returning a cell with state: answered:

• The quote MUST be a character-for-character copy of contiguous text from the source document, retrievable at the location the sub-agent cites. Do NOT compose a quote from a section heading plus standard boilerplate you expect to be there. Do NOT paraphrase and call it verbatim. Do NOT reconstruct a quote from memory of how such clauses "usually" read. Do NOT fill gaps in the source with ellipsis-stitching across non-contiguous text.
• The location must be specific enough for the normalization pass to re-open the document and re-read the same span — a section number, heading, or page reference the reviewer can navigate to.
• If the sub-agent cannot locate and copy the exact text (source truncated, OCR garbage, provision implied but not written, section heading visible but body not loaded), the cell state is needs_review, the value is null, and notes MUST contain quote_unavailable: <reason>. It is NEVER acceptable to set state: answered with a composed or reconstructed quote.
• The same rule applies to verbatim-typed columns AND to the companion source quotes attached to classify / date / duration / currency / number / free cells. The supporting quote carries the same verbatim obligation as the cell value.

The normalization pass in Step 4 spot-checks this by re-reading the source at the cited location and comparing the stored quote character-for-character against the source text. A mismatch downgrades the cell to needs_review, notes quote_mismatch, and flags the whole column for a wider spot-check — if one sub-agent composed a quote, others in the same run may have too.