/frontend-slides

name: frontend-slides
description: Create stunning, animation-rich HTML presentations from scratch or by converting PowerPoint files. Use when the user wants to build a presentation, convert a PPT/PPTX to web, or create slides for a talk/pitch. Helps non-designers discover their aesthetic through visual exploration rather than abstract choices.

Frontend Slides

Create animation-rich, Tailwind-styled HTML presentations that run entirely in the browser.

Core Principles

1. **Single file, no build step** — One self-contained HTML file. Tailwind via CDN script, fonts via Google Fonts/Fontshare. No npm, no build tools. 2. **Tailwind for all styling** — Utility classes in markup. Raw CSS only in the three sanctioned blocks (see Styling Conventions). 3. **Show, don't tell** — Generate visual previews; users discover taste by seeing options, not describing them. 4. **Distinctive design** — No generic "AI slop." Every deck must feel custom-crafted. 5. **Progressive disclosure** — Read lightweight style indexes first; load a full `design.md` only after the user picks that template. 6. **Fixed 16:9 stage (NON-NEGOTIABLE)** — Slides are authored at 1920×1080 and the stage scales as a whole to the viewport; never reflow content per device.

Styling Conventions (Tailwind)

Every deck and preview uses the same architecture:

• Load Tailwind in `<head>`: `<script src="https://cdn.tailwindcss.com"></script>`.
• Declare design tokens in an inline `tailwind.config` block — colors and fontFamily map to CSS variables or literal values (see [html-template.md](html-template.md)).
• Style everything with utilities in markup: layout, spacing, typography, color, borders, effects.
• Use arbitrary values for stage-pixel geometry: `left-[96px]`, `text-[168px]`, `tracking-[0.18em]`, `max-w-[1360px]`.
• Raw CSS lives in exactly three labeled `<style>` sections, nothing else:

1. **Stage mechanics** — the full contents of [viewport-base.css](viewport-base.css), pasted verbatim. 2. **Token definitions** — CSS variables (`--lp-*` for presets, theme vars for decks) that `tailwind.config` references. 3. **Choreography** — `@keyframes` plus `.slide.active`-scoped animation triggers (state-dependent animation can't be pure utilities).

• Elements keep one short semantic class (`lp-title`, `reveal`) only as an animation/JS hook — all visual styling stays in utilities.
• Never build class names dynamically in JS (`bg-${color}` breaks the CDN JIT); toggle complete class strings.
• No spaces inside arbitrary values — use underscores: `shadow-[0_8px_32px_rgba(0,0,0,0.3)]`.
• Negate CSS functions with calc: `right-[calc(-1*clamp(28px,3.5vw,44px))]`; a leading `-` before a function is silently dropped.

Design Aesthetics

You converge toward generic, "on distribution" outputs — the "AI slop" aesthetic. Actively resist it:

• **Typography:** pick beautiful, distinctive fonts; never Arial, Inter, Roboto, or system fonts.
• **Color:** commit to a cohesive palette via tokens; dominant colors with sharp accents beat timid, even distributions.
• **Motion:** prioritize CSS-only animation; one well-orchestrated staggered page load beats scattered micro-interactions.
• **Backgrounds:** build atmosphere with layered gradients, geometric patterns, or contextual effects — not flat default colors.

Avoid: purple-gradient-on-white clichés, predictable centered layouts, cookie-cutter card grids, and over-reused picks like Space Grotesk. Vary light/dark themes and aesthetics between generations.

Fixed Stage Rules

These invariants apply to EVERY slide in EVERY presentation:

• Every deck has a `.deck-viewport` wrapper filling the window and a `.deck-stage` fixed at 1920×1080.
• JS scales the whole stage uniformly (letterbox/pillarbox allowed); never re-layout content per device.
• No responsive breakpoints inside slides; author all measurements at the 1920×1080 design size.
• Slide switching uses `.active`/`.visible` via `visibility`/`opacity`/`pointer-events` from viewport-base.css — never `display: none`/`block`, which layout utilities like `flex` can override.
• `clamp()` is only for UI outside the stage or small fallback previews.
• Include `prefers-reduced-motion` support (shipped in viewport-base.css).

Content Density Modes

Ask whether this is a reading deck or a speaking deck, then design around the answer:

| Density mode | Best for | Design behavior | | --- | --- | --- | | **Low density / speaker-led** | Talks, keynotes, live explanation | One idea per slide, large type, 1–3 bullets max, generous negative space, more slides | | **High density / reading-first** | Reports, handouts, async review | Self-contained slides, structured grids/tables, 4–8 bullets or 4–6 cards, tight but intentional spacing |

Hard limits in both modes: no scrolling, no overflow, no overlapping panels, no uncomfortably small text. Split into more slides rather than shrinking content.

---

Phase 0: Detect Mode

• **Mode A: New presentation** — go to Phase 1.
• **Mode B: PPT conversion** — go to Phase 4.
• **Mode C: Enhancement** — read the existing HTML, then follow the modification rules below.

Mode C: Modification Rules

1. Before adding content, count existing elements against the density limits. 2. Adding images: fit inside the 1920×1080 canvas; if the slide is full, split into two slides. 3. Adding text: max 4–6 bullets per slide; split overflow into continuation slides. 4. After ANY modification verify: stage still 16:9, no text overflow, no panel overlap, screenshots correct at 1280×720 and one phone viewport. 5. Proactively split content that would overflow and inform the user — don't wait to be asked.

---

Phase 1: Content Discovery (New Presentations)

Ask ALL questions together (use the native structured-question UI if available, else one numbered message):

1. **Purpose** — Pitch deck / Teaching-Tutorial / Conference talk / Internal presentation. 2. **Length** — Short 5–10 / Medium 10–20 / Long 20+. 3. **Co