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. Four 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 ≈ 30–36px, never below 28px 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.
• Wrong voice for the audience. A board report is not a lesson and a pitch is not a
  status update. The deck type sets the structure and the voice. Decide it first — see
  references/deck-types.md.

The presenter may hold a phone remote (scan a QR code from the terminal, then tap
Next/Prev). It is the same single operator on a second device, not audience interaction.

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

1. Understand and clarify the talk.
   • Content: If the presentation content is vague or unclear, ask questions to clarify the topic, audience, speaker (name/role), and key message before building. For Vietnamese content, the default voice is plain, honest, direct — no marketing hype.
   • Deck type: Decide what the deck is for before writing: report upward, decision request, pitch, training, talk, or internal update. Infer it from the request and tell the user your choice in one line; ask only when two types fit equally. Then read references/deck-types.md and follow that type's arc, voice, and prohibitions.
   • Style: Ask the user for their preferred visual style and suggest these 5 modern options:
     1. Minimalist Bauhaus: High contrast, geometric typography, generous whitespace.
     2. Dark Mode Cinematic: Deep slate/black backgrounds, dramatic contrast, glowing accents.
     3. Editorial / Magazine: Sophisticated font pairings (serif + sans), structured grid layouts.
     4. Glassmorphism: Soft background gradients with blurred, translucent content panels.
     5. Neo-Brutalism: Bold typography, raw borders, hard shadows, high energy.
2. Pick a track (below). If unsure, ask once; otherwise default to plain HTML for
   small/quick decks and React for substantial, maintained talks.
3. Scaffold with the matching script — don't hand-assemble the boilerplate.
4. Build slides in the arc and voice of the deck type, 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. Respect the
   density limits — never exceed 5 bullets, ~60 words, or 5×4 table cells per slide.
   If content doesn't fit at the typography floor, split into more slides — never shrink
   past the floor and never produce a slide that scrolls vertically.
5. Keep the required chrome: a visible bottom navigation slider (dot strip) and slide
   number. Both scaffolds include it — don't remove it.
6. Write speaker notes in the <deck-name>-notes.md file the scaffold creates (never
   on the slides themselves).
7. Run the verify script to catch text-too-small and content-too-dense violations:

   bash /mnt/skills/user/slidewright/scripts/verify-slides.sh <path-to-deck>

   Fix every reported issue before proceeding.
8. 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.
9. Tell the user how to present with the phone remote. Both scaffolds include it.
   The HTML track runs node <deck>/slidewright-remote.mjs. The React track runs npm run dev.
   The terminal prints a QR code for the phone. See references/remote-control.md.
   Keep the deck's window.slidewright API and slidewright:change event when you edit
   navigation code.
10. 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

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

Both scaffolds include the phone remote (slidewright-remote.mjs, zero dependencies).
For a deck scaffolded before the remote existed:

bash scripts/add-remote.sh <path-to-deck>

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/deck-types.md — the six deck types and each one's arc, voice, and
  prohibitions. Read it before writing slide content.
• 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.
• references/remote-control.md — phone remote: running it, the deck API contract,
  security, troubleshooting (wrong IP, firewall, venue Wi-Fi).
• scripts/new-html-deck.sh — scaffold a plain-HTML deck.
• scripts/new-react-deck.sh — scaffold a Vite + React deck.
• scripts/add-remote.sh — add the phone remote to an existing deck.
• assets/remote/slidewright-remote.mjs — the phone remote: WebSocket relay, remote
  page, terminal QR code, static server (HTML track) and Vite plugin (React track).
  The scaffolds copy it into each deck; edit this source, not the copies.
• scripts/export-deck-pdf.py — export a deck to a content-complete PDF (waits for render
  and reveals hidden content; image-based).
• scripts/verify-slides.sh — static analysis of deck files: flags text below the
  typography floor, fixed-px font sizes, excessive bullet counts, and high word density
  per slide. Run after building slides and before handoff.