/tabular-review

name: tabular-review
description: >
  Tabular review — one row per document, one column per data point, every cell
  cited to source. Built for M&A diligence ("review these 200 target contracts
  for change-of-control, assignment, and MAC clauses") but works for any batch
  review that needs a spreadsheet out the other end. Use when user says "tabular
  review", "review grid", "build a grid", "extract these fields from these
  contracts", "review these documents for X, Y, Z", "give me a spreadsheet of",
  "batch review", or points at a folder of documents and asks to compare them.

/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:

| Type | What it returns | Use for | |---|---|---| | `verbatim` | Exact quote from the document, character-for-character | Defined terms, operative clause language, anything where the words matter | | `classify` | One value from a fixed list you define | Yes/No, present/absent, clause variants (e.g., "sole consent" / "consent not unreasonably withheld" / "silent") | | `date` | ISO date | Effective date, expiration, termination notice deadline | | `duration` | Number + unit | Term length, notice period, survival period | | `currency` | Number + currency code | Caps, thresholds, fees, purchase price references | | `number` | Bare number | Counts, percentages, page references | | `free` | Short free text summary | Use sparingly — this is the type that drifts. Only when the others genuinely don't fit. |

**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:

| State | Meaning | When to use | |---|---|---| | `not_present` | The document was read and the clause is not there | You are confident the subject matter isn't addressed | | `unclear` | Something is there but you can't classify it confidently | Ambiguous drafting, partial clause, conflicting provisions | | `needs_review` | You found something but a human must make the call | Edge case, unusual drafting, the answer depends on a judgment the schema doesn't capture |

These are three different pieces of information. A deal team handles "the contract is silent