rich-html-presentation

Instructions

Step 1 — Gather the content first

If the deck is grounded in the user's world (a meeting/transcript, documents, a project, a product), retrieve it with the right tools (SearchM365, ListCalendarView + meeting-transcript tools, ReadFileContent, web_search) before authoring. Use clearly-marked placeholders (e.g. [Add Q3 number]) for anything you can't find — never invent names, numbers, quotes, or dates.

Step 2 — Start from the template

Read references/template.html and references/components.md from this skill folder. The template is the source of truth for the design system. Copy its <style> block and all five <script> blocks verbatim — do not restyle or rewrite the navigation/theme engine. Only the slide content, <title>, and .brand label change.

The engine ships as five separate small scripts on purpose. Never merge them into one, and never make one depend on a variable from another — see "Preview-surface constraints" below. (The fifth is the optional speaker-notes tray; delete it wholesale if the deck has no notes.)

Step 2a — Preview-surface constraints (why the engine looks the way it does)

Decks get shared, and most recipients open them in an embedded preview — the Teams file-preview pane, Outlook's reading pane, a SharePoint preview — not a real browser tab. Those hosts rewrite the document before rendering, and they impose three limits that are easy to violate by accident:

1. Inline scripts over ~2000 characters are silently never executed. (The Teams preview injects its own guard carrying LIMIT=2000.) Keep every <script> under ~1700 characters to leave headroom.
2. Each inline script is wrapped, so top-level const/let does not reach a shared global scope. A const declared in one block is invisible to the next.
3. Each inline script may get its own global object. Even an explicit window.myThing = {} in one block can be undefined in the next. There is no reliable cross-block channel.

So every block must be self-contained: re-read what you need from the DOM, and if one block must trigger another, dispatch a DOM event rather than calling a function. The template's swipe handler does exactly this — it dispatches an ArrowRight/ArrowLeft keydown instead of calling the navigation code.