/frontend-slides
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
$ npx -y skills add dreamid27/frontend-slides --skill frontend-slides --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/frontend-slides
Context preview
The summary Claude sees to decide when to auto-load this skill.
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
SKILL.md
frontend-slides.SKILL.mdname: 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
Read more
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
A coding-agent skill for creating stunning HTML presentations — from scratch or by converting PowerPoint files. It is packaged as a Claude Code plugin, and the core SKILL.md can also be read by other coding agents with filesystem and shell access.
Repo: dreamid27/frontend-slides