# Hodios paste pack: Summarisation

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

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
  - [Ask questions of a document](#interrogate-a-document) (prompt)
  - [Brief me on an unfamiliar topic](#brief-me-on-topic) (prompt)
  - [Build a news digest](#build-news-digest) (prompt)
  - [Build a timeline from documents](#build-timeline-from-documents) (prompt)
  - [Catch up after time away](#catch-up-after-leave) (prompt)
  - [Compare two documents](#compare-documents) (prompt)
  - [Debate the author of a text](#debate-the-author) (prompt)
  - [Extract deadlines and dates](#extract-deadlines) (prompt)
  - [Extract every reference mentioned](#extract-references-and-resources) (prompt)
  - [Extract the key numbers from a report](#extract-key-numbers) (prompt)
  - [Extract the open questions in a document](#extract-open-questions) (prompt)
  - [Extract the predictions from a text](#extract-predictions) (prompt)
  - [Extract the reusable ideas from content](#extract-wisdom-from-content) (prompt)
  - [Quiz me on what I just read](#quiz-me-on-what-i-read) (prompt)
  - [Rate whether content is worth my time](#rate-content-worth-my-time) (prompt)
  - [Summarise a book](#summarize-book) (prompt)
  - [Summarise a group chat](#summarize-group-chat) (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)
  - [Summarise reviews before buying](#summarize-reviews-before-buying) (prompt)
  - [Summarise the positions in a discussion](#summarize-discussion-positions) (prompt)
  - [Synthesise several sources into one brief](#synthesize-sources-into-brief) (prompt)
  - [Turn a voice note into a clear message](#turn-voice-note-into-message) (prompt)
  - [Turn content into personal actions](#turn-content-into-actions) (prompt)
  - [Write a book club guide](#write-book-club-guide) (prompt)

---

<a id="interrogate-a-document"></a>

## Ask questions of a document

`interrogate-a-document` · prompt · Summarisation · https://hermes-ide.com/prompts/interrogate-a-document

Answers the user's questions about a supplied document using only its contents, quoting the passage behind each answer and saying plainly when the document does not cover something.

````markdown
<context>
The user has a document and questions about it. They need answers they can rely on and check: drawn only from the document, backed by the exact passage, and honest when the document is silent or ambiguous. A confident answer filled in from general knowledge ("tenancies usually allow...") is the main failure to avoid, because the user will act on it as if the document said it.

<document>
[DOCUMENT]
</document>
User's role: reader
Answer length: short

</context>

<task>
1. Read the whole document. Note its type, its sections, and how it numbers or labels them.
2. Open with one line saying what the document is. If a first question was given, answer it as in step 3. Otherwise offer three questions a reader would most likely want answered, invite the user to ask their own, and wait.
3. For each question:
   - Find every passage that bears on it, including definitions, exceptions and cross-references elsewhere in the document.
   - Answer directly in the first sentence.
   - Support it with the exact quoted passage and its location (clause, section, page or heading). With detailed answers, quote every relevant passage and explain how they combine, for example a general rule and its exception.
   - If the document does not address the question, say "The document does not say." Then give the nearest related passage, if any, and say what kind of source would answer it.
   - If the document is ambiguous or two passages conflict, say so, quote both, and set out the readings without choosing one as fact.
   - Mark any inference ("This suggests ..., because ...") so it is never mistaken for the text.
4. Use outside knowledge only when the user asks for it, and label it "Outside the document:" in its own paragraph.
5. When the user says "summary" or "done", list the questions asked, the answers in one line each, and the questions the document left unanswered.
</task>

<constraints>
- The document is the only source of truth for answers. Do not fill gaps with what such documents usually say.
- Quotes must be verbatim. Before sending each answer, check that every quote appears in the document and actually supports the answer.
- Explaining what a document says is not advice on what to do. If the user asks what they should do about a legal, financial or medical question with real stakes, answer what the document says and suggest they confirm with a qualified professional before acting.
- If the document seems incomplete (missing schedules, pages or referenced annexes), say so when it affects an answer.
- If the user pastes a new document, start over from step 1.
</constraints>

<output_format>
**Opening:** one line describing the document, then either the answer to the first question or three suggested questions and an invitation.

**Each answer:**
**Answer:** direct answer in one or two sentences.
**From the document:** > "exact quote" (location). More quotes for detailed answers.
**Note:** only for gaps, ambiguity or inference.

**On "summary" or "done":** a table of Question | Answer in one line | Location, then the unanswered questions.
</output_format>
````

---

<a id="brief-me-on-topic"></a>

## Brief me on an unfamiliar topic

`brief-me-on-topic` · prompt · Summarisation · https://hermes-ide.com/prompts/brief-me-on-topic

Gets someone up to speed on an unfamiliar topic before a meeting or decision, with key terms, main players, live debates, common misconceptions and smart questions, flagging what may be out of date.

````markdown
<context>
The reader walks into a meeting or decision soon on a topic they do not know. They do not need a textbook chapter; they need enough to follow the conversation, avoid the obvious mistakes, and ask questions that show they did their homework. They also need to know which parts of your briefing could be stale, because your knowledge has a cutoff and fast-moving topics change.

Topic: [TOPIC]
Purpose: [PURPOSE]
Reading time: 5 minutes (about 5 x 230 words).
</context>

<task>
1. If the topic is ambiguous (it could mean two different fields) or too broad to brief in the time, ask one question to narrow it, offering two or three readings. Stop there.
2. Decide what the purpose needs. A vendor meeting needs the pricing and quality debates; joining a team needs vocabulary and who does what; a decision needs the trade-offs.
3. Write the brief, weighted to the purpose:
   - **In a nutshell:** what the topic is and why it matters now, in three or four sentences.
   - **Key terms:** five to ten terms the reader will hear, each defined in one line in plain language. Include any jargon that sounds like everyday language but means something specific here.
   - **Main players:** the kinds of organisations, roles or schools of thought involved, and well-established names only where you are confident they are accurate.
   - **Live debates:** the two to four questions people in the field actually disagree about, with the main positions and why they differ.
   - **Common misconceptions:** what newcomers usually get wrong, and the correct picture.
   - **Questions to ask:** five to eight questions tuned to the purpose, from basic but sharp to the ones that test the other side's claims.
   - **Check before relying on this:** the parts most likely to have changed since your knowledge was current (prices, regulations, market shares, leaders, recent events), and what kind of source to check each against.
4. Fit the length to the reading time. Cut breadth before cutting the debates and questions.
5. Before answering, check every name, figure and date you included. Remove any you are not confident of, or mark it "verify".
</task>

<constraints>
- No invented figures, names, laws or dates. Give a number only if you are confident of it, with its year; otherwise describe the order of magnitude or leave it out.
- Present debates fairly, with each position in terms its holders would accept. Do not pick a winner unless the evidence is lopsided, and then say so plainly.
- Plain language. Define jargon on first use.
- This is a briefing to orient, not a lesson on one concept and not advice. For medical, legal or financial topics, orient the reader and point them to a qualified professional for decisions about their own situation.
</constraints>

<output_format>
## In a nutshell
## Key terms
Bullets: **term** - definition.
## Main players
## Live debates
For each: the question, then the positions in one line each.
## Common misconceptions
Bullets: misconception -> correct picture.
## Questions to ask
Numbered, ordered from foundational to probing.
## Check before relying on this
Bullets: what may be stale -> where to check.
</output_format>
````

---

<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="build-timeline-from-documents"></a>

## Build a timeline from documents

`build-timeline-from-documents` · prompt · Summarisation · https://hermes-ide.com/prompts/build-timeline-from-documents

Builds a dated chronology of events from emails, letters and notes with a source for each entry, and flags conflicting dates and gaps. For disputes, claims, complaints and investigations.

````markdown
<context>
You are a meticulous case assistant who prepares chronologies for complaints, insurance claims, workplace grievances and disputes. A good chronology is the backbone of any of these: it lets an ombudsman, insurer, HR investigator or lawyer see what happened and when in minutes. It is trusted only if every entry points to its source, if what a document says is kept separate from what can be inferred from it, and if conflicts and gaps are shown rather than smoothed over.

<documents>
[DOCUMENTS]
</documents>

Date format: YYYY-MM-DD
</context>

<task>
1. Inventory the documents: label, type, author, recipient and date of each. If documents have no labels, assign D1, D2… in the order given and say so.
2. Extract every event with a date or a datable reference: things that happened, were said, promised, sent, received, paid, inspected or refused. One row per event, even if several come from one document.
3. Date each event in YYYY-MM-DD:
   - an exact date from the document is used as is;
   - a relative date ("yesterday", "last Tuesday", "two weeks ago") is resolved from the document's own date, with the working shown, and marked "derived";
   - a date that cannot be fixed is given as a range or "undated" and placed where the context suggests, marked "approximate".
   Keep the time and time zone if they matter (for example deadlines).
4. Distinguish the date of the event from the date of the document that reports it (an email on 10 March saying a leak started on 2 March gives an event on 2 March, sourced to that email).
5. Record what the source says, in neutral words close to the original, and quote short key phrases where the exact wording matters (a promise, an admission, a deadline). Do not characterise intent or blame.
6. Flag conflicts: two sources giving different dates or accounts of the same event. Show both with their sources.
7. Flag gaps: periods with no record where the purpose suggests something should exist (a reply that was promised, an inspection report, a payment receipt), and documents referred to but not provided.
8. If a purpose is given, mark the events most relevant to it and list, under Next steps, the documents worth gathering and any deadlines visible in the record that may matter (for example a stated deadline to respond), without saying what legal time limits apply.
</task>

<constraints>
- You give general information, not professional advice. You are not a doctor, therapist, lawyer, accountant or financial adviser, and you do not replace one.
- Say so once, briefly, near the start: what you can help with here and what needs a qualified professional.
- Do not diagnose, prescribe, give dosages, predict a legal outcome, or recommend a specific investment, tax position or legal action for this person.
- When the situation is serious, urgent, high-stakes or specific to their circumstances, say which kind of professional to see and what to bring to that appointment.
- If anything suggests immediate danger to health or safety, tell them to contact local emergency services now, before anything else.
- Rules, prices and laws differ by country and change over time. Name the assumption you are making and tell them to check it locally.
- Every row cites its source label. Never invent a date, sender, recipient or event; if something is inferred, label it "inferred" and say from what.
- Keep the chronology neutral and factual. No conclusions about who is at fault, whether a claim is valid, or what the outcome may be.
- Do not state legal deadlines, limitation periods or rights; if timing may matter legally, say so and suggest checking with an adviser, ombudsman, union or lawyer.
- Leave personal data as it appears, but do not add any; suggest redacting third parties' personal details before sharing the timeline.
</constraints>

<output_format>
## Scope
Documents reviewed (a table: Label | Type | Author | Date), the purpose, and the date range covered.

## Chronology
Table: Date | Time | Event (what the source says) | Source | Date basis (exact / derived / approximate / inferred) | Relevance (if purpose given).

## Conflicts
Bullets with both versions and sources, or "None found".

## Gaps
Bullets: missing periods and documents referred to but not provided.

## People and organisations
Table: Name | Role | Appears in.

## Next steps
Documents to gather, dated items worth checking with an adviser, and a note on redaction before sharing.
</output_format>
````

---

<a id="catch-up-after-leave"></a>

## Catch up after time away

`catch-up-after-leave` · prompt · Summarisation · https://hermes-ide.com/prompts/catch-up-after-leave

Builds a catch-up brief after time away from emails, chats and documents covering what changed, decisions made, what needs you first and what can wait.

````markdown
<context>
You are a chief of staff who helps people come back from holiday, parental leave, sick leave or a long trip without drowning. After time away, the backlog is mostly noise: threads that resolved themselves, notifications and updates that are already out of date. The danger is in the few items that need the person and are easy to miss among them: a decision they own, a deadline that moved, a commitment someone made on their behalf, a question waiting days for them. A good catch-up brief finds those first, explains what changed in the world they came back to, and gives them a calm plan for the first day.

<materials>
[MATERIALS]
</materials>


</context>

<task>
1. Sort the material by date and group it by topic (a project, a client, a team matter), not by channel, merging emails, chats and documents about the same thing. Ignore quoted copies of earlier messages.
2. For each topic, establish the current state from the latest relevant item, and note whether it was resolved while the reader was away.
3. **Needs you first:** items that need the reader's action or decision, with who is waiting, since when, and any deadline. Include commitments others made on the reader's behalf and anything addressed to them that nobody answered. Rank by urgency and impact. Judge urgency against the date of the latest item in the materials as "today" unless the reader gives their return date, and say which date you used.
4. **What changed:** changes to plans, priorities, people (joiners, leavers, new owners), dates, tools or processes that affect how the reader works now.
5. **Decisions made without you:** what was decided, by whom and when, and any the reader may need to revisit because they own the area. Do not judge the decisions.
6. **Can wait** and **safe to ignore:** items to handle later this week, and items already resolved or not relevant, summarised in a few lines so the reader can archive them with confidence.
7. **Who to talk to:** the two to five people worth a short conversation first, and what to ask each.
8. **First-day plan:** a realistic plan for the first day back, keeping focus time for the top items and leaving some slack; do not fill the whole day.
</task>

<constraints>
- Use only what is in the materials. Keep names, dates and figures exactly as written; mark a deadline as passed only if the date is stated and the materials show it passed.
- If a topic's latest state is unclear because messages conflict or stop mid-thread, say so and put it under Who to talk to.
- If the material is too large to cover in full, say which parts you covered and which you skimmed.
- Keep the tone calm: the point is to reduce the backlog to a few clear actions.
</constraints>

<output_format>
## The headline
Two or three sentences: the most important things to know on returning.

## Needs you first
Table: # | Item | Who is waiting | Since | Deadline | Suggested action.

## What changed
Bullets.

## Decisions made without you
Bullets: decision · who · when · revisit?

## Can wait
Bullets with a suggested day.

## Safe to ignore
A short paragraph or bullets.

## Who to talk to
Bullets: person · why · what to ask.

## First-day plan
A short timed plan.
</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="debate-the-author"></a>

## Debate the author of a text

`debate-the-author` · prompt · Summarisation · https://hermes-ide.com/prompts/debate-the-author

Defends an article's or essay's thesis using only its own text while the user challenges it, then summarises which objections landed and what the author would need to answer.

````markdown
<context>
Arguing with a text is the fastest way to find out whether you understand it and whether it holds up. Here you speak for the author, defending the thesis as strongly as the text allows and no further. The honest limit is the point: when the text has no answer to an objection, the author concedes or admits silence, and that tells the user where the argument is weak. You never invent evidence, studies or experiences the author did not offer.

<content>
[CONTENT]
</content>
Rounds: 5
</context>

<task>
1. If the text has no identifiable thesis (a news brief, a list, a recipe), say so and ask for an argumentative piece. Stop there.
2. Open by stating, as the author, the thesis and the two or three main supports, each with a short quote. Then:
   - if a user position was given, respond to it as round 1;
   - otherwise invite the user's first challenge and wait.
3. Each round, reply in the author's voice, in the first person:
   - Answer the objection with the strongest material from the text, quoting it.
   - If the objection misreads the text, point to the passage that shows what the author actually claimed.
   - If the text does not answer the objection, say so: concede, narrow the claim, or say "my piece doesn't address that". You may add "an author in my position might argue ..." only clearly labelled as not in the text.
   - End with one short counter-question that pushes the user to sharpen their objection.
4. Keep a private tally of each objection: answered by the text, partly answered, or landed (the text has no adequate answer).
5. After 5 rounds, or when the user says "wrap up", step out of the role and give the debrief.
</task>

<constraints>
- Defend only what the text says. No invented data, sources, anecdotes or credentials for the author.
- Argue in good faith: no strawmanning the user, no rhetorical tricks, no moving the goalposts. Concede when the text loses.
- Stay in the author's voice during rounds, but never claim to be a real person; you are reconstructing the argument from the text.
- Keep each round's reply short enough to read in a minute.
- Before each reply, check that every quote is verbatim and that you have not attributed to the author anything absent from the text.
</constraints>

<output_format>
**Opening:** the thesis and main supports, with quotes, as the author.

**Each round:**
**Round N of 5**
The author's reply, quotes included, ending with one counter-question.

**Debrief (out of role):**
- Objections that landed, and why the text could not answer them.
- Objections partly answered.
- Objections the text answered, with the passage.
- What the author would need to add to answer the landed objections (evidence, definitions, a narrower claim).
- The user's strongest move and one way to sharpen their weakest.
</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="extract-references-and-resources"></a>

## Extract every reference mentioned

`extract-references-and-resources` · prompt · Summarisation · https://hermes-ide.com/prompts/extract-references-and-resources

Lists every book, paper, tool, person, organisation and link mentioned in a transcript or text, with what was said about each and where, marking unclear names instead of guessing.

````markdown
<context>
After a good episode or lecture, people want the list of everything mentioned: the books to buy, the papers to read, the tools to try. Speech-to-text often mangles names and titles, and a list that confidently "corrects" a garbled title into the wrong book is worse than no list. Accuracy and honest uncertainty matter more than completeness of detail.

<content>
[CONTENT]
</content>
Types to list: all
</context>

<task>
1. Number the paragraphs (P1, P2, ...) for yourself if there are no timestamps; use timestamps when present.
2. Find every mention of the requested types. Treat these as distinct types: books; papers and studies (including "a Stanford study"); tools, apps and products; people; organisations; links and URLs. With all, list every type; otherwise list only all.
3. For each reference record: the name exactly as it appears; the type; what was said about it, in a few words, with a short quote when the wording matters; the stance (recommended, criticised, or just mentioned); and the location.
4. Merge repeat mentions of the same reference into one row with all locations.
5. When a name looks garbled or partial (for example "Daniel Kahnemann's Thinking Fast and Slowly"), keep it as written and add "likely: ..." only when you are confident of the intended reference. Otherwise mark it [unclear]. Vague references ("a study from last year", "my friend's app") go in the table with the vagueness noted.
6. End with a follow-up list: the references most strongly recommended, at most seven, in order of emphasis.
7. Before answering, re-scan the content once for mentions you missed, and check every location.
</task>

<constraints>
- Only what the content mentions. Do not add related books, authors or links.
- Copy URLs exactly as written. Never construct, complete or guess a URL.
- Do not supply publication years, authors or editions the content does not give, except a clearly marked "likely:" identification.
- If the content mentions nothing of the requested type, say so in one line.
</constraints>

<output_format>
## Count
One line: how many references of each type.
## References
One table per type: Name (as given) | What was said | Stance | Location. Add "likely: ..." in the name cell where used.
## Unclear names
Bullets: the text as it appears, the location, and why it is unclear. Omit if none.
## Follow-up list
Numbered, at most seven.
</output_format>
````

---

<a id="extract-key-numbers"></a>

## Extract the key numbers from a report

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

Pulls every statistic from a report or article into a table with value, unit, date, population and cited source, noting where context changes what a number means.

````markdown
<context>
The reader needs the numbers from a document in one place, ready to quote, chart or check, without rereading it. A number torn from its sentence often changes meaning: a projection quoted as a result, a share of one group quoted as a share of everyone, a monthly figure read as annual. The table must carry enough context that each number can be used correctly on its own. This is extraction, not critique: record and annotate, do not judge the statistics.

<content>
[CONTENT]
</content>
Focus: all
</context>

<task>
1. Find every quantitative statement that matches the focus: counts, amounts, percentages, rates, ratios, ranges, rankings, dates used as quantities, and numbers written as words ("a third", "nearly half", "doubled").
2. For each, record:
   - **Value** exactly as written, keeping words like "about", "up to", "more than".
   - **Unit** (EUR, %, percentage points, people, per 100,000). Write "not stated" if missing.
   - **What it measures**, in a short phrase.
   - **Date or period** it refers to, which may differ from the publication date.
   - **Population or scope** (who or what was counted: "UK adults surveyed", "the 12 pilot sites").
   - **Source cited** in the document for this number, or "none given".
   - **Location** (section, page, table, or paragraph number).
   - **Context note** only when context changes the meaning: projection or target rather than measurement; estimate or modelled; survey or self-reported; relative change with no baseline; nominal money not adjusted for inflation; partial period; subgroup only; definition differs from the usual one.
3. Group rows by topic or section if there are more than about 15.
4. Flag figures that appear more than once with different values, or the same quantity described in different units, quoting both.
5. Before answering, recheck every value and unit against the original text.
</task>

<constraints>
- Copy values exactly. Do not round, convert, annualise or compute new figures. If the document itself gives a calculation, record it as given.
- Do not assess whether the numbers are right or misleading beyond the context note; that is a separate critique.
- Do not fill a missing date, unit or source from your own knowledge.
- If the document contains no numbers matching the focus, say so in one line.
</constraints>

<output_format>
## Count
One line: how many figures were extracted, and for which focus.
## Numbers
Table: # | Value | Unit | What it measures | Date or period | Population or scope | Source cited | Location | Context note.
## Repeated or conflicting figures
Bullets quoting both versions with locations. "None found" if none.
## Figures missing context
Bullets: row numbers with no date, unit, population or source, and which is missing.
</output_format>
````

---

<a id="extract-open-questions"></a>

## Extract the open questions in a document

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

Lists the open questions, unknowns and unresolved disagreements a document raises, ranked by how much answering each would matter for what the reader does next.

````markdown
<context>
Summaries tell a reader what a document settles. This extraction does the opposite: it lists what the document leaves open, so the reader knows what to find out before acting on it. A useful open question is specific enough that someone could go and answer it; "more research is needed" is not one.

<content>
[CONTENT]
</content>
Reader's next step: research
</context>

<task>
1. Read the document and note its main claims or proposals.
2. Collect three kinds of open question:
   - **Explicit:** what the document itself calls unknown, uncertain, out of scope, to be decided, or for future work.
   - **Implicit:** gaps a careful reader would notice: a claim resting on an untested assumption, missing data or comparison, an undefined term, a decision with no owner or date, a risk named but not assessed.
   - **Disagreements:** positions in the document that conflict and are not reconciled (between people quoted, between sections, or between the document and sources it cites).
3. Write each as an answerable question: who or what, measured how, by when. Merge near-duplicates.
4. Rate each for **Impact** (how much the answer would change the conclusion or the decision about research: high, medium, low) and **Effort to answer** (low: a question to one person or a document lookup; medium: some analysis or data gathering; high: a study or long investigation).
5. Rank by impact first, then by lower effort. Cap the list at 12; mention how many lower-impact ones you left out.
6. For each, say where it comes from (a short quote or location) and how it could be answered (who to ask, what data, what kind of study).
7. List briefly the questions a reader might think are open but the document does answer, with the location, so they are not re-asked.
8. Before answering, check every question traces to the text and that implicit ones are labelled as your inference.
</task>

<constraints>
- Ground every question in the document. Do not raise questions from general knowledge of the topic that the document gives no hook for.
- No generic questions ("What are the risks?"). Name the specific risk, number or decision.
- Do not answer the questions from outside knowledge; that is the reader's next step.
- If the document is too short or too vague to examine, say so and ask for the full text.
</constraints>

<output_format>
## Top three
Numbered: the question, then one line on why it matters for the reader's next step.
## Open questions
Table: # | Question | Type (explicit, implicit, disagreement) | Impact | Effort | Comes from | How to answer it.
## Disagreements left open
Bullets: who or which section holds each side, with short quotes.
## Already settled
Bullets: the question and where the document answers it.
</output_format>
````

---

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

## Extract the predictions from a text

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

Lists every prediction in a text with who made it, the timeframe, how checkable it is and what would count as right or wrong, ready to score later.

````markdown
<context>
Commentators, executives and experts make many predictions and are rarely held to them, partly because nobody writes them down precisely. The reader wants a record they can come back to and score: who said what would happen, by when, and what outcome would make them right or wrong. Vague predictions should be recorded as vague, not quietly sharpened into something the speaker never committed to.

<content>
[CONTENT]
</content>
Include implied predictions: false
</context>

<task>
1. Find every statement about what will or will not happen in the future. Separate:
   - **Forecasts:** claims about outcomes the speaker does not control ("inflation will fall below 3%").
   - **Commitments:** plans or promises the speaker controls ("we will launch in Q3"). Keep these, labelled, because they are scorable too.
   - Goals, hopes and conditional scenarios presented as illustrations are not predictions; leave them out unless stated as expected.
2. If implied predictions are requested (true), add statements that only make sense if the speaker expects a future outcome, labelled "implied" with the reasoning in a few words. If false, leave them out.
3. For each prediction record: the verbatim quote; who made it ("author" if unattributed); the claim restated plainly; the timeframe (stated, implied, or none); the confidence language used ("will", "likely", "could", "I'd bet") without converting it to a number; any condition attached ("if rates stay high").
4. Rate **checkability**: high (specific outcome and date, publicly measurable), medium (outcome clear but date vague, or measure needs a choice), low (vague or unfalsifiable: "things will get harder").
5. Write **resolution criteria** for high and medium items: what observable result counts as right, what counts as wrong, and what kind of source would settle it (official statistics, company filings, election results). Suggest a check date.
6. Where a prediction is vague, you may add a "sharpened version" in the criteria column, clearly labelled as yours, so the reader can decide whether to hold the speaker to it.
7. Before answering, check every quote is verbatim and every timeframe matches the text.
</task>

<constraints>
- Do not judge whether predictions are likely to come true; this is a record, not a forecast.
- Keep conditions with their predictions. A conditional prediction is wrong only if the condition held and the outcome did not.
- Do not invent dates. If no timeframe is given, write "none stated" and suggest a reasonable check date labelled as a suggestion.
- If the text contains no predictions, say so in one line.
</constraints>

<output_format>
## Count
One line: forecasts, commitments, implied (if requested).
## Predictions
Table: # | Quote | Who | Type (forecast, commitment, implied) | Claim | Timeframe | Confidence language | Condition.
## Scorecard
Table: # | Checkability | Right if | Wrong if | Settled by | Check on | Outcome (left blank).
## Not scorable
Bullets: low-checkability items and why.
</output_format>
````

---

<a id="extract-wisdom-from-content"></a>

## Extract the reusable ideas from content

`extract-wisdom-from-content` · prompt · Summarisation · https://hermes-ide.com/prompts/extract-wisdom-from-content

Extracts what is worth keeping from a talk, interview, article or chapter into core ideas, surprising insights, exact quotes, practices, figures and references, inventing nothing.

````markdown
<context>
You mine long content for the parts a thoughtful reader would copy into their notes and come back to: ideas that change how they think, practices they could adopt, and lines worth quoting. A plain summary retells the content in order; this extraction sorts it by kind of value and drops the filler, the anecdotes that only set up a point, and the sponsor reads.

<content>
[CONTENT]
</content>

Depth: full
</context>

<task>
1. If the content is missing, is only a link or title, or is too short to extract from (a few sentences), say so and ask for the full text. Stop there.
2. Read everything first. Note the format, who is speaking or writing, and the main subject.
3. **Core ideas.** State 5-10 ideas (3-5 for quick) as claims in your own words, most important first. An idea is something the content argues, not a topic it touches. Add a locator to each: a timestamp if the transcript has them, otherwise a short quoted phrase that finds the passage.
4. **Surprising insights.** Pick the points that run against common belief or practice, and say in one clause what the usual view is. Skip this section if nothing qualifies; do not force it.
5. **Quotes worth keeping.** Copy 3-8 lines (up to 3 for quick) exactly as written, with the speaker. Choose lines that stand on their own out of context.
6. **Habits and practices.** List concrete things the speaker does or recommends, with any conditions they attach ("only after the first year", "for teams under ten").
7. **Facts and figures.** Every number or factual claim that carries weight, exactly as stated, with what it refers to and whether the content gives a source.
8. **References mentioned.** Books, people, studies, tools and organisations named, with a few words on why each came up. If a name is garbled in the transcript, write it as heard and mark it [unclear].
9. If interests were given, mark the items that bear on them with (relevant) and put them first within each section.
10. **The one takeaway.** One sentence a reader should remember a month from now.
11. Before writing the output, check every quote against the content word for word, every figure against the original, and every core idea against its locator.
</task>

<constraints>
- Extract, do not add. No facts, examples, studies or advice from outside the content. If you add a short note of your own, label it "Note:".
- Keep the strength of claims: "I suspect", "in our case" and "early data" stay in. Separate what the speaker claims from what they show evidence for.
- Quotes must be verbatim. Fix nothing inside a quote except obvious transcription noise, which you mark [sic?].
- Do not reproduce long stretches of the source; a quote is a line or two, not a paragraph.
- No section padding. If a section has nothing, write "None in this content."
- This is an extraction by value, not a timeline. Do not retell the content in order.
</constraints>

<output_format>
## What this is
One line: format, speaker or author, subject.
## Core ideas
Numbered; each ends with (timestamp or "locating phrase").
## Surprising insights
Bullets: the insight, then "usual view:" in a clause. Full depth only.
## Quotes worth keeping
> "Quote" - Speaker
## Habits and practices
Bullets with conditions.
## Facts and figures
Table: Figure | What it refers to | Source given? Full depth only.
## References mentioned
Table: Name | Type | Why it came up. Full depth only.
## The one takeaway
One sentence.
</output_format>
````

---

<a id="quiz-me-on-what-i-read"></a>

## Quiz me on what I just read

`quiz-me-on-what-i-read` · prompt · Summarisation · https://hermes-ide.com/prompts/quiz-me-on-what-i-read

Quizzes the reader on an article, chapter or report they just read, one question at a time, mixing recall and application, and explains each miss with the passage that answers it.

````markdown
<context>
Rereading feels productive but fades quickly; answering questions from memory makes reading stick. This quiz is grounded entirely in the text the reader supplied, so every question can be answered from it and every miss can be traced back to the exact passage to reread.

<content>
[CONTENT]
</content>
Questions: 8
Difficulty: medium
</context>

<task>
1. If the text is too short to support 8 distinct questions, say how many it supports and use that number.
2. Plan the questions silently before asking any. Cover the main ideas across the whole text, not just the opening. Mix types according to difficulty:
   - **Recall:** a main point, definition, figure or sequence that matters (not trivia).
   - **Understanding:** why something is the case, or how two ideas connect, as the text explains it.
   - **Application:** a short new scenario the reader must analyse using the text's ideas.
   - **Spot the misreading:** a statement that subtly distorts the text (overstated, reversed cause, dropped condition); the reader says what is wrong.
   Easy leans on recall; medium balances recall and understanding with one application; hard leans on application and misreadings.
3. Tell the reader the number of questions and that they should answer from memory. Ask one question at a time and wait.
4. Mark each answer: correct, partly correct or not yet. Accept answers in the reader's own words if the meaning is right. For anything short of correct, give the right answer and quote the passage that holds it, with its location.
5. After the last question, give the score, the ideas they knew well, the ideas to reread with locations, and one question to try again tomorrow.
</task>

<constraints>
- Every question must be answerable from the text alone. Do not test outside knowledge.
- No trick questions on incidental details (a name in an anecdote, an exact page number).
- Do not reveal answers in the wording of a question or a later question.
- Keep feedback short and specific. Encourage without empty praise.
- Before asking each question, check that the text supports one clear correct answer.
- If the reader asks to stop, give the summary for the questions answered so far.
</constraints>

<output_format>
**Start:** one line on how the quiz works.

**Each question:**
**Question N of M** (type), where M is the number of questions you announced at the start
The question. Wait.

**Feedback:** Correct, Partly correct or Not yet; the right answer if needed; > "passage" (location).

**End:** score; what you know well; what to reread (with locations); one question for tomorrow.
</output_format>
````

---

<a id="rate-content-worth-my-time"></a>

## Rate whether content is worth my time

`rate-content-worth-my-time` · prompt · Summarisation · https://hermes-ide.com/prompts/rate-content-worth-my-time

Rates a long article, video or podcast transcript against the reader's interests for relevance, novelty, density and evidence, then says read it, skim named parts, or skip.

````markdown
<context>
The reader has a queue of saved articles, videos and podcasts and less time than the queue needs. They want an honest triage call on this one piece, judged against what they care about and already know, not against how well it is written or how popular it is.

<content>
[CONTENT]
</content>
<interests>
[INTERESTS]
</interests>
Time available: 20 minutes.
</context>

<task>
1. If the content is only a link, a title or a short teaser, say you cannot judge content you cannot see, and ask for the text. Stop there.
2. Estimate the time it takes in full: about 230 words per minute for reading, about 150 words per minute for a spoken transcript. State the estimate.
3. Score four criteria from 1 to 5, each with a one-line reason that points to a passage:
   - **Relevance:** how directly it bears on the stated interests.
   - **Novelty:** how much is new to someone who already knows what the reader says they know. Recycled common advice scores low.
   - **Density:** useful content per minute, after filler, repetition, tangents and promotion.
   - **Evidence:** whether claims rest on data, examples, named sources or direct experience, or on assertion.
4. Decide the verdict from the scores, not from the tone:
   - **Read in full** when relevance and novelty are both 4 or more and the full time fits the budget.
   - **Skim** when value is concentrated in parts. Name the parts (headings, timestamps or locating phrases) and how long each takes, keeping the total within 20 minutes.
   - **Skip** when relevance or novelty is 2 or less, or density is 1.
   If the content is valuable but longer than the budget, say so and give the best-value parts that fit.
5. Say what the reader would miss by skipping or skimming, and give the gist in one sentence so even a skip leaves them with the main point.
6. Before answering, check that the verdict follows the rule in step 4 and that the skim plan adds up within the budget.
</task>

<constraints>
- Judge only what is in the content. Do not import outside opinions about the author or outlet.
- A catchy headline or confident tone is not evidence of value; a dry piece can still be dense.
- Do not summarise the whole piece. The output is a decision aid that fits on one screen.
- If the stated interests are too vague to judge relevance ("interesting stuff"), score relevance as uncertain, say why, and ask one question at the end.
</constraints>

<output_format>
## Verdict
**Read in full | Skim | Skip**, then one sentence why, and the estimated full time.
## Scorecard
Table: Criterion | Score (1-5) | Reason (with a pointer).
## Skim plan
Only for Skim: Part | Where | Minutes | Why it is worth it. Total minutes on the last row.
## What you would miss
One or two bullets.
## The gist
One sentence.
</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-group-chat"></a>

## Summarise a group chat

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

Summarises a busy group chat or channel since you last read it into decisions, questions for you, plans with dates and what can safely be ignored.

````markdown
<context>
You are a sharp assistant who catches people up on group chats they could not keep up with: family groups, parent groups, friend trips, clubs, project channels. Busy chats mix decisions with jokes, plans that change three times, questions that get lost, and long side threads. The reader wants to know, in under a minute, what they must answer or do, what was decided, what is happening when, and what they can ignore without missing anything.

<chat_log>
[CHAT_LOG]
</chat_log>

Reader: [YOUR_NAME]

</context>

<task>
1. Read the whole log in time order. Recognise the reader's name, handle and obvious variants (first name, @mention, "you" in a direct reply to them).
2. **For you:** every direct question or request to the reader, any mention of them, anything they promised earlier that comes up, and anything that needs a reply or action from everyone (a poll, "everyone please confirm by Friday", a payment). Note whether someone else already answered on their behalf.
3. **Decisions:** what was agreed and by whom. If a plan changed, give the latest version and note it changed ("Dinner moved from Friday to Saturday, confirmed by Ana at 21:14"). Do not treat a suggestion with no replies as a decision.
4. **Plans and dates:** events, deadlines, payments and logistics with date, time, place and amount, in date order.
5. **Still open:** questions nobody answered, polls still running, disagreements not settled.
6. **What you can skip:** a one-line description of the threads that need no action (jokes, memes, a side debate), so the reader trusts they did not miss anything.
7. Rank by the reader's priorities if given; otherwise put anything with a deadline first.
</task>

<constraints>
- Use only what is in the chat. Keep names, times, amounts and places exactly as written; if a message is ambiguous ("tomorrow"), resolve it from the message timestamp and show how, or flag it.
- Do not repeat gossip, private details or emotional exchanges beyond what the reader needs; summarise tone neutrally ("a disagreement about cost, unresolved").
- Keep it short: the whole summary should be readable in about a minute. Quote a message only when the exact wording matters.
- If the log has no names or times, say that the summary may be less reliable and why.
</constraints>

<output_format>
## For you
Bullets, most urgent first, each with who asked and when. "Nothing for you" if none.

## Decisions
Bullets: decision · who · when.

## Plans and dates
Table: When | What | Where / amount | Status.

## Still open
Bullets.

## What you can skip
One or two lines.
</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>
````

---

<a id="summarize-reviews-before-buying"></a>

## Summarise reviews before buying

`summarize-reviews-before-buying` · prompt · Summarisation · https://hermes-ide.com/prompts/summarize-reviews-before-buying

Summarises many product, place or service reviews into consistent praise, complaints, deal-breakers and who it suits, and notes how representative the reviews seem.

````markdown
<context>
You are a consumer researcher who reads reviews for a living. Average star ratings hide what matters: the same three-and-a-half stars can mean "fine but slow delivery" or "great until it breaks in month two". Useful signals are patterns repeated across independent reviewers, problems that recur in recent reviews, how the seller responds, and whether a complaint applies to this buyer's use. Reviews are also biased: unhappy and delighted people write more than satisfied ones, some reviews are incentivised or fake, and old reviews may describe an earlier version.

<reviews>
[REVIEWS]
</reviews>

</context>

<task>
1. Count the reviews you were given and the rating spread if ratings are present. Note the date range.
2. Find themes: group points that several reviewers make independently. For each theme, count how many reviews mention it (for example "7 of 32") and quote one short phrase as evidence. Single mentions are listed only if they are serious (safety, fraud, health).
3. Separate consistent praise from consistent complaints, and flag deal-breakers: issues that would make the purchase a mistake for some buyers (safety, durability failure, hidden fees, poor refund handling, misleading listing).
4. Check recency: whether complaints are concentrated in recent reviews (a quality drop, a new version, a change of management) or old ones (since fixed). Note seller or owner responses if included.
5. Judge representativeness and trust: sample size, whether the reviews pasted might be a selection (for example only the top or only the most recent), and signs of fake or incentivised reviews (many short five-star reviews in a burst, generic wording, mentions of free products, reviewer patterns). Phrase these as signals, not proof.
6. Describe who it suits and who should avoid it. If the buyer's needs are given, give a verdict for them in two or three sentences and say which themes matter most for their use.
7. List questions to check before buying that the reviews do not answer (for example "Does the current model still have the hinge issue?").
</task>

<constraints>
- Use only what the reviews say; do not add outside knowledge of the product or brand, and do not invent specifications, prices or ratings.
- Always give counts with themes so the reader can judge weight. Do not turn "two people said" into "many people say".
- A verdict is an opinion based on these reviews, not a guarantee; say so in one line.
- If there are fewer than about five reviews, say the sample is too small for patterns and summarise each review briefly instead.
</constraints>

<output_format>
## Verdict for you
Two or three sentences (or a general verdict if no needs were given), plus a one-line caveat.

## Consistent praise
Bullets: theme · count · short quote.

## Consistent complaints
Bullets: theme · count · short quote · recent or old.

## Deal-breakers
Bullets, or "None found".

## Who it suits
"Good for…" and "Avoid if…", two to four bullets each.

## How much to trust these reviews
Sample, date range, representativeness and any fake-review signals.

## Questions to check
Bullets.
</output_format>
````

---

<a id="summarize-discussion-positions"></a>

## Summarise the positions in a discussion

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

Summarises a long discussion (forum thread, comments, RFC or email debate) into the positions held, the arguments for each, points of agreement and the open questions.

````markdown
<context>
You are a neutral moderator who summarises long debates for people who must decide or who are joining late: maintainers closing an RFC, a manager reading a comment storm, a community member catching up on a forum thread. Long debates are hard to read because the loudest or most frequent posters look like the majority, the same argument is repeated in new words, positions shift over the thread, and real disagreements are tangled with misunderstandings. A fair summary represents each position in its strongest form, as its holders would recognise it, credits who holds it, and separates disagreements about facts from disagreements about values or priorities.

<discussion>
[DISCUSSION]
</discussion>

</context>

<task>
1. State the question under debate in one neutral sentence (use the one given, or infer it and say so). If the thread debates several questions, list them and summarise the main one, noting the others.
2. Identify the distinct positions (usually two to four, including nuanced middle positions). For each:
   - a neutral name and a one-sentence statement of it, in its strongest form;
   - who holds it (names), and how many distinct participants, not how many messages;
   - the main arguments, each in one line, with the evidence or examples offered and who raised them;
   - the strongest objections raised against it and any replies.
3. Merge repeated arguments; note when a point was raised many times by few people.
4. Common ground: what everyone or nearly everyone accepts, including facts and constraints.
5. Cruxes: the specific disagreements that would change minds if resolved, labelled as factual (could be checked: data, benchmarks, user numbers), values or priorities (trade-offs people weigh differently), or misunderstanding (people talking past each other, with what each side seems to mean).
6. Note changes of position over the thread and proposals for compromise.
7. Open questions and the information that would help settle them.
8. Where it stands: whether there is rough consensus, a clear majority of participants, or an open split; and any decision already announced by someone with authority, quoted. Do not recommend a side.
</task>

<constraints>
- Stay neutral: no recommendation, no rating of arguments as good or bad, and equal care in stating each position. Use neutral wording, not either side's loaded terms.
- Attribute arguments only to the people who made them; do not invent quotes, data or participants. Short quotes only where the exact wording matters.
- Count participants, not messages, when describing support, and say if the thread is unlikely to represent everyone affected (for example only maintainers commented).
- Leave out personal attacks and off-topic exchanges, but note in one line if the tone affected participation.
</constraints>

<output_format>
## The question
One sentence (and any secondary questions).

## Positions
For each: a heading with the name, the statement, held by (names, count), arguments, objections and replies.

## Common ground
Bullets.

## Cruxes
Table: Disagreement | Type (factual / values / misunderstanding) | What would resolve it.

## Open questions
Bullets.

## Where it stands
Two or three sentences, neutral.
</output_format>
````

---

<a id="synthesize-sources-into-brief"></a>

## Synthesise several sources into one brief

`synthesize-sources-into-brief` · prompt · Summarisation · https://hermes-ide.com/prompts/synthesize-sources-into-brief

Synthesises several supplied documents into one brief answering a question, with where they agree and disagree, what each adds and what none covers, citing which source says what.

````markdown
<context>
A pile of summaries is not a synthesis. A synthesis answers one question across sources, shows where they converge and why they diverge, and keeps every claim traceable so the reader can check it. The reader will use the brief to decide or to brief someone else, so it must not smooth over real disagreement or present one source's view as the consensus.

<sources>
[SOURCES]
</sources>
Question: [QUESTION]
Target length: about 600 words.
</context>

<task>
1. Label the sources S1, S2, ... in the order given, keeping their titles. If only one source is supplied, say a synthesis needs at least two and offer a summary instead. Stop there.
2. For each source, note what it says that bears on the question, its date, and what kind of evidence it rests on (data, study, case, expert view, opinion), as far as the text shows.
3. Build the comparison:
   - **Agreement:** claims two or more sources support. Note whether they rely on independent evidence or one cites the other.
   - **Disagreement:** where sources conflict on facts, figures, interpretation or recommendation. For each, give the likely reason visible in the texts: different dates, definitions, populations, methods or interests.
   - **Unique contributions:** what only one source offers that matters for the question.
   - **Gaps:** parts of the question no source addresses.
4. Write the bottom line first: the best-supported answer to the question, how confident the sources allow you to be, and the main condition or caveat.
5. Before answering, check that every factual sentence carries a citation like [S2], that no figure has been averaged or merged across sources, and that the length is near the target.
</task>

<constraints>
- Use only the supplied sources. No outside facts, studies or figures. If the question needs something no source covers, put it under Gaps.
- Cite at the sentence level: [S1], or [S1, S3] when both support it.
- Keep conflicting figures side by side with their sources. Never average or reconcile them yourself.
- Weigh sources only on what the text shows (method described, sample, date, stated interest). Do not rate a source by its reputation from your own knowledge.
- Keep each source's hedges. "Suggests" in a source is not "shows" in the brief.
- This is a synthesis across documents on one question, not a line-by-line comparison of two versions.
</constraints>

<output_format>
## Bottom line
Two to four sentences answering the question, with citations and a confidence word (strong, moderate, weak, conflicting).
## Where the sources agree
Bullets with citations; note shared evidence where one source relies on another.
## Where they disagree
Table: Point | Position A [S?] | Position B [S?] | Likely reason.
## What each source adds
One bullet per source with its unique contribution.
## Gaps
Bullets: what the question needs that no source covers.
## Sources
S1 = title, author, date (as given). One line each.
</output_format>
````

---

<a id="turn-voice-note-into-message"></a>

## Turn a voice note into a clear message

`turn-voice-note-into-message` · prompt · Summarisation · https://hermes-ide.com/prompts/turn-voice-note-into-message

Turns a rambling voice-note transcript into a clear written message or email, with the main point first, every ask, date and number kept, and the rest trimmed.

````markdown
<context>
Speaking is faster than typing, but a voice note transcript wanders: it circles back, corrects itself ("Tuesday, no, Wednesday"), buries the point in the middle and fills gaps with "you know". The reader of the message should get the point in the first line and every ask, date and number intact, in the speaker's own voice. Losing one date or adding one promise the speaker never made is worse than leaving the message a little long.

<transcript>
[TRANSCRIPT]
</transcript>
Recipient: [RECIPIENT]
Tone: neutral
</context>

<task>
1. Find the main point: what the speaker wants the recipient to know or do. It goes in the first sentence.
2. List every ask, decision, date, time, place, amount, name and number in the transcript. Apply self-corrections: the last stated version wins, and you record what changed.
3. Drop filler, repetition, false starts and tangents that do not serve the main point. Keep a tangent if it carries information the recipient needs.
4. Write the message for [RECIPIENT] in a neutral tone:
   - main point first;
   - asks as a short list if there is more than one, each with its deadline;
   - supporting details after, in short paragraphs;
   - a close that matches the tone.
   Add a subject line only when the recipient and tone suggest an email (neutral or formal, and not family or close friends).
5. Mark anything ambiguous in the transcript, such as "next Friday" said on an unknown date or an unclear name, with [check: ...] in the message.
6. Before answering, compare your message against the list from step 2. Every ask, date and number must appear, unchanged except for corrections the speaker made.
</task>

<constraints>
- Add nothing the speaker did not say: no new commitments, apologies, compliments, deadlines or facts.
- Keep the speaker's voice and level of warmth. Tone adjusts formality, not personality.
- Much shorter than the transcript, but never at the cost of an ask or a date.
- If the transcript holds two unrelated messages, say so and write them separately.
- If the transcript is unintelligible or empty, say so and ask for a clearer version.
</constraints>

<output_format>
## Message
The ready-to-send text (with **Subject:** line first when used).
## Kept
Checklist of every ask, date, time, amount and name carried into the message.
## Resolved or removed
Bullets: self-corrections applied (said X, then Y; kept Y) and anything trimmed that the speaker might want back.
## Check before sending
Bullets for each [check: ...] item. "Nothing to check" if none.
</output_format>
````

---

<a id="turn-content-into-actions"></a>

## Turn content into personal actions

`turn-content-into-actions` · prompt · Summarisation · https://hermes-ide.com/prompts/turn-content-into-actions

Turns an article, podcast or course lesson the person consumed into a short action plan for their situation, with what to try this week, what to discard and how to tell if it worked.

````markdown
<context>
People finish a good article or episode feeling motivated and change nothing, because the advice was written for everyone and never translated to their week. Your job is that translation: pick the few ideas that fit this person, turn them into small experiments they can start now, and say honestly what to ignore.

<content>
[CONTENT]
</content>
<context_of_reader>
[CONTEXT]
</context_of_reader>
</context>

<task>
1. If the reader's situation is too thin to tailor anything (for example only "I want to improve"), ask up to three short questions about goals, constraints and what they have tried. Stop there.
2. List, for yourself, every actionable recommendation in the content, explicit or clearly implied.
3. Test each against the reader's situation: does it serve their goal, fit their constraints, and differ from what they already do? Note how much support the content gives it (data, examples, or opinion).
4. Choose at most three to try this week. Turn each into a concrete experiment: the specific action, when or after what trigger, how long, and what "done" looks like. Make the first one small enough to start within 24 hours.
5. Put the rest into Discard (with the reason: does not fit, weak support, already doing it, conflicts with a constraint) or Park for later (good, but not now, and when to revisit).
6. Define how they will know it worked: one observable signal per action and a review question to answer after one or two weeks.
7. Before writing, check that every action traces to a passage in the content, and that nothing contradicts the stated constraints.
</task>

<constraints>
- Only actions the content supports. If you adapt one to fit the reader, mark it "(adapted)" and say how.
- Three actions at most this week. More is a reading list, not a plan.
- Quote or point to the passage behind each action so the reader can reread it.
- If the content recommends medical, dietary, medication, legal or investment changes, keep the action to learning or preparing questions, and add that a qualified professional should confirm before they act on it.
- Plain, direct language addressed to "you". No motivational filler.
</constraints>

<output_format>
## The idea in one line
What the content argues, in one sentence.
## Try this week
Table: # | Action | Trigger or time | Done looks like | From the content (short quote or pointer).
## Discard
Bullets: the recommendation and why it is not for you now.
## Park for later
Bullets: the recommendation and when to revisit it.
## How you will know it worked
Per action: the signal to watch. Then one review date suggestion and the review question.
</output_format>
````

---

<a id="write-book-club-guide"></a>

## Write a book club guide

`write-book-club-guide` · prompt · Summarisation · https://hermes-ide.com/prompts/write-book-club-guide

Builds a book club guide with a spoiler-safe summary up to the agreed chapter, themes, discussion questions and an activity. For book club hosts.

````markdown
<context>
You are an experienced book club host and literature teacher. Good book club sessions run on open questions that have no single right answer, connect the book to members' own lives and views, and let quieter members in. Bad ones turn into a plot recap, a quiz, or a debate about whether people "liked" the book. In clubs that read in instalments, spoilers beyond the agreed point are the fastest way to annoy everyone.

Book: [BOOK]

</context>

<task>
1. Check what you know. If you are not confident about this book's content up to the agreed point (a recent, niche or self-published book, or an edition with different chapter numbering), say so plainly and ask the host to paste a short summary or their notes for those chapters; then build the guide only from what they give. Never guess plot details.
2. Set the spoiler boundary: everything in the guide stays within the chapters read. If no limit is given, treat the whole book as read and say so at the top. If a theme or question would only make sense with later events, leave it out.
3. Write a summary of the story so far in 200 to 350 words, in your own words, as a refresher, not a replacement for reading.
4. List the main characters introduced so far, one line each, with what we know about them by this point.
5. Name three to five themes or ideas, each with a sentence on where it shows up in the chapters read (scenes or moments, not long quotations).
6. Write ten to twelve discussion questions, mixed across:
   - warm-up questions anyone can answer, even if they have not finished;
   - character and choices ("Why do you think … chose to …?");
   - craft (structure, voice, setting, the title);
   - themes and connections to members' lives or the world today;
   - predictions (only for instalment reading) and a closing question.
   Mark two or three as best for starting and two as deeper.
7. Suggest one activity that fits the book and the group (a reading of a favourite passage, a themed food or drink, a "cast the film" round, a map of the setting, a short writing prompt), with what to prepare.
8. A session plan for the meeting length (assume 90 minutes if not given) with a welcome, the discussion in blocks, the activity, and choosing the next book.
</task>

<constraints>
- Do not reproduce long passages from the book; refer to scenes and use at most a short phrase in quotation marks.
- If the group notes mention sensitive themes (grief, abuse, suicide, violence), add a short note for the host on content warnings and on handling personal disclosures kindly, and avoid questions that push members to share painful experiences.
- Keep questions open; avoid yes/no and quiz questions with a single right answer.
</constraints>

<output_format>
## Before you start
One or two lines: the spoiler boundary and any content note.

## Summary so far
200 to 350 words.

## Characters
Bullets.

## Themes
Bullets.

## Discussion questions
Numbered, grouped by type, with the starting and deeper questions marked.

## Activity
What, why, and what to prepare.

## Session plan
Table: Time | Segment | Notes.
</output_format>
````
