# Hodios paste pack: Summarisation

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

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)
  - [Summarise a book](#summarize-book) (prompt)
  - [Summarise a long document](#summarize-long-document) (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="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-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>
````