Most long-document work with Claude falls into one of three prompt patterns, summarise, extract, or compare, and knowing which pattern actually fits your task, rather than defaulting to a generic 'tell me about this document' prompt, is the difference between a genuinely useful output and something too vague to act on.
Pattern one: summarise, for when you need the gist
Use this when you need to quickly understand what a document says without reading it fully yourself, a long contract, a lengthy report, a dense policy update. The prompt that works best specifies the audience and the length: 'Summarise this document for a business owner with no legal background, in under 200 words, focused on anything that requires a decision from me.' A generic 'summarise this' produces a generic summary, specifying the audience and the decision-relevant focus produces something you can actually act on.
Pattern two: extract, for when you need specific facts pulled out
Use this when the document contains specific data points you need isolated, dates, dollar figures, names, clauses, rather than a narrative understanding of the whole. 'Extract every dollar figure and the clause it appears in from this contract, in a table' produces a structured, checkable output. Asking for extraction as a table or list, rather than prose, makes the output far easier to verify against the source, since each row can be checked individually.
Summarise: for understanding the gist quickly, specify audience and focus
Extract: for pulling specific facts, ask for a structured table or list, not prose
Compare: for spotting differences across two or more documents, ask for a structured comparison, not a narrative
Pattern three: compare, for spotting what's different across documents
Use this when you have two or more versions of something, a contract before and after redlines, two vendor proposals, a policy across two financial years, and need the differences surfaced rather than a fresh read-through of each. 'Compare these two contracts and list every clause that differs, with a plain-English note on what changed and why it might matter' works better than asking Claude to read both and 'tell me the differences' loosely, because it forces a structured, clause-by-clause pass rather than a general impression.
A Melbourne legal team's actual workflow
A six-person Melbourne boutique law firm built three saved prompt templates matching these exact patterns for reviewing incoming vendor contracts against their standard terms, cutting first-pass contract review time from roughly 45 minutes to 12 minutes per contract, with a lawyer still doing the final judgement call on anything flagged. Across their typical volume of around 20 vendor contracts a month, that's a saving of roughly 11 hours a month, worth close to $2,200 at their billable rate, redirected toward higher-value client work.
Combining patterns for genuinely complex documents
Why structured output matters more than it seems
Across all three patterns, the single change that most improves reliability is asking for structured output, a table, a numbered list, a clearly labelled comparison, rather than free-flowing prose. Structured output is easier for a human to verify against the source quickly, easier to spot a gap or an error in, and easier to hand off to someone else who wasn't part of the original request. A prose summary of extracted contract clauses hides errors far more easily than the same information in a table where each row can be checked in isolation.
This matters especially for long documents where a single missed detail, a clause, a date, a figure, could carry real consequences. Structured extraction makes the checking process itself faster and more reliable, which is exactly where the time saving in the Melbourne example above actually comes from, not from skipping verification, but from making verification quick enough to do properly every time.
Whichever pattern fits a given task, the underlying principle holds across all three: a specific, structured request produces a specific, checkable output, while a vague request produces a vague one, regardless of how long or detailed the source document itself is.
Saving these three patterns as reusable templates, the same way a team might save any other frequently used brief, means nobody needs to reconstruct the right phrasing from scratch each time a long document lands in their inbox, which is exactly the kind of small, compounding discipline that separates a team getting consistent value from long-document work and one getting occasional, inconsistent results depending on who happened to write that day's prompt.
For a long, complex document, it's often worth running extract first to pull the structured facts, then summarise using those extracted facts as the grounding material for a tighter, more accurate summary, rather than trying to do both in a single prompt. Breaking the task into its component patterns, run in sequence, consistently produces a more reliable result than one large, vague instruction trying to do everything at once.
