# Frontend Slides Editable

> Use when the user wants a single-file HTML presentation that stays editable in the browser after generation, or needs object-level layout editing, slide reordering, local save/export, or PPT/PDF-to-web conversion with continued editing.

- **Type:** Skill
- **Install:** `agentstack add skill-archlizheng-frontend-slides-editable-frontend-slides-editable`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [archlizheng](https://agentstack.voostack.com/s/archlizheng)
- **Installs:** 0
- **Category:** [Web & Browser](https://agentstack.voostack.com/c/web-and-browser)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [archlizheng](https://github.com/archlizheng)
- **Source:** https://github.com/archlizheng/frontend-slides-editable

## Install

```sh
agentstack add skill-archlizheng-frontend-slides-editable-frontend-slides-editable
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

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 [STYLE_PRESETS.md](STYLE_PRESETS.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"`
3. 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.
4. 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.
5. 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 [STYLE_PRESETS.md](STYLE_PRESETS.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](https://github.com/archlizheng)
- **Source:** [archlizheng/frontend-slides-editable](https://github.com/archlizheng/frontend-slides-editable)
- **License:** MIT

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

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-archlizheng-frontend-slides-editable-frontend-slides-editable
- Seller: https://agentstack.voostack.com/s/archlizheng
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.