Frontend Slides Editable

Frontend Slides (Editable)

Create zero-dependency, animation-rich HTML presentations that run entirely in the browser with a built-in editor: move objects, multi-select with Ctrl+click, alignment snapping, simple text formatting with font family + size controls, undo/redo, a Pages sidebar (slide thumbnails, drag to reorder, delete), Ctrl+S persistence, and export HTML.

This skill is a copy of the frontend-slides skill extended with the editable deck runtime. For read-only decks without editor weight, use the original frontend-slides skill instead (same skills directory layout).

Parity with parent frontend-slides (style flexibility)

Adding edit mode must not replace preset authoring. The parent skill treats each choice in [STYLEPRESETS.md](STYLEPRESETS.md) as a spec: per preset you implement its Layout prose, Signature Elements, typography, and colors — title slides and content slides differ across presets (e.g. Bold Signal’s card + big numerals vs. Notebook Tabs’ paper + edge tabs vs. Swiss Modern’s grid + red bar).

Normative behavior in Phase 3:

1. Read STYLE_PRESETS for the chosen preset(s) and reflect layout + signatures in HTML/CSS, not only :root colors and fonts.
2. The editable reference ([examples/editable-deck-reference.html](examples/editable-deck-reference.html)) supplies JS/CSS patterns (chrome, sidebar, objects, history) — not a frozen slide layout to paste on every deck. Do not reuse one generic “title + subtitle + corner rounded rectangle” geometry for every style.
3. examples/generated/presets/*.html are sample decks, not a layout shortcut. The 12 legacy samples are runtime smoke + visual previews; the 34 ported samples are real-template ports from beautiful-html-templates using the shared Swiss/reference runtime plus locked slot editing. For real deliveries, match the chosen preset/template grammar instead of reusing a generic README deck.
4. Static chrome (decorations that should not be draggable) may live outside .slide-edit-layer (e.g. background pseudo-elements, fixed nav chrome) per preset; movable copy and blocks stay as [data-slide-object] inside the layer.

If runtime constraints ever conflict with a signature element, adapt the element (e.g. implement the same visual with CSS, or split into multiple objects) — do not drop preset identity for the sake of a single template.

Real-template ports (slot-editable)

For the 34 ported presets from beautiful-html-templates, prefer the upstream template's mood / tone / density and visual grammar over color-token matching alone.

Interaction baseline: ported decks must use the same Swiss/reference editor chrome and object editor as examples/editable-deck-reference.html / swiss-modern.html. Native template slots are locked-layout content slots; user-added objects are normal [data-slide-object][data-oid] objects.

Important interaction contract: data-edit-slot is editable content, not a draggable component. In edit mode the user can click slot text/images to change their content with RTE/Undo/Redo/Save/Export, but the upstream template's layout grid, card geometry, decorative layers, and spacing stay locked. Only user-added objects in .slide-edit-layer become selectable, draggable, resizable components. Do not promise that every native template child will get object handles unless a separate componentization mode is explicitly requested and implemented.

Template edit modes:

• data-template-edit-mode="slots" is the default. It is template-safe: authored content is editable through slots, while layout and decoration remain locked.
• data-template-edit-mode="components" is an optional generated mode for semantic blocks that can be represented as [data-slide-object].
• In delivered ported decks, Unlock layout componentizes the current slide on demand by creating movable copies of editable slots in .slide-edit-layer. The original native template DOM stays in place for fidelity, and the operation is undoable.
• Never componentize every DOM node. Exclude backgrounds, grids, axes, ticks, decorative marks, texture/glitch layers, SVG paths, animation wrappers, and pure layout containers.

When using or extending a ported preset:

1. Treat the matching beautiful-html-templates/templates/{source_slug}/template.html as the visual system: preserve fonts, CSS variables, slide-level classes, layout grid, decorative DOM, and component grammar.
2. Edit authored content through slots, not by decomposing the template into draggable boxes. Use:

• data-edit-slot
• data-slot-type="text|image|metric|table-cell"
• data-slot-label
• data-slot-locked-layout="true"

1. Keep decorative elements locked unless the user should naturally change that exact item. Grids, paper texture, hairlines, scan lines, pixel/glitch layers, ornamental marks, and layout containers should not become draggable objects.
2. Preserve .slide-edit-layer for user-added freeform objects. Added objects can use [data-slide-object][data-oid] and the normal Swiss drag/resize/multi-select runtime; native template slots use the Swiss RTE/Undo/Redo/Save/Export path but do not get move/resize handles.
3. If a needed slide type is missing, design a new slide in the same template system: same fonts, palette, spacing rhythm, chrome, and component grammar. Do not mix in another template's visual language.

Discovery gate (do not skip)

Models often jump straight to generating HTML. For Mode A (new deck) and Mode B (PPT or PDF) after extraction, you must finish Phase 1 before Phase 2, and Phase 2 before Phase 3 — unless a narrow exception below applies.

Hard rule: Unless the user provides in one turn (or one clearly scoped batch) every item in the Phase 1 checklist, you must run Phase 1 first as one grouped message (or a structured question UI). If the batch is incomplete, send only the missing checklist items in the next message — do not guess slide count, outline depth, preset, or language. **Invoking /frontend-slides-editable or attaching this skill does not waive discovery. A one-liner (e.g. “用 skill 介绍它自己”, “做一份某某主题的演示”) is topic / intent only**, not a brief.

Phase 1 checklist (complete brief — all required without model inference):

| # | Dimension | What “done” means | |---|-------------|-------------------| | 1 | Purpose | Pitch / teaching / conference / internal / meta-role (e.g. skill onboarding), etc. | | 2 | Length | Slide-count band (e.g. short 5–10 / medium 10–20 / long 20+) or exact count — never inferred from topic alone | | 3 | Content | Pasted outline, bullets, draft copy, or named source + extract scope (e.g. “README §X–Y only”); not “a theme” alone | | 4 | Style direction | Phase 1 style preference cluster or a named preset from [STYLEPRESETS.md](STYLEPRESETS.md) or explicit delegation (“you choose”) — if only “you choose”, Phase 2 still runs to narrow via recommendations/previews unless the user also explicitly skips previews | | 5 | Editing | Confirm full editable runtime (this skill’s default) or explicit switch to parent read-only frontend-slides | | 6 | Images | No / yes / unsure; if yes, files may arrive later, but intent is explicit | | 7 | Mobile | Required answer: Desktop-first only (default) or Adapt for phone portrait + landscape; do not infer this silently | | — | Language / locale | When prose is audience-facing and not already stated: monolingual / bilingual / per-locale files — ask in Phase 1 |

Images vs outline: Co-design outline ↔ images (Step 1.2) only after the user has real assets or links to evaluate. Do not skip Phase 1 dimensions just because images are pending; capture “yes, will provide” in Phase 1, then run image evaluation when files exist.

Mode B (PPT / PDF): After extract-pptx.py (.pptx) or extract-pdf.py (.pdf), present titles/summaries/asset counts and still run Phase 1 for anything extraction does not decide: length goals if restructuring, style direction, editing scope, locale, and image handling notes on extracted assets. Do not jump from “here’s the extract” straight to only style picking — close Phase 1 gaps first, then Phase 2, then codegen.

When Phase 1 and/or Phase 2 may be shortened (narrow exceptions only):

1. Explicit opt-out — User clearly skips discovery and/or previews (e.g. “跳过发现，你全部决定”, “no discovery — just generate”).
2. Complete written brief — Same batch already satisfies every Phase 1 checklist row without you guessing, and either (a) a named preset is chosen so Phase 2 can be a direct handoff to Phase 3, or (b) the user explicitly allows no previews and accepts your single recommended preset.

Default order: Phase 1 (grouped) → Phase 2 (show, don’t tell) → Phase 3. Never start Phase 3 to “save turns.”

Partial answers: Next message = only missing Phase 1 items, then resume Phase 2.

Never infer silence as approval. Mode C (enhance existing HTML): precise change list may skip full Phase 1–2; vague “make it better” → 1–2 clarifying questions first.

Anti-pattern: Generating HTML because the skill was attached or because you “already know” a good length or preset — failure mode.

Skipping discovery to “save turns” is a failure mode for this skill.

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. Viewport Fitting (NON-NEGOTIABLE) — Every slide MUST fit exactly within 100vh. No scrolling within slides, ever. Content overflows? Split into multiple slides.

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 CSS-only animations and transitions in generated decks (this skill outputs single-file HTML, no React and no Motion library). Focus on high-impact moments: one well-orchestrated load with staggered reveals (animation-delay) beats 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!

Viewport Fitting Rules

These invariants apply to EVERY slide in EVERY presentation:

• Every .slide must have height: 100vh; height: 100dvh; overflow: hidden;
• ALL font sizes and spacing must use clamp(min, preferred, max) — never fixed px/rem
• Content containers need max-height constraints
• Images: max-height: min(50vh, 400px)
• Breakpoints required for heights: 700px, 600px, 500px
• 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 Limits Per Slide

| Slide Type | Maximum Content | |------------|-----------------| | Title slide | 1 heading + 1 subtitle + optional tagline | | Content slide | 1 heading + 4-6 bullet points OR 1 heading + 2 paragraphs | | Feature grid | 1 heading + 6 cards maximum (2x3 or 3x2) | | Code slide | 1 heading + 8-10 lines of code | | Quote slide | 1 quote (max 3 lines) + attribution | | Image slide | 1 heading + 1 image (max 60vh height) |

Content exceeds limits? Split into multiple slides. Never cram, never scroll.

Phase 0: Detect Mode

Determine what the user wants:

• Mode A: New Presentation — Create from scratch. Go to Phase 1.
• Mode B: PPT / PDF conversion — Convert a .pptx or .pdf 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, viewport fitting is the biggest risk:

1. Before adding content: Count existing elements, check against density limits
2. Adding images: Must have max-height: min(50vh, 400px). 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: .slide has overflow: hidden, new elements use clamp(), images have viewport-relative max-height, content fits at 1280x720
5. Proactively reorganize: If modifications will cause overflow, automatically split content and inform the user. Don't wait to be asked

When adding images to existing slides: Move image to new slide or reduce other content first. Never add images without checking if existing content already fills the viewport.

Phase 1: Content Discovery (New deck & PPT/PDF path)

Centralize Phase 1: For Mode A and for Mode B after extraction, deliver the checklist in one grouped interaction (see Discovery gate above) — not dribbled across many turns. If the user’s first message is incomplete, only ask missing items next.

Do not jump to style previews or HTML until Phase 1 is satisfied (exceptions: Discovery gate).

Ask ALL discovery questions (1–6 below) in that grouped interaction when starting from scratch. Use a structured question tool when available; otherwise one concise message:

Question 1 — Purpose (header: "Purpose"): What is this presentation for? Options: Pitch deck / Teaching-Tutorial / Conference talk / Internal presentation

Question 2 — Length (header: "Length"): Approximately how many slides? Options: Short 5-10 / Medium 10-20 / Long 20+

Question 3 — Content (header: "Content"): Do you have content ready? Options: All content ready / Rough notes / Topic only

Question 4 — Style preference (header: "Style Pref"): What visual direction sounds closest as a starting point? Options:

• "Recommend for me" — infer from audience, topic, and content
• "Clean / Professional" — restrained, polished, trustworthy
• "Bold / Experimental" — high-contrast, energetic, surprising
• "Editorial / Warm" — human, crafted, story-forward
• "Technical / Minimal" — precise, structured, product-like
• "I already know the preset" — skip to a direct preset choice

Question 5 — Editing scope (header: "Editing"): Confirm the user wants the full editable runtime (default for this skill): object layout, Pages sidebar, undo/redo. If they explicitly want a minimal read-only file only, switch to the pa

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: archlizheng
• Source: archlizheng/frontend-slides-editable
• License: MIT

Install and usage instructions live in the source repository linked above.