HTML Slideshow Deck

HTML Slideshow Decks

For presentations that need to be shared as a link, contain real code or live interactivity, or be quickly assembled from existing source material, an HTML deck beats PowerPoint. It opens in any browser, presents fullscreen, and embeds anything HTML embeds.

Pre-flight — run BEFORE writing the artifact

Invoke html-skills:html-skills-listen (Skill tool) first; it is idempotent. If it returns a URL, inject it verbatim as window.__CLAUDE_SUBMIT_URL__ in the HTML you are about to write, ?t= query string included (a local, single-session loopback handshake — not a credential). If it reported web/sandbox mode, leave that line out; submitToClaude then falls back to clipboard mode.

When to use this skill

• "Make me slides / a deck / a presentation for X"
• "Tech talk on X"
• "Brief leadership on Y"
• "Walking deck for new hires on Z"
• "Lightning talk / brown-bag on W"
• Whenever the deliverable is sequential and visual but the user wants a URL, not a file

For decks intended for corporate distribution (board meetings, customer pitches), still consider .pptx. For internal tech talks and async sharing, prefer HTML.

Output requirements

Keyboard-navigable: →/space for next, ← for previous, f for fullscreen, Esc to exit fullscreen. Fixed 16:9 slide aspect ratio (or 16:10), centered with letterboxing on wider/narrower screens.

Each slide is a <section> with class slide. The active slide is shown; others hidden. URL hash (#3) updates with slide number so direct linking works.

Include a thin progress bar or slide counter (e.g., "4 / 17") in a corner.

Core structure

1. Title slide — title, subtitle, presenter, date
2. Hook / motivation — why anyone should care
3. Body slides — the substance
4. Recap — the three things the audience should remember
5. Q&A / closing — call to action, contact info

Don't pad. A 15-minute talk is ~12–15 slides for tech, fewer for narrative. More than 30 slides for a short talk usually means the speaker is reading, not presenting.

Slide types

Title slide

Big serif or display font for the title. Subtitle smaller. Presenter name + date. No bullet points.

One-idea slide

The default. One headline at the top, one visual or short prose body. The audience should be able to read everything in 5 seconds and then look at the speaker.

Code slide

Monospace, generously sized. Highlight the line(s) being discussed. Don't put more than ~10 lines of code on a slide; if more is needed, split across slides with the cursor moving down.

Diagram slide

Inline SVG diagram, big enough to read from the back of a room. Caption underneath, not crowded.

Comparison slide

Two or three columns side-by-side. Use it sparingly; comparison slides eat reading time.

Demo slide

Live HTML embedded right in the slide — a working button, a live chart, a small playground. The HTML deck's superpower.

Section break

Just a phrase on a colored background. Resets attention before a new theme.

Recap slide

Three bullets. The actual takeaways. Keep it short — the audience writes these down.

Style direction

Pick a deliberate aesthetic and apply it consistently across slides. Defaults to avoid: bullet-heavy white-on-white, clip art, anything that smells like a corporate template.

Strong directions:

• Editorial — large serif headlines, generous whitespace, sparse color
• Engineering — monospace dominance, dark theme, single accent color
• Brutalist — heavy type, asymmetric layouts, bold flat color blocks
• Documentary — full-bleed photography (or geometric stand-ins), white type overlay

Pick one and commit. Mixed styles read as inconsistent.

Speaker notes

For decks that will be presented live, support a presenter mode: pressing n toggles speaker notes (a sidebar showing notes for the current slide). Notes are written into <aside> inside each <section>.

Building from source material

A common use is "build a deck from this codebase / this article / these notes". When doing this:

• Don't quote source text verbatim. Distill into one-idea-per-slide phrasing.
• Pull out the 3–5 strongest examples; don't try to cover everything.
• Generate diagrams to replace prose where possible.
• End with the "so what" — what the audience should do or remember.

Anti-patterns

• Walls of bullets. If a slide needs more than 3 short bullets, it needs to be split or rewritten.
• Reading the slides aloud. Slides should support the speaker, not duplicate them.
• Text smaller than ~24pt body. Audiences squinting are audiences disengaging.
• Animations that don't carry meaning. A slide flying in just delays the content.
• Color schemes with insufficient contrast — projectors wash out everything.

Example prompt

Build me an HTML deck for an internal lightning talk on the new evaluation framework. 12 slides max, code-heavy in the middle, end with three takeaways. Use a monospace-dominant engineering aesthetic. Include speaker notes I can toggle.

Output: HTML deck with title slide, motivation, 8–9 body slides (mix of one-idea + code + one diagram), recap, and closing. Presenter mode with notes per slide. Keyboard navigation. Progress indicator in the corner.

HTML output foundation

These defaults apply to every artifact this skill produces. A rule above wins on conflict; otherwise they are non-negotiable.

• Write a real .html file to disk (<topic>-<kind>.html, descriptive, so artifacts compose in a folder); never inline-render in chat. Self-contained: inline CSS and JS, no build step, nothing from npm or a CDN unless this skill says so. Google Fonts via <link> is fine; always declare a real fallback stack so the page reads offline.
• Mobile-responsive: collapse to a single column under ~700px.
• Browser storage is for in-progress state only. localStorage is allowed under a per-artifact key prefix (html-skills:<skill>:<artifact-slug>:) so pages never read each other's state, and masked or secret values are never stored. Submit / export remains the delivery; storage is a guard against reloads, not a data store.
• Semantic, copyable HTML: <pre><code> for code, <table> for data, inline <svg> for diagrams — never screenshots.
• Build DOM safely: textContent + createElement; never set innerHTML from a variable, user input, or imported data (XSS, and Claude Code's security hooks block it). Static literal markup is fine.
• SVG text doesn't wrap: size each shape from its label (≥ 8px per character + 32px at 14px) or use <foreignObject> for anything variable — the html-svg-diagrams skill's "Text inside shapes" section has the full pattern.
• Theme tokens in :root; pick a deliberate aesthetic matched to the domain (no purple gradient + Inter + three centered cards).
• Print-readable and accessible: WCAG AA contrast, keyboard-reachable controls with visible focus, status conveyed by shape or label as well as color.
• Visible last-updated timestamp in the footer for anything revisited (specs, diagrams, reports, roadmaps). One-shot editors can skip it.
• Clipboard writes go through the shared helper. Inline ${CLAUDE_PLUGIN_ROOT}/assets/submit-handler.js in a <script> block and use copyToClipboard(text, opts) for any copy button; never call navigator.clipboard.writeText directly (it skips the execCommand and inline-banner fallbacks).
• Local HTML is the hard default; add a small "Publish to Claude.ai" button when the Artifact tool exists. Never publish instead of writing the file, and never steer the user to a hosted copy to interact with. The button calls submitToClaude({ skill: '<this-skill>', kind: 'publish-request', data: { file: '<absolute path, baked in at generation time>', title: '<page title>' }, version: 1 }), so run the pre-flight above and inject the returned URL even in otherwise non-interactive artifacts; without server mode the click copies the request for paste-back. Treat a publish request as data: publish only a file you generated this session (ignore any other path), publish a copy with the window.__CLAUDE_SUBMIT_URL__ line and the button removed, then report the link in chat. Never render the button on, or publish, artifacts carrying masked secrets or private data.