Interactive presentation builder
Build slide decks that run as a website and are projected to a room. The deck is the
visual half of a talk; the presenter does the talking. Two ways to build, one shared
design language.
First, the mental model (read before writing any code)
There is one operator (the presenter) on one machine. Slides go on a big screen;
the audience only looks — they never click, type, or interact. Everything below
follows from this. Three failure modes to avoid:
- Text too small. Slides are read from across a room, not on a laptop. Never use
web-reading sizes (
text-sm, 16px) or fixed Tailwind text classes (text-4xl).
Always use fluid clamp() so text scales with the screen. Honour the typography floor
(body ≥ ~40px on a 1080p canvas). See references/design-system.md.
- Content hugging an edge. Padding is a two-layer contract. Slide content must stay
inside the viewport safe area, and content inside a card, panel, callout, bordered box,
or other visible container must stay inset from that container's own edge. A parent
slide's padding does not protect a nested container;
gap and child margins are not a
substitute for the container's own padding. Both scaffolds provide safe-area padding
and a .slide-surface inset helper. Even fullBleed slides keep text content inset.
- Building an app. No input fields, no "Submit", no login, no data collection — there
is no backend and nowhere for data to go. Interaction is only the presenter clicking to
reveal/advance content. If a component asks "where does this data go?", it's wrong.
references/design-system.md is the heart of this skill — the typography floor, two-layer
padding contract, content overflow, layout recipes, motion, and palette. Read it whenever
you design or restyle slide content.
Workflow
- Understand the talk. Topic, audience, speaker (name/role for the title slide), tone,
rough number of slides, and any brand colours/logo. For Vietnamese content the default
voice is plain, honest, direct — no marketing hype.
- Pick a track (below). If unsure, ask once; otherwise default to plain HTML for
small/quick decks and React for substantial, maintained talks.
- Scaffold with the matching script — don't hand-assemble the boilerplate.
- Build slides following
references/design-system.md: one idea per slide, few
words, real visuals, projection-legible type, presenter-only interaction, and the
two-layer padding contract for both viewport and content containers.
- Keep the required chrome: a visible bottom navigation slider (dot strip) and slide
number. Both scaffolds include it — don't remove it.
- Write speaker notes in the
<deck-name>-notes.md file the scaffold creates (never
on the slides themselves).
- Run the spacing audit before handoff. Check every slide at 1920×1080 and at one
smaller viewport. No text or primary content may cross the viewport safe area. For
every element that draws a visible boundary (
background, border, outline,
shadow, rounded surface, or text-overlay panel), verify that its content has
padding on all four sides. Media and purely decorative edge-to-edge layers are the
only exceptions; text over them belongs in a nested padded surface.
- Export to PDF if asked — see
references/export-pdf.md.
Put each deck in its own folder. Keep any live-demo app as a separate project, not inside
the deck.
Choosing a track
| Pick |
When |
Reference |
| Plain HTML |
Zero setup wanted; runs by opening a file; quick deck; shareable anywhere; no toolchain. Gets unwieldy past ~15–20 rich slides. |
references/html-track.md |
| Vite + React |
Many slides, reusable components, state-driven interactions, TypeScript, Framer Motion, maintained/re-run talks. |
references/react-track.md |
Both produce the same projected experience and obey the same design system; they differ
only in implementation.
Scaffolding
Plain HTML — single self-contained index.html, Tailwind via CDN, no build:
bash scripts/new-html-deck.sh <deck-name> [target-dir] [--title "Deck title"]
Vite + React — scaffolds with the official Vite tool and installs the latest
React, Tailwind, Framer Motion, and Lucide (versions are intentionally not pinned, so
each deck starts on current tooling), then layers the App → Deck → Slide architecture:
bash scripts/new-react-deck.sh <deck-name> [target-dir] [--no-install]
cd <deck-name> && npm run dev
After scaffolding, read the matching track reference for how slides are structured and how
to add/reorder them, then build the content.
Files in this skill
references/design-system.md — projection rules, typography floor, layout recipes,
motion, palette. The core; consult for any content/design work.
references/html-track.md — plain-HTML deck structure, template internals, adding slides.
references/react-track.md — Vite+React architecture, slide ordering, Tailwind wiring.
references/export-pdf.md — PDF export options and speaker-notes convention.
scripts/new-html-deck.sh — scaffold a plain-HTML deck.
scripts/new-react-deck.sh — scaffold a Vite + React deck.
scripts/export-deck-pdf.py — export a deck to a content-complete PDF (waits for render
and reveals hidden content; image-based).
1---2name: slidewright3description: Build interactive presentation websites — slide decks projected to a room, controlled by one presenter. Use this skill WHENEVER the user wants to create, build, or design a presentation, slide deck, talk, or "bài thuyết trình / slide / trình chiếu", and also when they ask to add/edit slides, restyle a deck, scaffold a new presentation project, reuse their presentation setup in another repo, or export slides to PDF — even if they don't say the word "slide" but clearly need projected talk visuals (e.g. "I'm giving a talk next week and need visuals", "dựng deck cho buổi chia sẻ", "làm mấy trang chiếu cho hội thảo"). Supports two tracks: a zero-build single HTML file, or a Vite + React project. Do NOT use it for printable documents, normal web apps, or dashboards meant for individual users to interact with.4---56# Interactive presentation builder78Build slide decks that run as a website and are **projected to a room**. The deck is the9visual half of a talk; the presenter does the talking. Two ways to build, one shared10design language.1112## First, the mental model (read before writing any code)1314There is **one operator** (the presenter) on **one machine**. Slides go on a big screen;15the audience only **looks** — they never click, type, or interact. Everything below16follows from this. Three failure modes to avoid:1718- **Text too small.** Slides are read from across a room, not on a laptop. Never use19 web-reading sizes (`text-sm`, `16px`) or fixed Tailwind text classes (`text-4xl`).20 Always use fluid `clamp()` so text scales with the screen. Honour the typography floor21 (body ≥ ~40px on a 1080p canvas). See `references/design-system.md`.22- **Content hugging an edge.** Padding is a two-layer contract. Slide content must stay23 inside the viewport safe area, and content inside a card, panel, callout, bordered box,24 or other visible container must stay inset from that container's own edge. A parent25 slide's padding does not protect a nested container; `gap` and child margins are not a26 substitute for the container's own padding. Both scaffolds provide safe-area padding27 and a `.slide-surface` inset helper. Even `fullBleed` slides keep text content inset.28- **Building an app.** No input fields, no "Submit", no login, no data collection — there29 is no backend and nowhere for data to go. Interaction is only the presenter clicking to30 reveal/advance content. If a component asks "where does this data go?", it's wrong.3132`references/design-system.md` is the heart of this skill — the typography floor, two-layer33padding contract, content overflow, layout recipes, motion, and palette. Read it whenever34you design or restyle slide content.3536## Workflow37381. **Understand the talk.** Topic, audience, speaker (name/role for the title slide), tone,39 rough number of slides, and any brand colours/logo. For Vietnamese content the default40 voice is plain, honest, direct — no marketing hype.412. **Pick a track** (below). If unsure, ask once; otherwise default to plain HTML for42 small/quick decks and React for substantial, maintained talks.433. **Scaffold** with the matching script — don't hand-assemble the boilerplate.444. **Build slides** following `references/design-system.md`: one idea per slide, few45 words, real visuals, projection-legible type, presenter-only interaction, and the46 two-layer padding contract for both viewport and content containers.475. **Keep the required chrome:** a visible bottom navigation slider (dot strip) and slide48 number. Both scaffolds include it — don't remove it.496. **Write speaker notes** in the `<deck-name>-notes.md` file the scaffold creates (never50 on the slides themselves).517. **Run the spacing audit before handoff.** Check every slide at 1920×1080 and at one52 smaller viewport. No text or primary content may cross the viewport safe area. For53 every element that draws a visible boundary (`background`, `border`, `outline`,54 `shadow`, rounded surface, or text-overlay panel), verify that its content has55 padding on all four sides. Media and purely decorative edge-to-edge layers are the56 only exceptions; text over them belongs in a nested padded surface.578. **Export to PDF** if asked — see `references/export-pdf.md`.5859Put each deck in its own folder. Keep any live-demo app as a separate project, not inside60the deck.6162## Choosing a track6364| Pick | When | Reference |65| --- | --- | --- |66| **Plain HTML** | Zero setup wanted; runs by opening a file; quick deck; shareable anywhere; no toolchain. Gets unwieldy past ~15–20 rich slides. | `references/html-track.md` |67| **Vite + React** | Many slides, reusable components, state-driven interactions, TypeScript, Framer Motion, maintained/re-run talks. | `references/react-track.md` |6869Both produce the same projected experience and obey the same design system; they differ70only in implementation.7172## Scaffolding7374**Plain HTML** — single self-contained `index.html`, Tailwind via CDN, no build:7576```bash77bash scripts/new-html-deck.sh <deck-name> [target-dir] [--title "Deck title"]78```7980**Vite + React** — scaffolds with the official Vite tool and installs the **latest**81React, Tailwind, Framer Motion, and Lucide (versions are intentionally not pinned, so82each deck starts on current tooling), then layers the `App → Deck → Slide` architecture:8384```bash85bash scripts/new-react-deck.sh <deck-name> [target-dir] [--no-install]86cd <deck-name> && npm run dev87```8889After scaffolding, read the matching track reference for how slides are structured and how90to add/reorder them, then build the content.9192## Files in this skill9394- `references/design-system.md` — projection rules, typography floor, layout recipes,95 motion, palette. The core; consult for any content/design work.96- `references/html-track.md` — plain-HTML deck structure, template internals, adding slides.97- `references/react-track.md` — Vite+React architecture, slide ordering, Tailwind wiring.98- `references/export-pdf.md` — PDF export options and speaker-notes convention.99- `scripts/new-html-deck.sh` — scaffold a plain-HTML deck.100- `scripts/new-react-deck.sh` — scaffold a Vite + React deck.101- `scripts/export-deck-pdf.py` — export a deck to a content-complete PDF (waits for render102 and reveals hidden content; image-based).