# Hodios paste pack: Presentations

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

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

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

## How to use

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

## Contents

- Presentations
  - [Critique a slide deck](#critique-slide-deck) (prompt)
  - [Outline a presentation](#outline-presentation) (prompt)
  - [Plan slide visuals](#plan-slide-visuals) (prompt)
  - [Presentation track](#presentation-track) (workflow)
  - [Turn a document into slides](#turn-document-into-slides) (prompt)
  - [Write a lightning talk](#write-lightning-talk) (prompt)
  - [Write a webinar script](#write-webinar-script) (prompt)
  - [Write speaker notes](#write-speaker-notes) (prompt)

---

<a id="critique-slide-deck"></a>

## Critique a slide deck

`critique-slide-deck` · prompt · Presentations · https://hermes-ide.com/prompts/critique-slide-deck

Critiques a slide deck for storyline, one idea per slide, text density and visual clarity, and returns ranked slide-level fixes with rewritten titles. Use before presenting or sending a deck.

````markdown
<context>
A deck is judged on whether the audience gets the point and acts on it. The common problems, roughly in order of damage: no clear storyline (reading the titles in order tells no story), topic-label titles instead of claims, several ideas crammed onto one slide, walls of text, charts that do not show the point (wrong chart type, no highlight, unlabelled axes, too many series), and inconsistent formatting. A deck presented live should carry less text than a deck sent as a pre-read, which must stand on its own.
</context>

<task>
Critique this deck:
<deck>
[DECK]
</deck>

1. If the deck is empty or only a topic, ask for the slides and stop. If you only have text and cannot see the visuals, say so once and judge visuals only from their descriptions.
2. If the audience or the mode (presented or read) is not given, infer it and state your assumption.
3. Storyline test: list the slide titles in order. Can you state the deck's main message in one sentence from the titles alone? Note where the logic jumps, repeats or stalls, and where the ask or conclusion is missing or buried.
4. For each slide that has a problem, check:
   - Title: a full-sentence claim? If not, rewrite it as one using only content on the slide.
   - One idea: does everything on the slide support the title? If not, say what to split or cut.
   - Density: more than about 40 words for a live talk (or about 80 for a pre-read), or more than six bullets, is too dense; say what to cut or move to notes or an appendix.
   - Visuals: does the chart or image prove the title? Name a better chart type, the highlight to add, or the clutter to remove (gridlines, 3D, legends that could be direct labels, too many colours).
   - Accessibility: small text, low contrast or meaning carried by colour alone, where the description reveals it.
5. Rank all issues by how much they hurt the audience's understanding. Fatal: the point is unclear or wrong. Major: a slide fails its job. Minor: polish.
</task>

<constraints>
- Be specific: every issue names the slide and a concrete fix. No generic advice ("use fewer words").
- Use only the deck's content in rewritten titles; do not invent data.
- Skip slides with no problems; do not pad.
- Do not comment on brand colours or fonts unless they hurt readability.
</constraints>

<output_format>
## Verdict
Three lines: the deck's main message as you understand it, its biggest problem, and whether it is ready to present (ready / ready after fixes / needs restructuring).
## Storyline
The titles in order, then what the storyline does well and where it breaks.
## Slide-by-slide
A table: Slide | Issue | Fix (including any rewritten title) | Severity.
## Top changes
The three changes that would most improve the deck, in order.
</output_format>
````

---

<a id="outline-presentation"></a>

## Outline a presentation

`outline-presentation` · prompt · Presentations · https://hermes-ide.com/prompts/outline-presentation

Outlines a story-driven presentation with assertion-style slide titles, using SCQA or the pyramid principle, sized to the time slot and aimed at a stated goal for a specific audience.

````markdown
<context>
Most decks fail before any slide is designed: they are organised by topic ("Background", "Data", "Next steps") instead of by argument, so the audience sees information but not the point. Two structures fix this. SCQA (Situation, Complication, Question, Answer) builds tension and suits persuasion and change. The pyramid principle (answer first, then the supporting arguments, each backed by evidence) suits recommendations to senior or time-pressed audiences. In both, slide titles are assertions: full-sentence claims ("Churn doubled after the price change"), not labels ("Churn"). Reading only the titles in order should tell the whole story.
</context>

<task>
Outline a 15-minute presentation for [AUDIENCE] on:
<topic>
[TOPIC]
</topic>


1. If the topic gives no material to build an argument from (only a subject heading), ask for the key facts or findings and stop.
2. If no goal is given, infer the most likely one from the topic and audience and state it in Big idea as an assumption.
3. Write the big idea: one sentence, a claim the audience could disagree with, that the whole talk supports.
4. Choose SCQA or the pyramid and say why in one line, based on the audience and goal (for example: senior decision-makers, pyramid; an audience that does not yet see the problem, SCQA).
5. Size the deck: about one content slide per 1 to 2 minutes, plus a title slide. Allow 10% of the time as buffer.
6. Write an assertion title for each slide (at most 15 words), what goes on it (the evidence or visual that proves the title, for example "line chart, monthly churn, 2024-2025, price change annotated"), the evidence still needed, and minutes.
7. Open with a hook that matters to this audience (a number, a consequence, a question), and close on the goal: the decision or action requested, not "Questions?".
8. Check the horizontal logic: read the titles in order. If any does not follow from the one before, fix it.
</task>

<constraints>
- One idea per slide. If a slide needs two titles, split it.
- Use only facts from the topic. Where a slide needs a number or example you do not have, mark it `[data needed: …]`.
- Put supporting detail the audience may ask for in an appendix list rather than in the main flow.
- Do not design slide visuals beyond a one-line description of the chart or image.
</constraints>

<output_format>
## Big idea
One sentence, plus the goal (stated or inferred).
## Structure
SCQA or pyramid, the reason, and how the sections map to slides.
## Slide outline
A table: # | Assertion title | Content and visual | Evidence needed | Minutes. Then "Total: N minutes".
## Title read-through
The titles alone, in order, as a paragraph.
## Gaps
Bullets: `[data needed]` items and appendix slides to prepare. "None" if none.
</output_format>
````

---

<a id="plan-slide-visuals"></a>

## Plan slide visuals

`plan-slide-visuals` · prompt · Presentations · https://hermes-ide.com/prompts/plan-slide-visuals

Proposes the visual for each slide in an outline, whether a chart type, diagram, image or none, with layout notes and data needs, so a deck shows its points rather than telling them.

````markdown
<context>
Slides that only repeat the speaker's words in bullets make the audience read instead of listen. The assertion-evidence approach, tested in engineering and science presentations, works better: each slide's title is a full-sentence claim, and the body is the visual evidence for it. The right visual follows from the relationship in the content: change over time is a line, comparison across items is a sorted bar, part of a whole is a stacked bar (a pie only for two or three parts), a distribution is a histogram, a relationship between two measures is a scatter, a process is a flow, a hierarchy is a tree, a sequence of events is a timeline. Some slides need no visual at all: a single big number, a quote, or a question can carry the slide on its own.
</context>

<task>
Plan the visuals for this deck.

<slide_outline>
[SLIDE_OUTLINE]
</slide_outline>

1. If the outline has no clear message per slide, or the slides with data have no numbers, say which slides are affected; plan the rest and mark those slides as needing input rather than guessing.
2. For each slide, state its message as a full-sentence assertion title (rewrite the title if it is a topic label like "Q3 results").
3. Choose the visual that proves that assertion, or "none" if text, a big number or a quote does the job better. Name the specific type (for example "horizontal bar, sorted descending, 6 regions"), not just "chart".
4. Give layout notes: what to highlight (one bar in the accent colour, a callout on the key point), what to remove (gridlines, legend if labels can sit on the data), and where the eye should land first.
5. For each chart, list the exact data it needs, and whether the outline supplies it.
6. Set a handful of rules for the whole deck so visuals stay consistent.
</task>

<constraints>
- One message per visual. If a slide is trying to show two things, propose splitting it.
- Prefer simple, honest charts: no 3D, no dual axes unless unavoidable (and then say why), bar axes start at zero, and no pie with more than three slices.
- Use stock photos only where an emotional or concrete image adds meaning (a customer, the product in use, a place); never as decoration.
- Accessibility: do not encode meaning by colour alone, keep text on slides readable from the back of the room (about 24 pt minimum for live decks), and note alt text for key visuals if the deck will be shared.
- If the deck will be sent rather than presented, allow fuller annotations on each visual and say so.
- Respect the brand constraints if given; if a constraint conflicts with readability, say so once.
- Use only numbers in the outline. Never invent data to fill a chart; mark gaps as `[NEEDED: …]`.
</constraints>

<output_format>
## Visual plan
A table: # | Assertion title | Visual | Layout notes.
## Charts to build
For each chart: slide number, chart type, data series and categories, sort order, the highlight, and axis and label notes.
## Rules for the whole deck
Four to six bullets (colour use, fonts, chart style, image style, how highlights work).
## Missing data
Bullets of `[NEEDED: …]` items, or "None".
</output_format>
````

---

<a id="presentation-track"></a>

## Presentation track

`presentation-track` · workflow · Presentations · https://hermes-ide.com/prompts/presentation-track

Takes a presentation from audience and goal to storyline, slide content, speaker notes and a rehearsal with likely questions, pausing for approval between steps.

````markdown
Prepares a presentation one approved step at a time, as an experienced presentation coach would: brief, storyline, slide content, speaker notes, then a rehearsal with the questions the audience is likely to ask.

<topic>
[TOPIC]
</topic>

<audience>
[AUDIENCE]
</audience>

Speaking time: [DURATION_MINUTES] minutes.

Each step produces one artifact and stops for approval or edits. Later steps build on the approved versions and do not reopen them unless the presenter asks. Use only facts, figures and stories the presenter supplied; mark anything missing as `[NEEDED: …]` instead of inventing data, quotes, results or customer names. Plan for about 130 spoken words a minute and, as a starting point, one slide per one to two minutes. If the presenter asks to skip the approvals, confirm once that later steps will build on unreviewed choices; if they agree, run the remaining steps in one reply and state the choice made at each skipped gate.

## Steps

Work through these steps in order. Do not skip a gate.

1. brief (plan)
2. storyline (design)
3. slides (build)
4. notes (build)
5. rehearsal (verify)

### Step 1: Audience and goal brief

Pin down what this presentation must achieve before any slide exists.

1. Two things are essential: what the audience should do, decide or understand afterwards, and the substance to present (the facts, data or story). If either cannot be worked out from the topic and audience, ask for it in one message, together with the setting, what the audience already believes, and any template or Q&A time, then stop. If both are clear, do not ask: write the brief and list your assumptions about the rest (setting, Q&A time, template, mandatory slides) under **Assumptions to confirm**.
2. Write a brief of no more than one page:
   - **Goal:** "After this, [audience] will [think, feel or do] …", one sentence. If the presenter wants a decision, name the exact decision.
   - **Audience:** what they know, what they care about, their likely objections or worries, and how they prefer information (numbers first, story first, detail-hungry, time-poor).
   - **The one message:** the single sentence the audience should be able to repeat afterwards.
   - **Constraints:** [DURATION_MINUTES] minutes of speaking, Q&A time, format, template and anything that must or must not be said.
   - **Evidence on hand:** the facts, data and stories the presenter supplied that can carry the message, and the gaps marked `[NEEDED: …]`.
   - **Risks:** the ways this could go wrong with this audience (too much detail, a sensitive history, a sceptical stakeholder).
   - **Assumptions to confirm:** each default you chose for a detail the presenter did not give, in one line each. "None" if none.

Stop and wait for approval or edits. Do not build the storyline yet.

**Gate:** stop here and wait for the user's approval before step 2 (storyline).

### Step 2: Storyline

Build the argument before the slides, from the approved brief.

1. Choose a structure that suits the goal and say why:
   - **SCQA** (situation, complication, question, answer) for a recommendation or decision;
   - **pyramid** (answer first, then the supporting points) for senior or time-poor audiences;
   - **problem, solution, proof, ask** for a pitch;
   - **then, now, next** for an update or a story of change;
   - **chronological or step by step** for training and how-to.
2. Write the storyline as the sequence of points the audience must accept, one sentence each, in order. Read only these sentences: they should make the whole argument on their own. If a sentence does not move the audience toward the goal, cut it.
3. Allocate time to each part so the total fits [DURATION_MINUTES] minutes, leaving about 10% spare. Give the opening and close their own time.
4. Draft the opening (the first 30 seconds: why this matters to this audience, now) and the close (the message restated and the specific ask or next step). No agenda slide as the opener unless the audience expects one.
5. Mark where the strongest evidence and the one story or example go, and what to put in an appendix instead of the main flow.

Stop and wait for approval or edits. Do not write slide content yet.

**Gate:** stop here and wait for the user's approval before step 3 (slides).

### Step 3: Slide content

Turn the approved storyline into slides.

For each slide, in order:

1. **Title:** a full-sentence takeaway that states the point (for example "Returns fell 18% after we changed packaging"), not a topic label ("Returns"). Reading the titles alone should tell the whole story.
2. **Body:** the minimum that proves the title: one chart, one diagram, one image or three short bullets at most. Name the chart type, what is on each axis and what to highlight, using only the presenter's data. Mark missing figures `[NEEDED: …]`.
3. **Time:** minutes on this slide; the total must match the storyline timings.
4. **Why it is here:** one line linking the slide to the goal. If you cannot write it, drop the slide.

Then:

- List backup and appendix slides for detail that likely questions may need.
- Flag any slide with more than about 30 words of text, more than one message, or a chart that needs explaining for more than a minute, and propose a split or simplification.
- Note accessibility basics: readable font sizes for the room, contrast, no meaning carried by colour alone, and alt text for key visuals if the deck will be shared.

Stop and wait for approval or edits. Do not write speaker notes yet.

**Gate:** stop here and wait for the user's approval before step 4 (notes).

### Step 4: Speaker notes

Write what the presenter says on each approved slide.

1. For each slide, write notes as speakable sentences in the presenter's register, not as a copy of the slide text: the point in one line, the explanation or story, and the bridge to the next slide ("So if packaging was the cause, what does it cost to fix?").
2. Mark the one line per slide to say exactly as written, and where to pause.
3. Keep each slide's words within its time budget at about 130 words a minute; show the word count per slide and the running total against [DURATION_MINUTES] minutes.
4. Write the first three sentences of the talk and the last three to memorise word for word.
5. Add delivery cues only where they matter: where to slow down, where to look at the decision-maker, where to invite a reaction.
6. Name the two slides to skip or shorten if the presenter is running late.

Stop and wait for approval or edits before the rehearsal.

**Gate:** stop here and wait for the user's approval before step 5 (rehearsal).

### Step 5: Rehearsal and likely questions

Prepare the presenter to deliver it and to handle the room.

1. **Rehearsal plan:** three run-throughs before the day. First, aloud with a timer to check length; second, standing, with slides, recording audio or video; third, in conditions close to the real setting (the room, the video tool, the clicker). After each, note where they ran over, stumbled or read from the slides.
2. **Likely questions:** the eight to twelve questions this audience is most likely to ask, from the brief's objections and the weakest parts of the evidence. Put the hardest ones first. For each: why they will ask it, a short honest answer from the presenter's material (two to four sentences, answer first), and the backup slide to show if there is one. Where the material does not answer it, say so and suggest how to respond honestly ("I don't have that figure; I'll send it by Friday").
3. **Hostile or off-topic questions:** how to acknowledge, bridge back to the message and offer to follow up offline, without dodging.
4. **Practice offer:** offer to play the audience and ask the questions one at a time, giving brief feedback on each answer's length and directness.
5. **Day-of checklist:** tech check, backup copy of the slides, timing cues, water, the opening line rehearsed, and a plan if the slot is cut short.

This is the last step.
````

---

<a id="turn-document-into-slides"></a>

## Turn a document into slides

`turn-document-into-slides` · prompt · Presentations · https://hermes-ide.com/prompts/turn-document-into-slides

Turns a document or report into a slide outline with one message per slide, action titles that tell the story, suggested visuals from the document's own data, and an appendix plan.

````markdown
<context>
A document and a deck do different jobs. A document is read at the reader's pace and can hold every detail; a deck is a sequence of single messages, usually seen while someone talks, and often skimmed later by title alone. Converting one into the other fails when each document section becomes a slide of shrunken paragraphs, when titles are topic labels ("Methodology", "Results") instead of the point, and when every finding gets equal weight. The working method is to find the document's governing message, rebuild the argument as a sequence of action titles that tell the story when read alone, give each slide one piece of evidence, and push supporting detail to an appendix.
</context>

<task>
Turn this document into a slide outline.



<document>
[DOCUMENT]
</document>

1. If the document is too short or fragmentary to present, say so and ask what the presentation should achieve; then stop.
2. State the governing message in one sentence: what the audience should conclude. If no audience was given, assume the document's own intended reader and say so.
3. Choose the storyline order for this audience: answer first for executives and decision-makers; context, then findings, then implications for less familiar audiences. Explain the choice in one line.
4. Write the action titles first: one full-sentence takeaway per slide, ideally under 15 words, so that reading only the titles tells the whole story. If no slide count was given, propose one that fits the content (often 8 to 15 for a 20-minute slot) and say why.
5. For each slide, specify: the single supporting element (a chart type with what to plot from the document's data, a diagram, a short table, an image, or up to three bullets of at most 10 words each), the source section of the document, and one line of what the speaker would say.
6. Plan the appendix: detail, methodology, full tables and caveats that someone may ask about, each with the main slide it supports.
7. List what you left out of the main flow and why.
</task>

<constraints>
- Use only content from the document. Do not invent data, examples or conclusions, and do not round or change numbers. If a visual would need data the document lacks, say so in Gaps.
- One message per slide. If a slide needs two, split it.
- Keep caveats and limitations that change the meaning of a finding on the main slide, not only in the appendix.
- Chart choices must suit the data: comparisons as bars, change over time as lines, parts of a whole only when they truly sum to 100%.
- No decorative slides (agenda, "thank you", "questions?") unless the audience or format requires them; mention them in one line if so.
</constraints>

<output_format>
## Storyline
Governing message, chosen order and why, and the titles alone as a numbered list.
## Slides
For each: **N. Action title**; Visual or content; Source (document section); Say (one line).
## Appendix
Numbered: A1, A2… title, content, supports slide N.
## Left out
Bullets with reasons.
## Gaps
Data or material the deck needs that the document does not supply. "None" if none.
</output_format>
````

---

<a id="write-lightning-talk"></a>

## Write a lightning talk

`write-lightning-talk` · prompt · Presentations · https://hermes-ide.com/prompts/write-lightning-talk

Writes a five-minute lightning talk or a timed PechaKucha or Ignite script around one idea, with slide-by-slide words, visuals and a closing line, for meetups and internal demos.

````markdown
<context>
Short formats punish the habits of long talks. There is no time for an agenda, a bio slide or three points; a lightning talk has room for one idea, one story or example that makes it concrete, and one line people remember. Auto-advancing formats add a second constraint: each slide gets the same fixed time, so every slide's words must fit it, and the slides should be images that the words explain, not text to read. Speakers run over most often by squeezing in "one more thing" and by unrehearsed transitions.
</context>

<task>
Write a talk in the lightning-5min format.

<topic_and_point>
[TOPIC_AND_POINT]
</topic_and_point>

Timing by format, at about 130 spoken words a minute:
- lightning-5min: 5:00 hard stop, so aim for about 4:30: about 550 to 600 words, 6 to 12 slides at the speaker's pace.
- pechakucha-20x20: 20 slides × 20 seconds = 6:40, about 40 to 45 words per slide.
- ignite-20x15: 20 slides × 15 seconds = 5:00, about 30 to 33 words per slide.

1. If there is no material to build from (no story, example, data or experience), ask for one and stop.
2. State the one idea in a single sentence. If the material holds several ideas, choose the strongest for this audience and list what you cut.
3. Choose a shape: problem → turn → payoff, before → after, a single story with a lesson, or a myth and its correction. Say which and why.
4. Write the script slide by slide: the visual for each slide (an image, a single number, a short phrase or a demo frame) and the exact words to say, within that format's word budget.
5. Write a closing line that restates the idea in a memorable form, and the last slide.
6. Add rehearsal notes: where timing is tight, which slides are buffers, and what to do if a slide advances before you finish.
</task>

<constraints>
- One idea. No agenda slide, no "about me" slide longer than one sentence of spoken words, no "any questions?" slide in auto-advancing formats.
- Spoken language: short sentences, concrete nouns, and transitions that hand off to the next slide ("Which is exactly what broke on Tuesday.").
- In PechaKucha and Ignite, every slide's word count must fall within its budget; show the count.
- Slides carry at most a few words; the speaker carries the meaning.
- Use only facts, numbers and stories from the material. Mark anything the talk needs but lacks as `[NEEDED: …]`.
- A live demo inside five minutes needs a recorded fallback; say so if a demo is planned.
</constraints>

<output_format>
## The one idea
One sentence, then "Cut:" with anything left out.
## Shape
One or two lines.
## Script
A table: Slide | Visual | Words (with word count in brackets).
## Closing line
The last sentence, word for word.
## Rehearsal notes
Three to five bullets, including total word count against the time budget.
</output_format>
````

---

<a id="write-webinar-script"></a>

## Write a webinar script

`write-webinar-script` · prompt · Presentations · https://hermes-ide.com/prompts/write-webinar-script

Writes a timed webinar script with opening, agenda, teaching segments, polls, demo transitions, Q&A handling and a call to action, built to keep a remote audience engaged to the end.

````markdown
<context>
Webinar audiences are one click from leaving and are usually multitasking. Attention drops sharply after the first few minutes and at every long, uninterrupted stretch. Webinars that hold people deliver value early instead of after ten minutes of housekeeping and company history, change mode every five to eight minutes (a poll, a question, a demo, a story, a switch of speaker), tell people what they will get and when Q&A happens, and make the call to action a natural next step from the teaching rather than a hard sell bolted on at the end. People who arrive late and people who watch the recording should still be able to follow.
</context>

<task>
Write a webinar script for 45 minutes.


<topic>
[TOPIC]
</topic>

1. If the topic lacks the actual content to teach (the points, steps or insights), ask for it in up to three short questions and stop. Do not fill a teaching segment with generic advice.
2. Build the run of show: segments with start times adding up to 45 minutes, roughly:
   - opening and value promise (2 to 3 minutes; a short pre-start for late joiners if live);
   - a brief agenda and housekeeping (chat, Q&A, recording, under 1 minute);
   - two to four teaching segments, each built around one takeaway, with an interaction point between them;
   - a demo, if the topic includes one, with clear transitions in and out;
   - the call to action, introduced as the next step after the teaching;
   - Q&A (about 20 to 25% of the time);
   - a close that restates the takeaways and the call to action.
3. Write the script in spoken language for each presenter (label speakers), with:
   - a cold open in the first 60 seconds: a problem, a striking fact from the topic, or a question to the audience;
   - signposts ("That's the first mistake; the second is the one that costs most");
   - interaction cues every five to eight minutes: polls, chat prompts, "type 1 if…";
   - demo transitions: what to say while switching screens, and a fallback line if the demo fails;
   - a mid-point recap for late joiners.
4. Write two or three polls with answer options, when to launch them, and how the presenter will use the results live.
5. Plan Q&A: three seed questions in case the chat is quiet, how to group similar questions, how to handle off-topic or hostile ones, and what to do with unanswered questions.
6. Write the follow-up: the closing line about the recording and resources, and a three- to five-sentence follow-up email outline.
</task>

<constraints>
- Use only facts, claims, customer stories and product details from the topic. Mark anything missing as `[NEEDED: …]`; never invent statistics, testimonials or product features.
- The call to action is one clear step, mentioned briefly at the start ("stay to the end for…") and fully once near the end. No fake scarcity or invented deadlines.
- Keep slides and screen-sharing cues in brackets, separate from spoken lines.
- Spoken pace about 130 words a minute; scripted segments should leave room for interaction and Q&A.
</constraints>

<output_format>
## Run of show
Table: Start | Segment | Presenter | Interaction | Minutes. Total row.
## Script
Segment by segment, with speaker labels, spoken lines and [cues].
## Polls
Each: question, options, launch time, how to use the result.
## Q&A plan
Seed questions, handling rules, unanswered-question plan.
## Follow-up
Closing line and follow-up email outline.
## Placeholders
Every `[NEEDED: …]`. "None" if none.
</output_format>
````

---

<a id="write-speaker-notes"></a>

## Write speaker notes

`write-speaker-notes` · prompt · Presentations · https://hermes-ide.com/prompts/write-speaker-notes

Writes natural, speakable notes for each slide with a time budget, the one point to stress and a transition to the next slide, and checks the total fits the time slot.

````markdown
<context>
Speaker notes are for glancing at under pressure, not for reading aloud. The worst notes repeat the slide text, so the speaker reads the slide to an audience that has already read it. Good notes add what the slide does not say (the meaning of the chart, the example, the "so what"), use short spoken sentences, mark the one thing that must land, and carry a transition so the talk flows instead of restarting at every slide. Most people speak at about 130 to 150 words a minute in a presentation, slower with pauses.
</context>

<task>
Write speaker notes for these slides, for a 15-minute talk:
<slides>
[SLIDES]
</slides>

1. If the slides are empty or are only a topic, ask for the slide content and stop.
2. Budget the time: give each slide minutes in proportion to its weight (the key evidence slide gets more than the title slide), keep about 10% buffer, and track a running total.
3. For each slide write:
   - **Stress:** the one point the audience must take away, in one sentence.
   - **Notes:** what to say, in short spoken sentences and contractions, adding meaning beyond the slide text. Explain charts by their point ("Look at the right edge: that's the week we changed the price"). Mark [pause] where a point needs to land and [click] for builds or animations if the slide text implies them.
   - **Transition:** one sentence that links to the next slide's point.
4. Size each slide's notes to its time at about 130 words a minute. Notes for a slide with one minute should be under about 130 words.
5. Write the first and last slides more fully: the opening lines and the closing lines are worth having word for word.
</task>

<constraints>
- Use only content from the slides. Where a slide needs an example, story or number to make its point and none is given, write `[example needed: …]` instead of inventing one.
- Do not repeat the slide's bullets verbatim in the notes.
- Natural speech: no long subordinate clauses, no reading out of URLs or long numbers in full (round only if the slide already rounds).
- If the slides cannot fit the time (for example 30 dense slides in 10 minutes), say so in Timing check and suggest which slides to cut or merge.
</constraints>

<output_format>
## Speaker notes
For each slide: "### Slide N: <title> (m:ss, total m:ss)", then Stress, Notes and Transition.
## Timing check
Total words, estimated time at 130 words a minute, buffer left, and any slides to cut or merge.
## Gaps
Bullets: `[example needed]` items. "None" if none.
</output_format>
````
