Prompts for Text Summarization

How to Use This Lesson Lesson 20 explained the principles of summarization: audience, length, focus, format, and faithfulness. Lesson 72 showed how chains make summaries more reliable. This lesson is a practical collection of ready-to-use summarization prompts for situations developers and teams meet every day.

Each recipe follows the same structure:

Use it when: the situation the recipe is designed for Prompt: a tested prompt you can copy and adapt Example: a sample input and a possible output Why it works: the design decisions inside the prompt Adapt it: common variations At the end, the recipes are collected into a small reusable Python function.

Recipe Output

1. One-line TL;DR A single sentence
2. Key points with exact facts 3–5 bullets
3. Executive summary Situation, finding, recommended action
4. Meeting notes Decisions, action items, open questions
5. Email thread status Current status, decisions, who is waiting on whom
6. Incident summary What happened, impact, cause, fix, prevention
7. Audience-adapted summary The same content for a different reader
8. Release notes from commits User-facing changes grouped by type
9. Update summary Only what changed since the last summary Recipe 1: One-Line TL;DR Use it when: you need a preview, a notification, or a subject line. "TL;DR" stands for "too long; didn't read".

Prompt Summarize the text in in one sentence of at most 25 words for {audience}. Keep any key date or number exactly as written.

{text} Example Input:

From 1 December, all live classes move from Zoom to the GOCOURSE classroom platform. Login details will be emailed on 25 November. Zoom links stop working after 30 November. Possible output:

From 1 December, live classes move to the GOCOURSE classroom platform; login details arrive by email on 25 November. Why It Works A word limit plus "one sentence" gives two consistent constraints (Lesson 8). "Keep any key date or number exactly" protects the details readers most need (Lesson 20). The audience placeholder lets the same recipe serve students, staff, or managers. Adapt It For push notifications, add: Maximum 100 characters, no emojis. and check the length in code. For subject lines, ask for a phrase instead of a sentence. Recipe 2: Key Points With Exact Facts Use it when: readers need to scan the main points of an article, report, or announcement.

Prompt Summarize the text in as 3 to 5 bullet points for {audience}.

Rules:

• One main fact per bullet.
• Keep all numbers, dates, names, and amounts exactly as written.
• Include only information stated in the text. Do not add reasons or opinions.
• Keep the level of certainty: if something is planned or possible, do not present it as decided.

{text} Why It Works The three rules address the three most common faithfulness failures: changed numbers, added reasons, and changed certainty (Lesson 20).

Adapt It Replace "3 to 5" with an exact number when the output feeds a fixed layout. Add Order the bullets by importance to {audience}. when readers may only read the first bullet. Recipe 3: Executive Summary Use it when: a decision-maker needs to understand a report quickly and know what to do.

Prompt Write an executive summary of the report in for a manager with 1 minute to read.

Use exactly three short paragraphs:

1. Situation: what the report is about, in one or two sentences.
2. Key finding: the most important result, with its supporting number.
3. Recommended action: what the report suggests doing next. If the report makes no recommendation, write "The report does not recommend an action."

Use only information from the report.

{text} Example Output Situation: The report reviews course completion rates for the July to October batches.

Key finding: Completion fell from 68% to 54%, mainly in courses where live classes moved to weekday mornings.

Recommended action: The report suggests restoring evening class slots for the November batch. Why It Works A fixed three-part structure matches how managers read: context, result, action. The fallback for "no recommendation" prevents the model from inventing an action (Lesson 10, Tip 3). Recipe 4: Meeting Notes to Decisions and Action Items Use it when: turning meeting notes or transcripts into something people can act on.

Prompt From the meeting notes in , produce:

Decisions:

• ...

Action items (Owner — Task — Due date, or "No date"):

• ...

Open questions:

• ...

Write "None" under a heading if nothing applies. Use only what the notes say; do not assign owners or dates that were not mentioned.

{text} Example Input:

Priya: let's move the Django batch start to 15 Nov. Everyone agreed. Arun will update the website by Friday. We still don't know if recordings will be ready on day one. Karthik to check with the video team. Possible output:

Decisions:

• The Django batch will start on 15 November.

Action items (Owner — Task — Due date, or "No date"):

• Arun — Update the website — Friday
• Karthik — Check with the video team whether recordings will be ready on day one — No date

Open questions:

• Will recordings be ready on day one? Why It Works Separating decisions, actions, and questions is far more useful than a narrative summary of a meeting. "Do not assign owners or dates that were not mentioned" prevents invented accountability, a common and harmful error. "No date" makes missing deadlines visible instead of hidden. Recipe 5: Email Thread Status Use it when: someone joins a long email thread and needs to know where things stand.

Prompt Summarize the email thread in for someone joining the conversation now.

Format: Current status: one sentence Decisions made: bullet list, or "None" Waiting on: who needs to do what, or "Nothing"

When later messages correct or override earlier ones, report only the latest position and mention that it changed.

{text} Why It Works The rule about later messages addresses the main risk of thread summaries: reporting a plan that was already changed (Lesson 20).

Adapt It Before sending the thread, remove signatures and quoted replies in code (Lesson 7). They add length and repeat old content.

Recipe 6: Incident Summary Use it when: writing up a technical problem such as an outage, a failed payment run, or a deployment error.

Prompt Write an incident summary from the notes and logs in .

Sections: What happened: 1–2 sentences Impact: who was affected and for how long, with numbers if stated Cause: the cause as stated in the notes; if the cause is not confirmed, write "Not confirmed" and list the suspected causes as suspected Fix: what was done to resolve it Prevention: follow-up actions mentioned in the notes, or "None stated"

Use a neutral, factual tone. Do not blame individuals.

{text} Why It Works "Not confirmed" vs "suspected" preserves the difference between knowledge and guesses, which matters for engineering decisions. A neutral, no-blame tone matches good incident review practice and keeps the summary useful for learning. Recipe 7: Audience-Adapted Summary Use it when: the same content must be explained to readers with different knowledge, such as developers, students, and parents.

Prompt Summarize the text in for {audience}.

The reader knows: {reader_knows} The reader does not know: {reader_does_not_know}

Explain any necessary technical term in a few plain words the first time it appears. Maximum {max_words} words.

{text} Example Settings Audience reader_knows reader_does_not_know Parents of students Their child is enrolled in a coding course Programming terms New developers on the team Python and Django basics The project's architecture Managers Business goals Implementation details Why It Works Stating what the reader knows and does not know is more precise than labels such as "for beginners" (Lesson 34, audience roles).

Recipe 8: Release Notes From Commits Use it when: turning a list of commit messages or merged changes into notes for users.

Prompt Turn the commit messages in into release notes for users of a learning platform.

Group changes under these headings, and omit a heading if it has no items: New features Improvements Bug fixes

Rules:

• Describe each change in terms of what users notice, not code details.
• Leave out internal changes (refactoring, tests, dependency updates) unless they change user-visible behavior.
• Do not invent changes that are not in the commits.

{text} Why It Works "What users notice" translates developer language into user benefits. Leaving out internal changes keeps notes relevant to the audience. "Do not invent changes" prevents marketing-style additions that are not true. Recipe 9: Update Summary (What Changed Since Last Time) Use it when: readers have already seen a previous summary and only need what is new, such as weekly project status or ongoing support cases.

Prompt The previous summary is in . New information is in .

Write only what changed: New: facts that were not in the previous summary Changed: facts that are different now (write "was X, now Y") Resolved: items from the previous summary that are now closed

Write "No changes" if nothing changed.

{previous_summary}

{text} Why It Works Comparing against the previous summary avoids repeating what readers already know. "was X, now Y" makes changes explicit, which is especially important for dates and amounts. Choosing a Recipe You Need... Recipe A preview or notification 1 A scannable overview 2 A decision-ready summary for a manager 3 Actions after a meeting 4 To catch up on a long thread 5 A write-up of a technical problem 6 The same content for different readers 7 User-facing release notes 8 A recurring status update 9 For very long inputs, combine any recipe with map-reduce (Lesson 15) or extract-then-summarize (Lesson 72).

Using the Recipes in Code Store recipes as templates and fill them with string.Template, which raises an error when an option is missing (Lesson 38).

from string import Template

RECIPES = { "tldr": Template( "Summarize the text in in one sentence of at most 25 words for $audience.\n" "Keep any key date or number exactly as written.\n\n" "\n$text\n" ), "action_items": Template( "From the meeting notes in , list:\n" "Decisions:\n- ...\n" "Action items (Owner — Task — Due date, or \"No date\"):\n- ...\n" "Open questions:\n- ...\n" "Write \"None\" under a heading if nothing applies. Use only what the notes say.\n\n" "\n$text\n" ), }

def build_summary_prompt(recipe: str, text: str, options: str) -> str: return RECIPES[recipe].substitute(text=text, options)

print(build_summary_prompt("tldr", "Classes move to the new platform on 1 December.", audience="students"))

try: build_summary_prompt("tldr", "Classes move to the new platform on 1 December.") except KeyError as error: print("Missing option:", error) Output:

Summarize the text in in one sentence of at most 25 words for students. Keep any key date or number exactly as written.

Classes move to the new platform on 1 December. Missing option: 'audience' Code Explanation RECIPES maps recipe names to templates written with $ placeholders, which do not conflict with braces or quotation marks in the prompt text. build_summary_prompt() fills the template. The text value is always required; other options depend on the recipe. When audience is missing, substitute() raises a KeyError naming the missing option, so incomplete prompts are never sent. To grow this into a maintained collection with versions, owners, and tests, use the prompt library approach from Lesson 68.

Common Mistakes Mistake 1: One Generic Summary Prompt for Everything What it is: Using "Summarize this" for meetings, incidents, threads, and reports.

Why it happens: It seems simpler to have one prompt.

What it causes: Summaries that miss what each situation requires, such as owners in meetings or the latest status in threads.

How to fix it: Use a recipe designed for the situation.

Mistake 2: Inventing Missing Details What it is: Summaries that assign owners, dates, causes, or recommendations not present in the source.

Why it happens: The format implies every field should be filled.

What it causes: False information presented as fact.

How to fix it: Provide explicit fallbacks: "No date", "Not confirmed", "None stated".

Mistake 3: Not Cleaning the Input What it is: Sending raw threads with signatures, quoted replies, and disclaimers.

Why it happens: Cleaning seems optional.

What it causes: Longer prompts and summaries of outdated quoted content.

How to fix it: Remove noise in code before building the prompt (Lesson 7).

Mistake 4: Skipping Verification for Important Summaries What it is: Publishing summaries without checking numbers and claims.

Why it happens: Summaries look correct at a glance.

What it causes: Changed figures and unsupported statements reach readers.

How to fix it: Check numbers in code and verify claims for important summaries (Lessons 20, 72).

Best Practices Choose a recipe for the situation. Each recipe encodes what that kind of summary needs.

Keep faithfulness rules in every recipe. Exact numbers, no additions, preserved certainty.

Give every field a fallback value. Make missing information visible.

Clean inputs before summarizing. Remove signatures, quotes, and markup.

Store recipes as templates. Fill them in code and fail loudly on missing options.

Verify important summaries. Use code checks and verification prompts.

Try It Yourself Exercise 1: Meeting Recipe Write notes from a real or imagined team meeting that include two decisions, three action items (one without an owner and one without a date), and an unresolved question. Run Recipe 4 and check that no owner or date was invented.

Exercise 2: Same Content, Three Audiences Take a technical announcement, such as a database migration or a new login system. Use Recipe 7 for three audiences: students, parents, and new developers. Compare vocabulary and length across the three outputs.

Exercise 3: Extend the Recipe Collection Add Recipes 3, 5, and 8 to the RECIPES dictionary using $ placeholders, and write a test for each that confirms the prompt renders with valid options and raises an error when a required option is missing.