How to Prompt an LLM to Summarize

Article summary

A good summarization prompt names a purpose (for whom, deciding what), a length (words or bullets, with a hard cap), a structure (TLDR + bullets + risk, or whatever fits), and a faithfulness rule ("only what is in the source; mark unknowns"). Skip any of those four and you get the dreaded medium-length, vibes-only summary.

Summarization is the use case where the default prompt is the worst prompt. "Summarize this" produces output that is precisely medium length, lightly hedged, and useful to no one. Four specifics fix that.

1. Name the purpose

A summary for whom, doing what? "Summarize for a CFO deciding whether to approve a $2M spend" produces a different output than "summarize for an engineer who needs to understand the system before tomorrow's meeting." Same source, completely different summary.

If you do not have a specific purpose in mind, write the summary for the most common reader you actually have. "Summary for engineers skimming on their phone" works.

2. Pin the length

Models trained on average human writing produce average-length outputs by default. Force a cap:

"Summary in exactly 5 bullets, max 18 words each."
"TLDR in one sentence, then 3 bullets, max 100 words total."
"Three paragraphs, max 80 words each."

Hard caps with hard counts are best. "Be concise" is meaningless to the model and produces no consistent length.

3. Specify the structure

Give the summary a shape that matches the reader's job:

Status update: TLDR + What changed + What is at risk.
Meeting recap: Decisions + Action items + Open questions.
Article summary: Headline finding + Three supporting facts + One disagreement worth knowing about.
Document briefing: Purpose + Key claims + Sources cited + What is not addressed.

The structure does most of the work. Bad summaries are bad because they lack one.

4. Demand faithfulness, plainly

Add this line, near verbatim:

Only include facts present in the source. If a question would require information not in the source, write "not stated in source." Do not infer beyond what the text supports.

This is the single most accuracy-positive line in a summarization prompt. It does not eliminate hallucinations but it cuts them by a lot, because the model has been given explicit permission to say "I don't know from this." Without that permission, the default is to fabricate something plausible.

A complete starter prompt

You are summarizing a meeting transcript for an engineering team lead who missed the call. They will read the summary on their phone in 20 seconds.

Structure:
- TLDR: one sentence.
- Decisions made: 3 bullets max.
- Action items: who, what, by when. Max 4.
- Open questions: 2 bullets max.

Total length: 120 words max.

Rule: only include things actually said. If something was implied but not stated, omit it. If "by when" is unclear, write "deadline unclear."

Transcript:
[paste]

This will produce something useful on the first try. The default would produce a 400-word recap that nobody reads.

Frequently asked questions

Why does the default summary feel useless?

Because "summarize this" gives the model no signal about purpose, audience, or length. Models trained to be helpful default to "moderately long, lightly hedged, mention everything once." That is the worst summary for almost every actual reader. Pin a purpose and a length and the output snaps into shape.

Should I ask for bullets or paragraphs?

Bullets when the reader will scan (status updates, meeting recaps, briefings). Paragraphs when the reader will read (long-form prose, executive memos). Mixed when the document has an obvious shape (headline + 3 bullets + 1 risk). Pick deliberately; do not let the model choose.

How do I stop hallucinated facts in summaries?

Add the explicit rule "Only include facts present in the source. If the source does not address a question, write 'not stated in source.' Do not infer." This single sentence cuts hallucinated specifics dramatically. Combine with retrieval if the source is large.