/superloopy-slides

name: superloopy-slides
description: >-
  Use when the user asks to create, convert, style, animate, export, share, or
  deploy HTML slide decks, presentations, pitch decks, talks, or keynotes;
  including zero-dependency or single-file output, PowerPoint/PPT/PPTX input,
  PDF export, browser delivery, visual style exploration, or "loopy slides".
  Not for general web pages or landing pages.

Superloopy Slides

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

> **Live example** — a multilingual deck built with this skill: <https://fileloom-slides.pages.dev> (English · 한국어 · 中文 · 日本語 · Español; single-file, embed-safe, on a fixed 16:9 stage).

This is a Superloopy skill: the deck is done only when a real-browser visual artifact proves it renders correctly — never when the HTML "looks complete" in source. Completion requires an artifact under the active evidence root via `SUPERLOOPY_EVIDENCE`.

Activation

Open your reply with `SUPERLOOPY SLIDES ENABLED`. If another active Superloopy mode mandates its own first line, print that first and this marker on the next line.

The anti-slop design rules below are this skill's own instance of the `superloopy-frontend` [anti-slop contract](../superloopy-frontend/references/anti-slop.md), specialized for the fixed 1920×1080 slide stage. A presentation is campaign/editorial surface, so that contract's non-waivable core binds every deck: honest assets (no div-mock passed off as a product capture, no unauthorized marks, no invented metrics or testimonials), no shipped placeholder names/brands/filler copy, and a named authority for every kept default or waived check. Do not open a second superloopy-frontend pass on top of a deck — this skill owns the visual layer for presentations, including the evidence gate.

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.
• **Embed-safe + standalone-safe (NON-NEGOTIABLE)** — every deck must render correctly BOTH opened directly AND inside an iframe (Confluence "Advanced HTML & Iframe Embed" macro, Notion, etc.). Use the dual-mode scaler from `html-template.md`: detect iframes (`window.self !== window.top` in try/catch), add `.embed` to `<html>`, scale by width only in embed mode, and set `window.frameElement.style.height` in a try/catch for same-origin hosts. Never `position:fixed` for the viewport or chrome; never rely on `vh`/`%` heights in embed mode — an auto-height iframe computes them as ~0 and locks the collapsed height in.
• Keep ALL presentation chrome (controls, counter, progress, nav dots) inside `.deck-stage`, after the slides, sized for the 1920×1080 canvas — chrome outside the stage does not scale in iframes and overlaps content when the deck shrinks.
• 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 o