frontend-slides-frontend-slides

name	frontend-slides-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 ta
category	Document Processing
source	antigravity
tags	["python","react","node","pdf","pptx","ai","agent","automation","workflow","template"]
url	https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/frontend-slides-frontend-slides

Frontend Slides

When to Use

Use this skill when you need 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...

Create zero-dependency, animation-rich HTML presentations that run entirely in the browser.

Core Principles

1. Zero Dependencies — Single HTML files with inline CSS/JS. No npm, no build tools.
2. Show, Don't Tell — Generate visual previews, not abstract choices. People discover what they want by seeing it.
3. Distinctive Design — No generic "AI slop." Every presentation must feel custom-crafted.
4. Progressive Disclosure — Read lightweight style indexes first. For bold templates, use small preview cards for style previews and load the full design.md only after the user picks that template.
5. Fixed 16:9 Stage (NON-NEGOTIABLE) — Every deck uses a 1920×1080 slide canvas scaled as a whole to the viewport. Slides must stay 16:9 on every screen, including phones. Do not reflow slide content to fit the device.

Design Aesthetics

You tend to converge toward generic, "on distribution" outputs. In frontend design, this creates what users call the "AI slop" aesthetic. Avoid this: make creative, distinctive frontends that surprise and delight.

Focus on:

• Typography: Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter; opt instead for distinctive choices that elevate the frontend's aesthetics.
• Color & Theme: Commit to a cohesive aesthetic. Use CSS variables for consistency. Dominant colors with sharp accents outperform timid, evenly-distributed palettes. Draw from IDE themes and cultural aesthetics for inspiration.
• Motion: Use animations for effects and micro-interactions. Prioritize CSS-only solutions for HTML. Use Motion library for React when available. Focus on high-impact moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more delight than scattered micro-interactions.
• Backgrounds: Create atmosphere and depth rather than defaulting to solid colors. Layer CSS gradients, use geometric patterns, or add contextual effects that match the overall aesthetic.

Avoid generic AI-generated aesthetics:

• Overused font families (Inter, Roboto, Arial, system fonts)
• Cliched color schemes (particularly purple gradients on white backgrounds)
• Predictable layouts and component patterns
• Cookie-cutter design that lacks context-specific character

Interpret creatively and make unexpected choices that feel genuinely designed for the context. Vary between light and dark themes, different fonts, different aesthetics. You still tend to converge on common choices (Space Grotesk, for example) across generations. Avoid this: it is critical that you think outside the box!

Fixed Stage Rules

These invariants apply to EVERY slide in EVERY presentation:

• Every deck has a viewport wrapper that fills the browser window.
• Every slide is authored inside a fixed 1920×1080 stage.
• The stage scales uniformly to fit the viewport. It may letterbox/pillarbox; it must not re-layout content.
• Do not use responsive breakpoints to rearrange slide content for phones.
• Use fixed internal slide measurements at the 1920×1080 design size.
• Slide visibility must be controlled by .active / .visible using visibility, opacity, and pointer-events from viewport-base.css. Do not use display: none / display: block for slide switching; later layout classes such as .slide-content { display: flex; } can override them and make every slide visible at once.
• Use clamp() only for non-slide UI outside the stage, or for small fallback previews where a full stage is impractical.
• Include prefers-reduced-motion support
• Never negate CSS functions directly (-clamp(), -min(), -max() are silently ignored) — use calc(-1 * clamp(...)) instead

When generating, read viewport-base.css and include its full contents in every presentation.

Content Density Modes

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

Density mode	Best for	Design behavior
Low density / speaker-led	Public talks, keynote-style sharing, live explanation	One idea per slide, large type, strong visual hierarchy, generous negative space, 1-3 bullets max, more slides if needed
High density / reading-first	Reports, handouts, async review, detailed internal docs	More self-contained slides, structured grids/tables/annotations, 4-8 bullets or 4-6 cards when readable, tighter but still intentional spacing

Baseline limits still apply: no scrolling, no overflow, no overlapping panels, and no text below comfortable reading size. If content exceeds the selected density m