html-slideshow-deck

これはレビュー時に保存された抜粋です。完全で最新の内容は外部ソースを確認してください。

---
name: html-slideshow-deck
description: Generate keyboard-navigable HTML slideshow decks for presentations, tech talks, leadership briefings, onboarding walkthroughs, and any sequential visual narrative. Use whenever the user wants slides, a deck, a presentation, a tech talk, a brown-bag, a briefing, or any sequential walkthrough — especially when they want to share via a link rather than as a PowerPoint or Keynote file. Prefer HTML over .pptx whenever the deck contains live code, embedded interactivity, or will be shared as a URL.
metadata:
  version: "1.2.1"
---

# 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.

## 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.

## HTML output foundation

These defaults apply to **every** artifact this skill produces, on top of the requirements above. If a rule above conflicts with this list, the rule above wins; otherwise these are non-negotiable.

- **Output a real `.html` file the user opens in a browser — never inline-render in chat.** Every artifact this skill produces is a file on disk (`<topic>-<kind>.html`), not an HTML block embedded in the agent's chat surface (claude.ai artifact/canvas widgets, fenced ```html``` blocks, custom rendered iframes, etc.). Inline rendering strips features, themes unpredictably against the surrounding chat (often unreadable in dark mode), and lacks the stable origin and clipboard/network access the submit handler needs. Always write the file. The file itself must be self-contained: no build step, no external runtime, inline CSS and JS. Google Fonts via `<link>` is fine; otherwise nothing loaded from npm or a CDN unless this skill explicitly calls for it.
- **Mobile-responsive.** Collapse cleanly to a single column under ~700px so the artifact opens on a phone — including during incidents, commutes, and link-shares to non-laptop reviewers.
- **No `localStorage` / `sessionStorage` / `IndexedDB`.** Claude.ai artifacts can't use browser storage. State lives in JS memory; the export / copy button is the persistence layer.
- **Real semantic HTML, not screenshots.** Code goes in `<pre><code>` (selectable, copyable). Tabular data goes in `<table>`. Diagrams are inline `<svg>` with real `<g>` and `<path>` elements, not embedded PNGs. The reader should be able to copy any value, line, or label out of the artifact.
- **Build DOM safely; don't sling strings.** Use `textContent` for text and `document.createElement` + `appendChild` for structure. **Never** set `innerHTML` from a string that includes a variable, user input, computed value, or imported data — it's an XSS vector and many agent harnesses (including Claude Code) block it via security hooks. Static literal markup inline in your script is fine.
- **SVG text doesn't wrap — size the shape to the label, or use `<foreignObject>`.** Plain SVG `<text>` overflows silently when the label is longer than the box was sized for, crashing into adja