tabular-review

/tabular-review

1. Load ~/.claude/plugins/config/uk-legal-plugins/corporate-legal-uk/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. Normalisation 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-uk:tabular-review
/corporate-legal-uk:tabular-review --schema .review-schema.yaml --docs ./vdr/02-Contracts/
/corporate-legal-uk:tabular-review --template ma-diligence-uk

--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-uk.

--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-uk: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/uk-legal-plugins/corporate-legal-uk/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/uk-legal-plugins/corporate-legal-uk/CLAUDE.md → diligence structure, materiality thresholds, house format preferences
• ~/.claude/plugins/config/uk-legal-plugins/corporate-legal-uk/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 (GBP default for UK contracts)	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 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 UK 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. Show it to the user and confirm before fanning out.

schema:
  name: "M&A Diligence — Project [Code] (UK)"
  created: 2026-05-18
  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, counterparty_right_to_terminate]
      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?"
    - id: governing_law
      label: "Governing Law"
      type: verbatim
      prompt: "What jurisdiction's law governs? (English / Scots / NI / other)"
    # ... 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. Do NOT paraphrase and call it verbatim. Do NOT reconstruct a quote from memory of how such clauses "usually" read.
• The location must be specific enough for the normalisation pass to re-open the document and re-read the same span.
• If the sub-agent cannot locate and copy the exact text, 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 normalisation 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.

Step 4: Normalise

After the fan-out, read the whole table column by column.

For each classify column:

• Check that every answered value is in the options list. Outliers get re-classified or bumped to needs_review.
• Check for clusters: if 180 documents say consent_required and 20 say consent_not_unreasonably_withheld, that's probably real. If 195 say consent_required and 5 say freely_assignable, look at the 5.

For each date / duration / currency column:

• Check format consistency. Normalise. Default currency: GBP unless document specifies otherwise.
• Flag implausible values (a 99-year term, a £1 cap) as needs_review.

For each verbatim column AND for the companion source quotes on every other column:

• Spot-check by re-opening the source document at the cited location for a random sample (at least 3–5 rows per column, or 10% of rows, whichever is larger) and comparing the stored quote character-for-character against the source.
• If any quote is composed, paraphrased, or reconstructed: downgrade that cell to needs_review with quote_mismatch in notes, and flag the whole column.

Step 5: Output

Write the table in three formats:

Markdown (always, for in-session review):

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

CSV (.csv, always): One file for the values, one companion file for the quotes and locations (_sources.csv).

Excel (.xlsx) or Google Sheets — whichever the user works in. Ask; don't guess. Both follow the same workbook structure (see references/excel-output.md and references/gsheets-output.md). In the spreadsheet output:

• Each data column is paired with a hidden source column containing the quote and location. Cell comments (Excel) or notes (Sheets) on the visible column surface the quote on hover.
• Colour code by state: white = answered, yellow = unclear or needs_review, gray = not_present.
• A Verified column per data column, blank by default. The reviewer marks it.
• A _schema sheet with the column definitions, so the file is self-documenting.

Prepend the work-product header from the plugin config ## Outputs as a top row. Alongside it, include a distribution note:

This review is derived from source documents that may be privileged, confidential, or both. In England & Wales, legal professional privilege in relation to this document depends on whether it was prepared at the direction of a solicitor for the purpose of giving or receiving legal advice or in contemplation of litigation. Distribution beyond the privilege circle can waive LPP. Store with the matter's privileged files and make distribution decisions deliberately.

Step 6: Summary

After the table is written, give the user a one-screen readout:

• Document count, column count, rows completed
• Count of not_present, unclear, needs_review per column — this is the verification workload
• Any columns where the normalisation pass flagged >10% of rows
• Where the output files are
• A reminder: every cell is a lead, not a finding. Verification required before this informs a warranty, a schedule, or a memo.

Close with the next-steps decision tree

End with the next-steps decision tree per CLAUDE.md ## Outputs. The tree is the output; the lawyer picks.

What this skill does not do

• It does not replace reading the documents. It tells you where to look.
• It does not produce confidence scores. The unclear / needs_review states and the verbatim quotes are the confidence signal.
• It does not silently skip documents. Every document the user pointed at gets a row.
• It does not pretend a paraphrase is a quote. The evidence trail is the whole point.

Relationship to other skills

• diligence-issue-extraction finds issues; this extracts data points.
• material-contract-schedule builds one specific table (the disclosure schedule). It can consume this skill's output directly.
• ai-tool-handoff hands bulk review to Luminance/Kira when the corpus is too large.

Output safeguards

Every output gets the work-product header. Every cell gets a source citation or a flagged state. The summary explicitly says verification is required. The Excel Verified column makes the verification state auditable. This is not a tool that lets you skip reading; it's a tool that makes reading faster.