Verified against Claude · 2026-07-30
Compare several long documents against each other, not just summarize each one
A structured comparison prompt for feeding Claude several documents at once (proposals, contracts, resumes) and forcing a criteria-by-criteria comparison table instead of separate summaries you have to compare yourself.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You have 4 documents below, each labeled with a name. Your job is to compare them against each other on the criteria listed, not to summarize each one separately — a reader should be able to see how the documents differ at a glance. COMPARISON CRITERIA - Total contract value over 3 years - Termination notice period - Data residency guarantees - SLA uptime commitment - Named support escalation path OUTPUT FORMAT 1. A table: one row per criterion, one column per document, each cell a short factual finding, not a rating like "good" or "poor" unless the criterion is explicitly subjective. 2. Below the table, name the single strongest and single weakest document overall, with the one-sentence reason tied directly to specific rows above — not a new judgment introduced for the first time here. 3. Flag any criterion where a document simply does not address the topic at all, distinct from addressing it poorly — "silent" and "bad" are different findings and must not be merged. CONSTRAINTS - Every cell must be traceable to something actually stated in that document. If you are inferring rather than quoting or closely paraphrasing, mark it "(inferred)". - Do not let document order imply a ranking; the table should let a reader form their own opinion before your part 2 conclusion. DOCUMENTS DOCUMENT: Vendor A Proposal [full text] DOCUMENT: Vendor B Proposal [full text]
Customize the highlighted detailsoptional — the prompt above already works
Why this works
Given several documents and a vague 'compare these' ask, a model will often produce three separate summaries back to back and leave the actual comparing to the reader, because summarizing each document independently is the lower-effort default path through the material. Fixing the output as one table with criteria as rows and documents as columns forces genuine cross-document synthesis: to fill in row 3 across four columns, Claude has to hold all four documents' treatment of that specific criterion in mind simultaneously rather than processing them sequentially and never directly juxtaposing them. Distinguishing 'silent on this topic' from 'addresses it poorly' as separate findings matters in real due-diligence use because these have opposite implications — a contract silent on data residency might mean it is negotiable, while one that addresses it with a bad term is a fixed objection — and a model given no instruction to separate them will default to treating an unaddressed topic as an implicit negative, which is not a safe inference. Requiring an '(inferred)' marker on any cell not directly traceable to the source text is the load-bearing anti-hallucination constraint here: multi-document comparison is exactly the setting where a model under time pressure to fill every cell will confidently invent a plausible-sounding value for a document that simply never mentioned that criterion.
What you get back
A 5-row by 4-column table (one column per vendor), e.g. row "Termination notice period": Vendor A = "60 days (inferred — stated as 'standard notice period' in §9.2, not explicitly 60 days)", Vendor B = "Not addressed in this document", Vendor C = "90 days", Vendor D = "30 days", followed by: "Strongest overall: Vendor D — shortest termination notice and only vendor with a named 24/7 escalation contact (row 5)."
Verified against
Claude Sonnet 4.6 · 2026-07-30
Changelog
- 2026-07-30 — Initial publish, verified against Claude Sonnet 4.6 with a 4-vendor proposal set.
Building this for real?
This is a free starting point. If you'd rather have what Scult builds built and running for your business, that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
