# frontend-slides-editable: AI generated decks that you can still edit

> This is a skill for Claude Code and Codex that generates animated single-file HTML presentations and then hands you a browser editor to finish the job: drag objects, resize blocks, edit text, reorder slides, save locally and export clean standalone HTML. It ships 46 style presets and can port existing HTML templates.

**archlizheng/frontend-slides-editable** — Editable HTML presentation skill for Codex/Claude Code with drag-resize editing, slide reordering, local save/export, and PPTX-to-web conversion. Shout out to @zarazhangrui 

- Repository: https://github.com/archlizheng/frontend-slides-editable
- Stars: 536 · Forks: 52
- Language: HTML
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/archlizheng-frontend-slides-editable

## The problem the project names

The repository description is a single bilingual line that states the problem precisely. The Chinese version says it turns AI-generated presentations into single-file HTML that you can keep editing, and the English version says to create stunning single-file HTML decks that stay editable after generation.

That is a real and specific complaint about the current state of AI-generated slides. The agent produces something that looks good in the chat window and is useless as a document, because the only way to change a word is to regenerate the whole thing and hope the animation timings survive.

The readme puts it in the subhead too, framed as a request for a Star: if this skill helps your decks go from one-shot generation to something you can keep polishing, a Star helps more people find it. That framing is deliberate, because the project is not trying to be a slide generator, it is trying to be a bridge between generation and editing.

The scope is narrow and worth stating precisely. It is a skill for Claude Code and Codex, not a library and not a web application. The primary language is HTML, the licence is MIT, and the badge row states the three things that define the artefact: a Claude Code and Codex skill, single-file HTML output, and 46 presets.

The recent releases are v2.2.0 from 2026-05-24 and v2.1.0 from 2026-05-14, and the last push was on 2026-07-01, so the project is in the middle of a rewrite of the editing runtime rather than in maintenance. The description also credits one person by name for the work, so the scope of what the project owes any single contributor is wide.

The top level of the repository shows what is in it. There is a SKILL.md, which is the skill definition the agent reads, a STYLE_PRESETS.md, an animation-patterns.md, an html-template.md, an editor-runtime.md describing how the editor works, and a viewport-base.css. There is a docs/ directory, an examples/ directory, a scripts/ directory and a beautiful-html-templates/ directory holding the upstream templates the ported presets are derived from.

## The editing runtime, and the two kinds of object

The 2.0 highlights section is dense, and it is the part that explains what the editor actually does. Two ideas carry most of it.

The first is the distinction between slots and objects. Native content in a real template, its title, body text, metrics and images, is edited in place through data-edit-slot markers, so the original layout of the template is preserved and does not get pulled apart. Only objects added through the Add element command are freely draggable and resizable. The readme is explicit that the grids, textures, hairlines, glitch treatments and paper systems of a ported template remain locked, while user-added objects stay movable.

That distinction is the design idea worth understanding. A presentation template has a layout, and a layout is the thing that makes it look designed rather than assembled. If every element could be dragged, the deck would degrade into a pile of boxes the first time somebody moved a heading. Locking the template skeleton and only freeing the content is how you get an editor that does not destroy the thing it is editing.

The second is that the export is clean. Export strips the editor-only upload UI and file inputs from the output, so what you ship is the deck and not the machinery you built it in.

The rest of the highlights are the ordinary work of making an editor pleasant. Add element inserts text, image and video placeholders on the current slide from edit mode, wired into the undo and redo stack. Images and video can be picked as local files and embedded as data URLs so the file stays self-contained, images can be pasted with Ctrl or Cmd and V when the focus is not in rich text, and double-clicking existing media replaces it.

Resize handling got specific attention. Selecting an object gives you a corner handle plus right and bottom edge handles, so you can adjust along a single edge. Images and video inside a slide no longer clamp to a global max-height, so resizing the frame actually scales the visible media with object-fit set to contain, rather than leaving a small image floating in a large box.

The rich text toolbar collects font and size controls into drawers, and custom pixel sizes use an inline numeric field with an Apply button rather than a prompt call, because a prompt is not available in some embedded environments. Where possible, changing font or size from the toolbar preserves the text selection.

Objects and pages got the safer treatment: a per-object delete control, and better confirmation copy when deleting a slide.

## Presentation tools, and the deliberate removal of the trail

The presentation tools entry is worth reading closely, because one of its changes is a removal rather than an addition.

The top-left hover cluster now includes Laser and Fullscreen. The Laser gives a pure laser dot, and the trailing-stroke effect was removed by design. The dot follows the pointer, it exits on entering edit mode or pressing Esc, and no trail nodes are ever created. Fullscreen uses the browser Fullscreen API.

So this is a feature that was made simpler on purpose. A laser pointer with a fading trail is a common presentation flourish, and it is also a source of DOM churn, since every movement of the pointer would create and then remove nodes. Removing the trail means the laser is a single element that moves, which is cheaper and cannot leave debris behind when the presentation ends.

That kind of decision, a feature deliberately reduced to its simplest form because the complicated version had costs, is a good sign about how the runtime was engineered.

The other half of the entry is the mode interaction, which is stated plainly: the laser exits on entering edit mode or on Esc. That matters because the editor and the presentation are the same document, and anything the presentation mode leaves behind is something the editor has to tolerate.

Elsewhere in the highlights, deleting slides got safer confirmation copy, and objects carry their own delete control rather than relying on a selected-state menu, which is the right pattern for a touch-driven editor.

## Where the 46 presets come from

The presets section explains something that would otherwise look inconsistent, and it is a good example of a build pipeline that grew organically and was then documented.

The examples/generated/presets/ directory is maintained in two layers. Twelve legacy presets still come from scripts/build-preset-decks.py, and they exist for runtime smoke testing and for the visual preview gallery. Thirty-four ported presets are generated by scripts/build-template-port-decks.py from real upstream templates, and they preserve the original CSS, fonts, slide classes and decorative vocabulary, while using the shared Swiss and reference editor plus a locked slot adapter. Overlapping output names are intentionally replaced by the ported layer, which is what keeps the final count at 46 preset files.

So the 46 presets split into two populations with different provenance. Twelve are original to this project. Thirty-four are ports of real templates from the local beautiful-html-templates index, and the ported ones are the ones with the depth, because they carry an actual design system rather than a house style.

The template ports entry gives the detail. Ported coverage includes all 34 templates in the local index. Output slugs default to the upstream slug, while the original seven keep compatibility aliases such as signal-gold.html, studio-volt.html and monochrome-ledger.html. The files adapt the source template at beautiful-html-templates/templates/{source_slug}/template.html, and the data-edit-slot content uses the Swiss rich text, undo, redo, save and export experience, while the grids, textures, hairlines, glitch treatments and paper systems remain locked.

There is a preview gallery in the readme showing three of the results, Cobalt Grid, Studio and Soft Editorial, each linking to the generated preset file and each with a cover image in docs/preset-previews/. The gallery is built from the presets directory rather than from separate mock-ups, which is the right arrangement, because a preview that is generated from the real artefact cannot drift from it.

The point of the two-layer structure is that the legacy layer is a test fixture and the ported layer is the product. The smoke tests run against the generated decks, and the newer presets are the ones you would actually pick from.

## The repository, the build and the reference files

The package.json in the repository is almost empty, with a single runtime dependency, puppeteer-core at version 25.1.0. That is a small signal about how the project is built.

The output is HTML, so there is no build step for the decks themselves. What needs a browser is the preview generation, the preset cover images and any screenshot-based check of a generated deck, and puppeteer-core is a browser automation library that drives an existing Chrome rather than downloading one. So the dependency is there for producing the gallery and for verification, not for the artefact.

The dependency list in full is short enough to show:

```json
{
  "dependencies": {
    "puppeteer-core": "^25.1.0"
  }
}
```

The examples directory holds the reference files a new user should look at first. There is examples/editable-deck-reference.html, which is presumably the canonical demonstration of the editing runtime, and examples/frontend-slides-editable-skill-intro-bilingual.html, which is the introductory deck for the skill itself in both languages. There is examples/pitch-deck-readme-editable-fork.html, a pitch deck built with the editable fork, and then examples/demos/ and examples/generated/.

The documentation is split across the top level rather than living only in docs/. The SKILL.md is what the agent itself reads, so it is written for a model rather than for a person, and STYLE_PRESETS.md, animation-patterns.md, html-template.md and editor-runtime.md are the supporting references the skill points at.

There is also a package-lock.json and a .gitattributes and .gitignore, and the MIT licence is at the top level.

For anyone evaluating this, the shortest useful path is to open the reference deck in a browser, use the editor on it, export it and look at the result, and then read the documentation map section of the readme. That tells you what the editing runtime does before you ask an agent to generate anything at all.

## Conclusion

Adopt frontend-slides-editable if you generate decks with an agent and find that the output is always disposable, because the built-in editor is the difference between a first draft and a deck you can keep working on. Do not adopt it if you need to hand the deck to someone who will open it in PowerPoint, because the deliverable is HTML. Before you commit, read STYLE_PRESETS.md and the documentation map in the repository, and try the reference deck in examples/ before generating anything of your own.

## FAQ

### What is frontend-slides-editable?

It is a skill for Claude Code and Codex that generates animated, single-file HTML presentations with a built-in browser editor. You can drag objects, resize blocks, edit text, reorder slides, save locally and export a clean standalone HTML file. The project is MIT licensed and its primary language is HTML.

### What is the difference between slots and objects in frontend-slides-editable?

Native template content such as titles, body text, metrics and images is edited in place through data-edit-slot markers so the template layout is preserved and stays locked, while objects added with Add element are freely draggable and resizable. The readme makes clear that grids, textures, hairlines, glitch treatments and paper systems remain locked in ported presets.

### Where do the 46 style presets in frontend-slides-editable come from?

From two build layers. Twelve legacy presets are generated by scripts/build-preset-decks.py and serve as runtime smoke tests and visual previews, while 34 ported presets are generated by scripts/build-template-port-decks.py from real upstream templates, preserving their original CSS, fonts, slide classes and decorative vocabulary. Overlapping names are replaced by the ported layer, keeping 46 final preset files.

### What does the export from frontend-slides-editable produce?

A clean standalone HTML file. The export strips the editor-only upload UI and file inputs so the shipped artefact is the deck rather than the editing machinery. Media added through the editor is embedded as data URLs so the file stays self-contained, and the original seven presets keep compatibility aliases such as signal-gold.html and studio-volt.html.

### What does frontend-slides-editable require to build or generate?

The repository has a single runtime dependency, puppeteer-core at version 25.1.0, which drives an existing Chrome for preview generation and verification rather than for the HTML output itself. The deck output needs no build step, and the repository includes a reference deck, a bilingual skill introduction and a pitch deck under examples/ for trying the editing runtime.

## Sources

- [archlizheng/frontend-slides-editable on GitHub](https://github.com/archlizheng/frontend-slides-editable)
- [Issues](https://github.com/archlizheng/frontend-slides-editable/issues)
- [License: MIT](https://github.com/archlizheng/frontend-slides-editable/blob/main/LICENSE)
- [README](https://github.com/archlizheng/frontend-slides-editable/blob/main/README.md)
- [Releases](https://github.com/archlizheng/frontend-slides-editable/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/archlizheng-frontend-slides-editable