frontend-slidesSAFE
Create beautiful slides on the web using a coding agent's frontend skills
Overview
From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.
This pack brings the beautiful-html-templates design systems into the frontend-slides skill without making them the default for every deck.
What To Read
- Read
bold-template-pack/selection-index.jsonfirst. - Shortlist candidates from metadata only:
moodtonebest_foravoid_forformalitydensityscheme- For title-slide previews, read only the relevant candidate
preview.md
files.
- After the user chooses a bold template, read exactly that one template's
full design.md.
- Do not read every
design.mdin the pack. - Do not read or copy
template.htmlfrom the source template library unless a
selected design.md is missing a critical implementation detail.
The full source metadata index is not bundled in the user-facing skill. Normal generation should use selection-index.json only.
How To Use In Frontend Slides
Preview mix:
- 1 safe option from
STYLE_PRESETS.md - at least 1 bold option from this pack
- 1 wildcard option, which may be another bold template from this pack or a
self-generated custom design
Adjust the tone inside that default mix:
- For board, legal, regulatory, healthcare, investor-update, or highly formal
internal decks, make the safe option very restrained and choose calmer, higher-formality bold templates. The wildcard should feel authoritative and specific, not merely decorative.
- For bold, editorial, expressive, experimental, or highly designed decks, keep
the safe option as a readable fallback, choose one strong bold template, and use the wildcard for either a second adventurous template or a custom design that better matches the user's occasion and vibe.
If the wildcard is custom, it must follow Frontend Slides' no-slop aesthetics: distinctive typography, a committed palette, a recognizable layout system, a context-specific visual idea, fixed 16:9 stage behavior, and no visible process labels such as "custom", "wildca
6ef92979dd76OBSERVED · 2026-10-06Host compatibility
What the documentation claims. We have not run a compatibility test.
| Host | Status | Notes |
|---|---|---|
| cursor | mentioned |
What it tells the agent
The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.
---
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 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 mode, split it into more slides instead of shrinking until it becomes cramped.
---
## Phase 0: Detect Mode
Determine what the user wants:
- **Mode A: New Presentation** — Create from scratch. Go to Phase 1.
- **Mode B: PPT Conversion** — Convert a .pptx file. Go to Phase 4.
- **Mode C: Enhancement** — Improve an existing HTML presentation. Read it, understand it, enhance. **Follow Mode C modification rules below.**
### Mode C: Modification Rules
When enhancing existing presentations, fixed-stage fitting is the biggest risk:
1. **Before adding content:** Count existing elements, check against density limits
2. **Adding images:** Fit them inside the 1920×1080 slide canvas. If slide already has max content, split into two slides
3. **Adding text:** Max 4-6 bullets per slide. Exceeds limits? Split into continuation slides
4. **After ANY modification, verify:** the slide stage remains 16:9, no text overflows its card, no panels overlap, and screenshots look corTrust audit
SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | PASS |
| L1 | Static analysis of the code | PASS |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- none-observed
- Network
- none-observed
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- none-found
Findings (0)
No findings outside the package's declared scope.
Gates applied: no_behavioural_pass.
6ef92979dd76full audit observations/trust-audit/skill/zarazhangrui__frontend-slides.json · Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-06 | 6ef92979dd76 | SAFE | B | 89 | first audit |
Questions
What does the frontend-slides skill do?
Create beautiful slides on the web using a coding agent's frontend skills
Is frontend-slides safe to install?
The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean skill reads B.
What can frontend-slides access on my machine?
The audit observed no filesystem, network or shell use at all in its source.
Which assistants does frontend-slides work with?
Its documentation mentions cursor. That is what the text claims, not a compatibility test we ran.
How current is this page?
The grade is for one exact copy of the source (6ef92979dd76), read on 2026-10-06. The repository is watched, and a new audit runs when it changes — this is the first audit.