How to Summarize a PDF With AI: Prompts, Limits, and Verification
Your downloads folder is full of documents you meant to read. Here is how to get a summary you can act on, and how to tell when the summary is wrong.
Prompt engineering is mostly five ideas repeated. Learn those and you will outperform anyone reciting a list of magic phrases.
“Short blog post about gardening” gets you a short blog post about gardening: correct, general, and useless. Then you clarify, and clarify again, and eventually get something workable after six messages that a better first message would have produced immediately.
Prompting well is not a secret vocabulary. It is a small number of ideas, and once you have them you stop needing prompt libraries.
A model predicts what should come next given everything it has been shown. Your prompt is the context that determines what “next” means. That framing explains almost every practical rule: more relevant context narrows the space of plausible continuations, and vagueness leaves it wide, so the model lands on the average — which is exactly what generic output is.
Not every prompt needs all five. Most weak prompts are missing three.
1. Role or perspective. “You’re a copy editor for a technical publication” is different from no framing at all — it selects a register and a set of concerns.
2. Task, stated precisely. “Summarize” is ambiguous. “Give me the five decisions made and who owns each” is not.
3. Context. Who it is for, what has been tried, what constraints apply, what the surrounding situation is.
4. Format. Length, structure, table or prose, bullet or paragraph. Say it or you will get the default.
5. Constraints, including negative ones. What to avoid, what not to assume, what not to include. Negative constraints are underused and they work.
Before: Write a post about gardening.
After:
You're writing for people who have killed several houseplants and concluded they're bad at this. Write a 600-word piece on why plants die indoors, focused on the three actual causes — light, watering rhythm, and pot drainage. Direct and slightly dry, no encouragement, no "green thumb" clichés. Include one specific diagnostic the reader can run this evening. Short paragraphs, no bullet lists.
Same topic. Completely different output.
The highest-value instruction there is, and almost nobody uses it.
Before answering, ask me the questions you'd need to give a genuinely specific answer instead of a generic one. One at a time. Don't start until you have enough.
One example of what good looks like beats three paragraphs describing it.
Here's a paragraph in the style I want: [paste]. Write three more on these topics, matching that rhythm and level of concreteness. Tell me what you think defines the style, so I can check we agree.
For anything analytical, requesting the working first improves the answer, because the conclusion is then conditioned on the reasoning rather than the reverse.
Closer. The structure works, the tone is too enthusiastic, and the third section is generic. Fix those three things and leave everything else exactly as it is.
Naming what is right protects it. Otherwise the next version fixes your complaint and breaks something that was fine.
Now argue the strongest case against what you just told me. Not a token counterpoint — the version a smart person who disagrees would actually make.
Assistants agree too readily. This is the correction.
Content and marketing:
Act as a direct response copywriter. Product: [X]. Audience: [specific profile]. The one thing they must understand: [Y]. Write five email subject lines across different angles — curiosity, specificity, objection, outcome, and one contrarian. Under 50 characters each. No clickbait, no emoji, nothing I'd be embarrassed to have in someone's inbox. Then tell me which you'd send first and what it's testing.
Personal productivity:
Here's everything on my plate this week: [list]. I have about 22 usable hours. Sort it by what actually has consequences, tell me what to drop and what to delegate, and build me a plan with slack in it. Then tell me which item I'm avoiding and why you think that.
The techniques work anywhere. In ChatUp, keep the relevant job, voice, and constraints in the current conversation, then compare another available model when a prompt is not working. The current selector is the source of truth for model names and availability.
You need five ideas: context, specificity, format, constraints, and iteration. Beyond that, returns diminish fast.
As examples of structure, yes. As things to paste unmodified, no — the specificity is the value, and a library entry has none of yours.
Broadly, yes. Models differ in verbosity, instruction-following, and default register, so expect to adjust format instructions rather than rewrite the prompt.
Generation is stochastic, and context from earlier in a long conversation influences later replies. For anything important, start a fresh chat.
Everything here reduces to giving the model less room to be generic. Context, format, constraints, an example, and a follow-up that names what to keep. That is the job, and it takes an afternoon to learn.
Try it in ChatUp
Run the prompts above against the model that suits the task, keep the useful context across chats, and pick it back up on any device.
Try for Free