Vendor Agreement Review

Vendor Agreement Review

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 /commercial-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/commercial-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Destination check

Before producing output, check where it's going. If the user has named a destination (a channel, a distribution list, a counterparty, "everyone"), ask whether it's inside the privilege circle. Public channels, company-wide lists, counterparty/opposing counsel, vendors, and clients (for work product) waive the protection. When the destination looks outside the circle, flag it and offer (a) the privileged version for legal only, (b) a sanitized version for the broader channel, or (c) both — don't silently apply a privileged header and then help paste it somewhere the header won't protect it. See the canonical ## Shared guardrails → Destination check in this plugin's CLAUDE.md.

Purpose

Read a vendor agreement against the playbook this team actually uses (in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md), find every term that deviates, and tell the lawyer what to do about each one — with specific redline language, not vague "consider revising."

The output is a review memo the lawyer can act on in one pass. Every issue has a severity, a business-impact explanation, a proposed fix, and an escalation call if one is needed.

Precondition: load the playbook

Before reading the contract, read ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. If it's missing or still has placeholders, surface this bounce:

I notice you haven't configured your practice profile yet — that's how I tailor playbook positions, escalation, and house style to your practice.

Two choices:

• Run /commercial-legal:cold-start-interview (2 minutes) to configure your profile, then I'll review tailored to YOUR playbook.
• Say "provisional" and I'll review against generic defaults — US jurisdiction, middle risk appetite, lawyer role, no playbook (flag all common vendor-contract risks from first principles) — and tag every output [PROVISIONAL — configure your profile for tailored output] so you can see what I do before committing.

Provisional mode

If the user says "provisional," run the review normally using these generic defaults: middle risk appetite, lawyer role, US jurisdiction, no playbook (flag the common vendor-side risks from first principles — unlimited liability, no data-breach carveout, uncapped indemnity, auto-renewal without notice, etc. — rather than matching to configured positions). Tag the reviewer note and every finding block with [PROVISIONAL]. At the end of the output, append:

"That was a generic run against default assumptions. Run /commercial-legal:cold-start-interview to get output calibrated to YOUR practice — your playbook, your jurisdiction, your risk appetite. 2 minutes."

Which side? Before applying the playbook, determine which side the company is on for this contract. Usually obvious: if the counterparty is a vendor/supplier providing goods or services, you're purchasing-side. If the counterparty is a customer buying your product/service, you're sales-side. If it's not obvious (a reseller agreement, a partnership, a revenue share), ask: "Which side is [company] on for this agreement — vendor or customer?" Read the matching playbook section (### Sales-side playbook or ### Purchasing-side playbook) from the config. Note which side in the output so the reviewer knows which playbook was applied. If the matching side is [Not configured], stop and tell the user to run /commercial-legal:cold-start-interview --side <side> before this review can proceed.

This skill is typically used for purchasing-side contracts (vendors supplying you), but the side check still applies — a "vendor agreement" could be your own template sent to a vendor as part of a reseller arrangement (sales-side).

The playbook in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md is the source of truth. It tells you:

• What this team's standard positions are (not market standard — their standard)
• What fallbacks they've accepted before
• What they never accept
• Who approves what
• The one deal-breaker to check first

If the contract has the deal-breaker, flag it at the top of the memo and stop the detailed review. There's no point spending 30 minutes on liability caps if the agreement gives the vendor rights to use customer data for training.

Workflow

Step 1: Orient

Read the whole agreement once, fast. Answer:

Dollar-value handling. If the main agreement does not state a dollar value (the MSA sets terms but the Order Form carries price, which is typical), stop and ask before running escalation math or applying dollar thresholds:

The MSA itself doesn't state an annual contract value. The Order Form carries the price. Your escalation threshold is $[X from the matrix]. Before I route this, I need the ACV. Options:

1. Paste the Order Form value (preferred — I'll use it for routing and the memo).
2. Tell me if this is above or below $[threshold] and I'll route accordingly; the memo will flag that the routing assumed [above/below threshold] without an ACV in hand.
3. Route conservatively to the higher approver regardless — safer for a review you haven't priced.

Do NOT silently assume a value and then use the assumed value to drive routing. The assumption propagates into the approval call, which is a place the review shouldn't be guessing.

DPA-by-reference handling. If the main agreement incorporates a DPA "available at [URL]" or "as set forth at [URL]" or similar by reference, the DPA is part of the contract but is not in front of you. Note it explicitly in the Orient table and in the review memo:

This agreement incorporates a DPA by URL reference at [URL]. The DPA carries the real data terms — subprocessor rights, breach-notification timing, data-return mechanics, standard contractual clauses, audit rights. Without reading it, the data-protection analysis below is partial. Offer to route the DPA to /privacy-legal:dpa-review (if installed) for a separate review, or fetch and read it inline before completing Step 3's data-protection analysis.

If the user is installed with privacy-legal, explicitly offer:

Want me to hand the DPA URL to /privacy-legal:dpa-review once you're ready? That skill is built for the DPA work and will catch subprocessor / SCC / breach-notification issues that this skill only flags at the gate.

Do not silently proceed as if the DPA were absent when it is incorporated by reference. A missing DPA and an unread DPA are different gaps — label them differently.

Step 2: Deal-breaker check

Check the "one thing" from ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md first. If present:

## ⛔ DEAL-BREAKER PRESENT

**Section [X.X]** contains [the deal-breaker]. Per the team playbook, this is a
hard no. Recommend:

- [ ] Push back — propose [specific alternative language]
- [ ] Walk — if counterparty won't move, we don't sign

Detailed review below is provided for completeness but is moot unless this is
resolved.

Step 3: Term-by-term comparison

For each playbook category in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md, find the corresponding contract section and compare.

For each deviation, produce:

### [Section X.X]: [Issue name]

**Playbook says:** [our standard position, quoted from `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md`]

**Contract says:**
> "[exact quote from the contract]"

**Gap:** [Missing term | Weaker than standard | Weaker than fallback | Non-standard structure | Unacceptable]

**Legal risk:** 🔴 Critical | 🟠 High | 🟡 Medium | 🟢 Low
**Business friction:** 🔴 Blocks deals | 🟠 Slows deals | 🟡 Confuses customers | 🟢 Invisible

**Why it matters:** [one or two sentences in plain English — what goes wrong
for the business if this term stays as-is]

**Proposed redline:**
> "[the specific replacement language — ready to paste into a markup]"

**If they won't move:** [the fallback from `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md`, or "escalate to [person]"
if no fallback exists]

Severity calibration:

Severity is always applied against ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. If a term doesn't map cleanly to a playbook position, ask the user which bucket it belongs in and offer to record the answer in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md.

Liability cap decision procedure

The cap amount is the least important part of the cap. When reviewing the limitation-of-liability clause, do not produce a single "check liability cap against playbook" line item. Work through the four dimensions below and state each one explicitly in the finding:

1. Direct vs. indirect/consequential damages. Does the cap apply to ALL liability, or only direct damages? A 12-month cap on direct damages with uncapped consequential damages is a completely different position than a 12-month aggregate cap. State both treatments explicitly.

2. The cap base — quote it verbatim. "12-month cap" could mean: (a) fees paid in the 12 months preceding the claim, (b) fees payable in the current 12-month period, (c) fees over the last 12 months of usage, (d) fees under the current order form, (e) total fees ever paid. These can differ by an order of magnitude. Quote the exact language. If ambiguous, flag it: "Cap base is ambiguous — [the quoted language] — could mean [X] or [Y]. Confirm before signing."

3. Cap-carveout interaction. A $100K cap with uncapped indemnity for data breach, IP, and confidentiality is functionally uncapped for the claims that actually arise in SaaS disputes. Enumerate what sits ABOVE the cap (the carveouts), what sits BELOW (what's actually capped), and assess whether the capped surface is meaningful: "The cap covers [general contract breach]. Data breach, IP indemnity, and confidentiality are carved out and uncapped. For this vendor's risk profile, the capped surface is [meaningful / nominal]."

4. Your playbook position per dimension. The practice profile should have positions for: direct cap (multiple of fees), indirect damages (excluded / capped / uncapped), carveout list (what's acceptable above the cap), and cap base (which definition you'll accept). If the playbook has one "standard position" field, note: "Your playbook has a single cap position — consider splitting into direct/indirect/carveouts/base for more precise review."

Jurisdiction delta check

The playbook applies one governing-law preference globally. Enforceability varies materially. Check the contract's actual governing law against the top divergences before accepting playbook positions at face value:

• Non-solicits/non-competes: Unenforceable in CA (Bus. & Prof. Code §16600). Restricted in many EU jurisdictions. Enforceable with limitations elsewhere. [jurisdiction — verify]
• Auto-renewal: CA GBL §17600-17606, NY GBL §527-a, IL 815 ILCS 601 have specific consumer/B2B notice requirements. Other states vary. [jurisdiction — verify]
• Liability exclusions: EU and UK unfair contract terms rules (UCTA 1977, Consumer Rights Act 2015) constrain consumer exclusions. Some US states limit exclusion of gross negligence or willful misconduct. [jurisdiction — verify]
• Indemnification: Some states void indemnification for the indemnitee's own negligence. [jurisdiction — verify]
• Confidentiality term: Some jurisdictions limit "perpetual" confidentiality to a reasonable period. [jurisdiction — verify]

When the playbook position conflicts with the contract's governing-law enforceability, flag: "Your playbook prefers [X], but this contract is governed by [Y] law where [X] is [unenforceable / restricted / subject to statutory override]. [jurisdiction — verify]"