# Hodios paste pack: Summarisation

Everything in Summarisation from Hodios, the open prompt library by Hermes IDE: 7 entries, catalog 2026.1003.0.

Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed.

Browse and search the library at https://hermes-ide.com/prompts

## How to use

Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions.

## Contents

- Summarisation
  - [Build a news digest](#build-news-digest) (prompt)
  - [Compare two documents](#compare-documents) (prompt)
  - [Extract deadlines and dates](#extract-deadlines) (prompt)
  - [Summarise a book](#summarize-book) (prompt)
  - [Summarise a long document](#summarize-long-document) (prompt)
  - [Summarise a video or podcast transcript](#summarize-video-transcript) (prompt)
  - [Summarise an email thread](#summarize-email-thread) (prompt)

---

<a id="build-news-digest"></a>

## Build a news digest

`build-news-digest` · prompt · Summarisation · https://hermes-ide.com/prompts/build-news-digest

Turns several articles into a short briefing - key developments, where sources agree or disagree, what is genuinely new and what to watch next - with every point traced to its source.

````markdown
<context>
A useful digest saves the reader from reading every article without hiding how the coverage differs. It separates facts reported by several outlets from claims made by one, separates reporting from opinion, keeps attributions ("the ministry said", "according to two people familiar"), and is honest that the articles may be out of date or incomplete. It uses only the articles supplied.

<articles>
[ARTICLES]
</articles>
</context>

<task>
1. Number the articles [1], [2], … in the order given, and note each one's outlet, date and type (news report, analysis, opinion, press release) where you can tell. If dates are missing, say so.
2. Extract the developments: what happened, who did it, when, and the key numbers. Merge duplicates across articles and cite every source that reports each one.
3. Compare the coverage:
   - Agreement: facts reported consistently by two or more sources.
   - Differences: conflicting numbers, timelines or explanations; claims that appear in only one source; differences in framing or what each outlet emphasises. State both sides with citations and do not resolve a conflict the articles do not resolve.
4. What is new: if the articles span time, what changed in the latest ones compared with earlier ones. If they do not, say what is new compared with the background the articles themselves give.
5. What to watch: scheduled events, decisions or data mentioned in the articles, and the open questions they leave.
6. If a focus was given, order everything by relevance to it and add one line on why it matters for that focus. Do not speculate beyond what the articles support; mark any inference.
</task>

<constraints>
- Use only the supplied articles. Do not add facts from memory, and say when something the reader would expect (for example the other side's response) is missing from the coverage.
- Keep attribution: an outlet's claim is not a fact, and an anonymous source is labelled as such.
- Opinion and analysis pieces are labelled; their arguments are not reported as events.
- Keep numbers, hedges and qualifiers exact.
- If only one article is supplied, produce a summary and say comparison needs at least two sources.
</constraints>

<output_format>
## Bottom line
Two or three sentences.
## Key developments
Bullets, most important first, each ending with citations like [1][3].
## Where sources agree
Bullets with citations.
## Where they differ
Bullets: the point, what each source says, with citations.
## What is new
Bullets.
## What to watch
Bullets with dates where given.
## Sources
Numbered list: outlet, headline, date, type.

Aim for under 400 words before the source list.
</output_format>
````

---

<a id="compare-documents"></a>

## Compare two documents

`compare-documents` · prompt · Summarisation · https://hermes-ide.com/prompts/compare-documents

Compares two versions of a document, or two related documents, and reports what changed, what stayed consistent and what conflicts, with quotes and locations for every finding.

````markdown
<context>
Reviewers comparing documents miss the changes that matter most: a number edited in the middle of a paragraph, a "must" softened to "should", a clause deleted rather than reworded, or two related documents (a policy and its FAQ, a proposal and its contract, a spec and its summary) that quietly contradict each other. You compare meaning, not just wording, and you show your evidence with short quotes so the reader can check every finding.

<document_a>
[DOCUMENT_A]
</document_a>
<document_b>
[DOCUMENT_B]
</document_b>
</context>

<task>
1. Decide the relationship and state it: two versions of the same document (A older, B newer, unless the text says otherwise), or two related documents that should agree. If it is unclear, say which reading you took.
2. For versions, find every substantive change: added, removed, moved and modified content. Prioritise changes in meaning: numbers, dates, amounts, names, obligations (must, shall, may, should), scope, conditions and exceptions, deadlines, and negations. Group pure wording or formatting changes into a single line instead of listing each.
3. For related documents, find where they say the same thing, where one covers something the other omits, and where they conflict.
4. Rate each finding's impact: High (changes what someone must do, pay, deliver or may rely on), Medium (changes emphasis, scope or clarity), Low (wording).
5. Flag passages that are ambiguous, moved in a way that changes their context, or cannot be compared because a section is missing or truncated.
</task>

<constraints>
- Quote short fragments from both documents for every High and Medium finding and give the section, heading or paragraph where it appears.
- Report differences; do not judge which version is better unless asked, and do not invent the reason for a change.
- Do not paraphrase numbers or obligations; quote them.
- If either document looks truncated or the two are unrelated, say so before comparing.
- For legal or financial documents, this is a reading aid; say once that anything with consequences should be checked by the person responsible or a professional.
</constraints>

<output_format>
## Relationship
One line.
## Summary
Three to five bullets: the changes or differences that matter most.
## Changes or differences
A table: Impact | Location | A says | B says | What it means. Sorted High first.
## Conflicts
For related documents: bullets with quotes from both. For versions: write "Not applicable".
## Consistent
One or two lines on what is unchanged or agrees, so the reader knows what they can skip.
## Needs a closer look
Bullets for ambiguous, moved or truncated parts.
</output_format>
````

---

<a id="extract-deadlines"></a>

## Extract deadlines and dates

`extract-deadlines` · prompt · Summarisation · https://hermes-ide.com/prompts/extract-deadlines

Extracts every date, deadline, appointment and time-bound obligation from letters, emails, syllabi or contracts into a sorted calendar-ready list, quoting the source line.

````markdown
<context>
You extract dates the way a careful paralegal or registrar would. Missed deadlines rarely come from the obvious date in bold; they come from a notice period buried in clause 14, "within 30 days of the date of this letter", a recurring due date, a time in another time zone, or "03/04" read the wrong way. Your job is to find every time-bound item, convert it to a calendar-ready date where the text allows, show your working where it does not, and quote the exact source line so the person can check you.

Documents:
<documents>
[DOCUMENTS]
</documents>


</context>

<task>
1. Read every document. For each, note its title or sender and its own date if stated.
2. Find every time-bound item: deadlines, due dates, appointments, exams, hearings, payments, renewals, cancellation or notice windows, cooling-off periods, expiry dates, recurring obligations, and dates by which a reply or document is required. Include soft dates ("by the end of the month") and conditional ones ("if you do not reply by").
3. For each item record: the date, the time and time zone if stated, what must happen, who must act (the reader or someone else), the consequence if stated, the source document, and the exact source line quoted.
4. Resolve dates:
   - Absolute dates: normalise to YYYY-MM-DD with the weekday. If the year is missing, infer it from the document date and say so.
   - Relative dates ("within 14 days of receipt", "30 days before renewal"): compute them only when the anchor date is in the text. Show the calculation. If the anchor is unknown (for example the date of receipt), give the formula and list it under "Relative deadlines that need an anchor".
   - Times in another zone: convert to the reader's time zone when one is given, showing both.
   - Ambiguous formats (03/04/2026): give both readings, pick the likely one from context (sender's country, other dates in the same document) and flag it.
5. Note whether a stated weekday matches the date, and flag mismatches.
6. Sort all dated items chronologically. Mark items dated before today as "past" and keep them in the list. If today's date was not given, use the most recent document date as the reference point, mark earlier items "possibly past", and say once which reference date you used.
7. List recurring obligations separately with their rule and the next three occurrences when computable.
</task>

<constraints>
- Quote the source line exactly for every item. If you cannot quote it, do not list it.
- Never invent a date, time, anchor or consequence. Do not round "within 30 days" to a month.
- Count days as the text says (calendar days unless it says working or business days). When a rule for counting is unclear (whether the first day counts, what happens on weekends or public holidays), say so and use the earlier date as the safe date.
- Do not interpret whether a deadline is legally binding or what happens if it is missed beyond what the text says. For legal, tax, immigration or court deadlines, add one line telling the reader to confirm the date with the issuer or a qualified adviser.
- If the input contains no dates or obligations, say so.
</constraints>

<output_format>
## Next up
The three earliest items on or after the reference date (today, or the latest document date), one line each, with days remaining when today is known.

## All dates
Table, sorted: Date (weekday) | Time | What | Who acts | Type | Source | Quote | Notes.

## Recurring
Table: Rule | Next occurrences | Source | Quote.

## Relative deadlines that need an anchor
Table: Deadline formula | Anchor needed | Source | Quote.

## Undated obligations
Bullets with quotes, or "None".

## Ambiguities
Numbered list of anything to check, or "None".
</output_format>
````

---

<a id="summarize-book"></a>

## Summarise a book

`summarize-book` · prompt · Summarisation · https://hermes-ide.com/prompts/summarize-book

Summarises a non-fiction book's argument, key ideas, evidence and critiques, and turns it into actions for your purpose. Says when it does not know the book instead of inventing content.

````markdown
<context>
The reader wants to understand what a book argues, how well it argues it, and what to do with it, not a chapter-by-chapter recap. The biggest risk is a confident summary of a book you do not actually know well: invented chapters, quotes or studies are worse than no summary.

<book>
[BOOK]
</book>
</context>

<task>
1. Decide what you are working from. If the input is the user's notes or text, summarise only that and say so. If it is a title, judge honestly how well you know the book. If you do not recognise it, or know only its reputation, say so, offer what you can say with confidence, and ask the user to paste notes or a table of contents. Do not produce the full summary from guesses.
2. State the thesis in one or two sentences: the claim the author wants the reader to accept.
3. Lay out the core argument as a short chain: the problem, the author's diagnosis, the proposed answer, and why the author thinks it works.
4. Explain five to eight key ideas, each in plain words with an example of how it shows up in real life.
5. Describe the evidence the author relies on (research, case studies, personal experience, history) and how strong it is.
6. Give the main critiques and limits: where findings have not held up, where the argument overreaches, and who the advice fits less well. Attribute criticism to its general source ("later replication attempts", "reviewers in the field") rather than inventing names.
7. Turn it into three to five concrete actions for the user's purpose, or for a general reader if no purpose is given.
8. Say who should read it in full and which chapters, if you know them, give the most value.
</task>

<constraints>
- No direct quotes unless they appear in the user's own notes. Paraphrase instead.
- Do not invent chapter titles, page numbers, studies, statistics or anecdotes. If unsure of a detail, leave it out or mark it "(verify)".
- Separate what the author claims from what is well established.
- For fiction, adapt: replace argument and evidence with premise, themes, characters and craft, and avoid spoilers unless the user asks.
- Aim for a summary readable in five minutes.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>

<output_format>
Start with one line: "Working from: your notes" or "Working from: my general knowledge of the book (confidence: high, medium or low)".
## In one paragraph
## The core argument
A numbered chain of three to five steps.
## Key ideas
Numbered: idea in bold, then two or three sentences and an example.
## Evidence
## Critiques and limits
## Apply it
Checklist of three to five actions tied to the purpose.
## Read it in full if
</output_format>
````

---

<a id="summarize-long-document"></a>

## Summarise a long document

`summarize-long-document` · prompt · Summarisation · https://hermes-ide.com/prompts/summarize-long-document

Produces a layered summary of a long document, from one line to key points to section detail, keeping numbers, hedges and nuance faithful and pointing to where each point comes from.

````markdown
<context>
You are an analyst who briefs busy decision makers on documents they will not read in full. Your summaries are layered so the reader can stop at any level, and they are faithful: the numbers are exact, hedges stay hedged ("may", "in some cases"), the author's claims are kept apart from the evidence for them, and nothing is added that the document does not say.

Document:
<document>
[DOCUMENT]
</document>

Length: standard
</context>

<task>
1. Read the whole document first. Identify its type, its main claim or purpose, and its structure.
2. Write one line that captures what the document says and why it matters, not what it is about.
3. Write the key points (5–7), most important first. Each point is a finding, conclusion or requirement, with a pointer to where it appears (section heading or number, page if available; if the document has no headings or pages, a short quoted phrase that locates it).
4. If a purpose was given, add what matters most for it: the passages that support or complicate the reader's decision, and anything they must act on.
5. For standard and detailed lengths, summarise each major section in 1–3 bullets (standard) or a short paragraph (detailed), following the document's own order.
6. Collect the numbers that matter (amounts, dates, percentages, thresholds, deadlines) exactly as written, with units and where they appear.
7. List caveats the document states (limitations, assumptions, conditions) and notable gaps: questions a careful reader would ask that the document does not answer.
</task>

<constraints>
- Faithfulness first: no facts, numbers or conclusions that are not in the document. Do not round or convert figures unless you label the conversion.
- Preserve the strength of claims: keep "may", "suggests", "in pilot sites" and similar qualifiers. Do not turn a correlation into a cause or a proposal into a decision.
- Separate what the document claims from what it shows. If a key claim has no supporting evidence in the text, say so neutrally.
- Your own observations go only in Caveats and gaps, labelled as yours.
- If the document appears truncated, partly unreadable, or is several documents pasted together, say so and summarise what is there.
- For the short length, output only In one line, Key points, and For your purpose if a purpose was given.
</constraints>

<output_format>
## In one line
## Key points
Numbered, each ending with (§, page or a short locating quote).
## For your purpose
Only if a purpose was given.
## Section by section
Standard and detailed only.
## Numbers that matter
Table: Figure | What it refers to | Where.
## Caveats and gaps
Bullets: the document's stated caveats, then your observed gaps, labelled.
</output_format>
````

---

<a id="summarize-video-transcript"></a>

## Summarise a video or podcast transcript

`summarize-video-transcript` · prompt · Summarisation · https://hermes-ide.com/prompts/summarize-video-transcript

Summarises a video or podcast transcript into key points with timestamps, exact quotes and a verdict on which parts are worth watching in full, without inventing times or claims.

````markdown
<context>
You summarise talks, interviews, lectures and podcasts so people can decide what deserves their time. Spoken material is padded: intros, sponsor reads, tangents, recaps and repeated points. The value sits in a few segments. A useful summary keeps the speaker's actual argument and evidence, points to where each idea is in the recording so the reader can jump there, quotes the lines that are worth having in the speaker's exact words, and says honestly which parts reward full viewing and which can be skipped.

Transcript:
<transcript>
[TRANSCRIPT]
</transcript>

</context>

<task>
1. Read the whole transcript. Identify the speakers, the format (talk, interview, panel, tutorial, lecture, narrative) and the main thesis or question. Note how the timestamps are written.
2. Segment it into topics. For each segment note the start timestamp as written in the transcript.
3. Extract the key points: the claims, ideas, steps or stories that carry the content, in the order they appear, each with its timestamp and speaker. Merge repeated points and keep the clearest occurrence.
4. Select three to six quotes that are worth keeping verbatim (a memorable framing, a precise claim, a strong example). Copy them exactly, with timestamp and speaker.
5. Judge what deserves full viewing: segments where a demo, visual, tone, worked example or detail is lost in summary. Give the timestamp range and why.
6. List factual claims that are surprising, specific (numbers, studies, named events) or contested, so the reader can check them before relying on them. Do not judge them true or false beyond saying they need checking.
7. List skippable parts: intros, sponsor reads, housekeeping, tangents, with ranges.

</task>

<constraints>
- Use only timestamps that appear in the transcript. If there are none, locate points by order and approximate position (for example "about a third of the way in") and say timestamps were not available. Never invent times.
- Quotes must be verbatim, including errors in auto-captions; mark obvious caption errors with [sic] or give the likely word in brackets.
- Attribute statements to the right speaker; if speakers are not labelled, say so and describe them by role ("the host", "the guest") only when the text makes it clear.
- Do not add facts, context or opinions the speakers did not give. Keep the speaker's hedges ("I think", "early data suggests").
- Keep the summary proportionate: about one key point per five to ten minutes of content, and a one-paragraph overview a busy reader can stop after.
- If the input is not a transcript, or is too short to summarise, say so.
</constraints>

<output_format>
## In one paragraph
Who, what, the main argument and the verdict (watch in full, watch parts, or the summary is enough).

## Key points
Table: Time | Speaker | Point.

## Quotes worth keeping
Bullets: "Quote" - Speaker, time.

## Worth watching in full
Table: Range | What it is | Why it is worth watching.

## Claims to check
Bullets, with time.

## Skip
Bullets with ranges, or "Nothing to skip".
</output_format>
````

---

<a id="summarize-email-thread"></a>

## Summarise an email thread

`summarize-email-thread` · prompt · Summarisation · https://hermes-ide.com/prompts/summarize-email-thread

Summarises a long email thread into where things stand now, the decisions made, open questions and who owes what to whom, so you can catch up or reply in minutes.

````markdown
<context>
You are an executive assistant who catches people up on threads they were copied into late. Long threads are tricky: the newest message can overturn an earlier agreement, replies quote earlier messages so the same text appears several times, people answer only part of a question, and silence is not agreement. You report the current state of play, with dates and names, so the reader can act without reading forty messages.

Thread:
<thread>
[THREAD]
</thread>

</context>

<task>
1. Put the messages in date order, ignore quoted copies of earlier messages, and note forwarded parts and who joined or left the thread.
2. Write where things stand now in 2–4 sentences: the topic, the current agreed position, and what is blocking progress, based on the latest relevant messages.
3. List decisions: what was agreed, by whom, and the date. If a later message changed or reopened a decision, show the latest state and mark the earlier one as superseded.
4. Build "who owes what": each open commitment or request, the person who owes it, to whom, the due date if stated, and whether it looks done, pending or overdue based on the thread.
5. List open questions: things asked but not answered, or answered by only some of the people asked.
6. Note important changes of position over the thread in a short timeline.
7. If the reader's role is given, say what they specifically need to do or reply to, and anything they are being asked that they may have missed.
</task>

<constraints>
- Do not treat silence as agreement, or a "sounds good" from one person as a group decision. Say who agreed.
- Use only names, dates, figures and commitments that appear in the thread; write "no date given" where none was set. Do not compute "overdue" unless a date was stated and a later message shows it passed.
- Keep exact figures, prices and dates. If two messages conflict, show both with their dates.
- Do not draft a reply unless asked; you may suggest the next step in one line under For you.
- If the text is not an email thread or is too fragmentary to follow, say so.
</constraints>

<output_format>
## Where things stand
2–4 sentences.

## Decisions
Bullets: decision · who · date. Superseded ones struck through or marked "superseded on <date>".

## Who owes what
Table: Who | Owes what | To whom | Due | Status.

## Open questions
Bullets, with who was asked.

## What changed along the way
Short dated timeline.

## For you
Only if a role was given: what you need to do, and the suggested next step.
</output_format>
````
