Verified against Gemini · 2026-07-21
Diff a redlined contract against the original and flag every substantive change
A long-context prompt that loads both the original and the redlined version of a contract into the same window and returns a change-by-change risk analysis, instead of a generic first read that misses a clause quietly weakened somewhere the visible tracked-changes markup doesn't draw the eye.
The prompt
Ready to copy — highlighted parts are example details you can swap.
I'm giving you two versions of the same contract: the original and a redlined counter-proposal. Read both in full before comparing anything — don't review the redline in isolation from what it's actually changing. ORIGINAL Full text of the SaaS Master Services Agreement, original signed version. REDLINED COUNTER-PROPOSAL Full text of the vendor's returned MSA with tracked-changes markup. CONTRACT CONTEXT This is a 2-year SaaS vendor Master Services Agreement. We are the customer, not the vendor. WHAT COUNTS AS SUBSTANTIVE Ignore pure formatting, renumbering, or wording changes that don't alter meaning or obligation — flooding the output with those is worse than useless, it buries the changes that actually matter. Ignore any change that is purely a section renumbering caused by an earlier deleted clause. INSTRUCTIONS 1. Go clause by clause. For every substantive change, quote the original wording and the new wording side by side, not just a paraphrase of what changed. 2. Classify each change into exactly one of: increases our obligation, reduces our protection, shifts cost to us, ambiguous/needs clarification, or favorable to us. 3. Cross-reference: if a change in one clause has a knock-on effect on another clause elsewhere in the document (a shortened notice period in §3 that makes a termination right in §9 harder to exercise in practice), name that connection explicitly — a change that looks small in isolation can be the one that matters most once you see what else it touches. 4. State plainly which of our known priorities this touches: payment terms and data-deletion timelines are non-negotiable for us; most other terms are open to discussion 5. This is a first-pass flag list to prepare for actual legal review, not legal advice itself — say so at the top of your output, and don't present any classification as a final legal determination. DEFINED TERMS If a redlined change modifies a defined term (a capitalized term with its own definition clause), search the rest of the redlined document for every other place that term is used and check whether the change to its definition actually alters what any of those other clauses now mean in practice — a definition change that looks narrow in isolation can quietly widen or narrow an obligation stated three sections away, and that connection is easy to miss unless you deliberately trace it. CHANGES THAT WORK TOGETHER Some redlines are only risky in combination — a shortened cure period paired with a broadened definition of what counts as a breach, for instance, is materially riskier than either change would be alone. Call out any pair or group of changes that compound each other's effect, not just each one individually. IF NOTHING SUBSTANTIVE CHANGED IN A SECTION Say so plainly rather than manufacturing a finding to fill out the output — a clause with no substantive redline doesn't need an entry just because every other clause got one; only flag sections that actually changed in a way that matters. OUTPUT FORMAT grouped by contract section, most risky classification first within each section. For each flagged change: clause reference, original vs. new wording, classification, and a one-line plain-English explanation of the practical effect. Follow the main list with a short section on compounding changes that only matter in combination, and end with a short list of changes you could not confidently classify and why, so a human reviewer knows exactly where to focus first.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Holding both the full original and the full redlined document in the same context window is what makes a genuine clause-by-clause diff possible — reviewing the redline alone, even with its own tracked-changes markup, only shows what the counterparty chose to visibly mark, and a party revising a contract in their own favor doesn't always mark every place a definition or a cross-reference elsewhere quietly shifts in meaning as a result. Asking for the original and new wording quoted side by side, rather than a paraphrase of the change, keeps every flagged item checkable against the actual contract text instead of trusting a summary of a summary. The cross-reference instruction targets the single most expensive kind of miss in contract review: a change that looks minor read in isolation — a shortened notice period, a redefinition of a defined term used elsewhere — but that quietly guts a separate clause's practical value once you trace where else that term or number is used, which is exactly the kind of connection a clause-by-clause read easily misses and a full-document long-context read is positioned to catch. Naming the specific known priorities up front changes what counts as a flag at all, not just how it's phrased — a clause a generic reviewer might rate as low-risk can be the single most important line item if it touches the one term your side has already decided is non-negotiable, and a model with no visibility into that priority has no way to weight it correctly on its own. The explicit not-legal-advice framing matters because a fluent, confidently classified risk table reads as more authoritative than it should be treated as — this output is meant to focus what a human (ideally counsel) looks at closely, not to replace that review. The instruction to trace a changed defined term through every other clause that uses it, rather than reviewing each redline where it visually appears, addresses a mechanic specific to how contracts are actually written: a definition clause is usually one short paragraph, but its effect is distributed across every place the defined term is later invoked, so a model reviewing redlines clause by clause in isolation will correctly flag the definition change itself while missing that it silently altered the meaning of an obligation stated four sections later that was never itself redlined. Calling out compounding changes separately from individual ones matters because risk in a negotiated contract is rarely additive — two moderate changes that interact can be materially more dangerous together than either reads in isolation, and a flat list that scores each change independently has no mechanism for surfacing that interaction at all.
What you get back
§4.2 (Payment terms): Original — "Net 45 from invoice date." Redlined — "Net 15 from invoice date." Classification: shifts cost to us (working capital impact). Touches known priority: payment terms. §9.1 (Termination): Original — "either party may terminate with 90 days' written notice." Redlined — "either party may terminate with 30 days' written notice, provided all fees for the then-current term have been paid in full." Classification: ambiguous/needs clarification — the added payment condition could effectively block termination if a dispute over fees is unresolved at notice time; cross-references the payment-terms change above. Could not confidently classify: the revised definition of "Confidential Information" in §1.3 narrows the category, but it's unclear without seeing how the term is used downstream in §11 whether this favors or disadvantages us on balance.
Verified against
Gemini Gemini 3 Pro · 2026-07-21
Changelog
- 2026-07-21 — Initial publish, verified against Gemini 3 Pro on a redlined SaaS MSA counter-proposal.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
