How I Use AI to Read the Things I Don't Have Time to Read
Last year a client sent me a 40-page production contract on a Friday afternoon and needed an answer by Monday. I did what everyone does: dropped it into a chat and typed "summarize this."
What I got back was accurate, well-organized, and completely useless. Eight bullet points describing that the document was a production agreement covering scope, deliverables, payment terms, and IP. I knew all of that from the title page. The one thing I actually needed to know — whether I was signing away the right to show the work in my own reel — was in a subclause on page 31 and did not appear anywhere in the summary.
That wasn't the model failing. That was me asking a question with no answer in it. "Summarize this" means "compress this proportionally," and proportional compression is exactly what buries the one paragraph that matters. The important clause is short. The boilerplate is long. Summarize by volume and the boilerplate wins.
I've read a lot of documents through a model since then — contracts, research papers, competitor teardowns, two-hour call transcripts — and almost everything I learned comes down to one shift: stop asking for a summary, start asking the question you were going to read the document to answer.
The extraction prompt
Ninety percent of the time I open a long document, I already know what I'm looking for. I'm not reading a contract for pleasure; I'm reading it to find out what it costs me and what I'm giving up. So that's what I ask for.
Below is a document I need to make a decision about. I'm going to tell you what I care about, and I want you to go find it — do not summarize the document as a whole. What I care about: [THE 2-3 THINGS THAT ACTUALLY MATTER TO YOU] For each one, give me: the answer, the exact quoted sentence(s) it comes from, and where in the document they appear. If the document does not address one of my concerns, say "not addressed" — do not infer, do not fill the gap with what's typical. At the end, list anything you noticed that I did not ask about but that a careful reader would flag. Document: [PASTE]
Three parts of that prompt are doing the work.
"Do not summarize the document as a whole" kills the proportional-compression instinct. I want a search, not a précis.
The exact quote requirement is the single most valuable line I've added to any prompt in the last two years. A model paraphrasing a legal clause is a model gently rounding it toward what clauses usually say. When it has to produce the literal sentence, I can read the sentence myself and check whether the interpretation holds. It also makes hallucination visible — if the quote doesn't exist in the file, that's obvious in a way a smooth paraphrase never is.
"Not addressed" as an allowed answer matters more than it looks. Without it, a model asked "what are the termination terms?" will find *something* to say about termination, because the request implies there's an answer. Explicitly permitting "the document doesn't cover this" is what makes silence possible — and silence is often the finding. A contract that says nothing about my reel rights is a very different problem from one that denies them, and I need to be able to tell those apart.
The last line — flag what I didn't ask about — is my hedge against my own blind spots. It's the only summarizing I want, and it's targeted at the gap between what I thought to ask and what's actually in there.
Making it prove the reading
Even with quotes, I don't trust a single pass on anything that carries real consequences. So on important documents I run a second prompt whose only job is to attack the first one.
Here is a document, and here is a set of claims someone made about it. For each claim, verify it against the document itself: mark it SUPPORTED (and give the quote), UNSUPPORTED (the document doesn't say this), or CONTRADICTED (the document says something different — show me what). Be adversarial. Assume at least one claim is wrong and your job is to find it. Do not defend the claims. Document: [PASTE] Claims: [PASTE THE FIRST PASS OUTPUT]
Running the extraction and the verification as two separate passes is the point. A model asked to produce an answer and then check its own answer in the same breath will mostly ratify itself — it's already committed. Handing the output back as *someone else's* claims removes the ownership, and the adversarial framing gives it a job it can succeed at by finding errors.
This catches maybe one real error in five documents for me. That sounds low until you consider that the one it caught was a payment-schedule misread that would have cost me six weeks of cash flow.
The pass I run on things I'm not an expert in
Contracts I at least know how to read. Research papers, technical specs, and anything outside my domain are harder, because I don't know what I don't know — I can't ask for the clause that matters if I don't know that clause exists.
For those I use a different shape entirely. Instead of extraction, I ask for the argument's skeleton and its weak joints.
I'm reading this as a non-expert and I need to understand it well enough to decide whether to act on it. Give me, in this order: 1. The central claim in one sentence, in plain language. 2. The evidence it rests on — and specifically, what kind of evidence it is (measured, modeled, self-reported, anecdotal). 3. The three assumptions the argument needs to be true that it does not itself prove. 4. What a competent, informed skeptic in this field would push back on first. 5. What would have to be true elsewhere in the world for this to be wrong. Use plain language throughout — if you use a term of art, define it inline in five words. Quote the document for points 1 and 2. Document: [PASTE]
Point 3 is the one I'd keep if I could only keep one. Every argument has load-bearing assumptions it treats as too obvious to state, and those are exactly what a non-expert can't see. Getting them named turns an intimidating document into a short list of things I can go verify or ask a real expert about.
I use this on transcripts too. A two-hour call has an argument buried in it, and the skeleton view finds it faster than any summary of what was said in order.
Where this doesn't work
I don't do this with anything I need to have actually read. There's a real difference between *knowing what a document says* and *having read it*, and the gap shows up the moment someone asks you a question one layer deeper than your extraction.
So: anything I'm going to be accountable for in a room, I read. Anything where the craft is in the phrasing — a script, a brief, copy someone worked hard on — I read, because the model can tell me what it says and cannot tell me whether it lands. And anything I'm signing, I read the quoted clauses in place, in the original file, with the surrounding paragraph.
What the model buys me isn't the reading. It's knowing where to spend the reading. I go through 40 pages at speed, come out with six passages that matter, and then read those six properly. That's not a shortcut around the work — it's a way of pointing the work at the right pages.
The habit that made it stick
None of these prompts are clever. What made them useful is that they're saved, because the moment I need them is always the moment I'm least likely to write them well — Friday afternoon, forty pages, a deadline. Under that pressure I don't compose a careful extraction prompt with quote requirements and a "not addressed" escape hatch. I type "summarize this" and take what I get.
That's most of what I use Super Prompts for: the prompts I know are better than my instinct, sitting one click away so instinct never gets a vote.
The next time a long document lands on you, don't ask what it says. Ask it the question you were going to read it to answer, make it quote the answer back, and then go read those pages yourself.