Frontend Slides: an agent skill that builds HTML decks from a visual preview

The problem Frontend Slides targets: decks that depend on a build pipeline

Most web presentation tooling assumes you will keep a project around. You install a framework, write components, run a dev server, and ship a bundle. That is reasonable for a product site and wasteful for a conference talk. Frontend Slides takes the opposite position. The README states the output is a single HTML file with inline CSS and JS, with no npm, no build tools and no frameworks. The audience is people who can describe a deck but not style one: the README frames the skill as helping non-designers create web presentations without knowing CSS or JavaScript.

The second audience is narrower and more interesting. Because the core instructions live in SKILL.md, the project is not locked to one vendor. The README lists Codex, Kimi Code, OpenCode and Gemini CLI as agents that can read the same core skill if they have filesystem and shell access. That packaging choice matters more than any individual template, and it is the reason the project is worth a look even if you do not use Claude Code.

How the skill works: progressive disclosure instead of one giant prompt

The repository is a set of documents, not a runtime. SKILL.md is the entry point; STYLE_PRESETS.md, viewport-base.css, html-template.md, animation-patterns.md, the bold-template-pack directory and the scripts directory are support files the agent loads when it needs them. The README describes this as loading only the referenced support files it needs. The v2.0.0 release name, Progressive Disclosure Restructure, suggests this layering was deliberate rather than incidental.

The style discovery flow is the part with real design behind it. The agent asks about content, then generates three visual previews: one safe preset from STYLE_PRESETS.md, at least one bold template drawn from bold-template-pack/selection-index.json, and one wildcard that is either another bold template or a self-generated design. The README is explicit that the agent reads the compact index first, loads only the shortlisted candidates' preview.md cards for title-slide previews, and loads the full design.md for exactly one bold template after the user chooses it. That is a real constraint on context: 34 bold design systems exist, but only one full design file is ever pulled in for the final deck.

PowerPoint conversion is a separate path. The README says the skill extracts all text, images and notes, shows the extracted content for confirmation, and then generates the HTML presentation with the original assets. The extraction is handled by scripts/extract-pptx.py, and the confirmation step is a checkpoint rather than a formality: if the extraction drops a diagram, you see it before the deck is built.

Installing Frontend Slides in Claude Code and running a first deck

There are two install paths and they produce different command names. The plugin route uses a custom marketplace source. The README warns that these must be sent as two separate Claude Code messages, not pasted together, and that you should use the HTTPS URL because the shorter owner/repo form may make Claude Code attempt SSH.

/plugin marketplace add https://github.com/zarazhangrui/frontend-slides

After that finishes, install the plugin:

/plugin install frontend-slides@frontend-slides

Plugin-installed skills are namespaced, so the invocation is /frontend-slides:frontend-slides. A manually installed skill is not namespaced and is invoked as /frontend-slides. The manual route copies the skill files into your Claude Code skills directory:

mkdir -p ~/.claude/skills/frontend-slides/scripts
cp SKILL.md STYLE_PRESETS.md viewport-base.css html-template.md animation-patterns.md ~/.claude/skills/frontend-slides/
cp -R bold-template-pack ~/.claude/skills/frontend-slides/
cp scripts/extract-pptx.py scripts/deploy.sh scripts/export-pdf.sh ~/.claude/skills/frontend-slides/scripts/

Or clone the repository straight into place:

git clone https://github.com/zarazhangrui/frontend-slides.git ~/.claude/skills/frontend-slides

A first real run is a sentence, not a config file. Invoke the skill and describe the deck:

/frontend-slides:frontend-slides

> "I want to create a pitch deck for my AI startup"

What you should see, per the README, is a short interview about content, then three style previews, then a choice, then the finished deck opened in your browser. For an existing file the phrasing changes to "Convert my presentation.pptx to a web slideshow", and the skill shows extracted content for confirmation before generating. The scripts directory also contains deploy.sh and export-pdf.sh, but the README excerpt does not document their flags or behaviour, so treat them as unresolved until you read them.

Where Frontend Slides breaks down

The honest limitation is the one the README advertises as a feature. A single HTML file with inline CSS and JS is portable and also unversioned. There is no component library, no design token file, and no diff-friendly structure: change one slide's layout and you are editing generated markup. If three people maintain a recurring deck, this is the wrong tool, and a framework with a real component model will cost you less over a quarter.

The second failure mode is agent dependency. The skill is instructions, so its quality tracks the model reading them. An agent that cannot browse files, or that ignores the instruction to load only the shortlisted preview cards, will either miss the bold template pack or flood its context with all 34 design systems. The README's progressive disclosure rules are a contract with the agent, not an enforcement mechanism.

The third gap is documentation. The README describes the conversion flow but does not document rollback if a generated deck is wrong, does not state which PowerPoint features survive extraction beyond text, images and notes, and does not give flags for deploy.sh or export-pdf.sh. The fixed 16:9 format is also a constraint worth naming: a deck built for a 16:9 stage is not the same artifact as a responsive page, and the README presents the fixed ratio as a quality property rather than a trade-off.

Frontend Slides versus reveal.js and Marp

reveal.js and Marp solve the same surface problem with a different architecture. reveal.js is a JavaScript library you author against: you write HTML sections, configure a presentation object, and the library handles navigation, transitions and speaker notes at runtime. Marp is a Markdown-to-slides compiler with a CLI and editor integrations, so the source of truth is a text file and the slide structure comes from horizontal rules. Both give you a stable authoring format and a toolchain you can pin.

Frontend Slides inverts that. There is no runtime library to configure and no Markdown dialect to learn; the source of truth is a prompt plus a chosen visual direction, and the artifact is a finished file. The practical difference shows up on the second edit. With Marp you change a line of Markdown and recompile. With reveal.js you edit a section and reload. With Frontend Slides you ask the agent again, and the result depends on what it regenerates. If your deck is a living document, a compiler or a library is the better fit. If your deck is a one-shot artifact that has to look distinctive and ship as a file, the agent route removes the setup cost that the other two impose.

Licence, maintenance and the cost of upgrading

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the permissive end of the spectrum and it means you can vendor the skill files into an internal repository without a legal review cycle. The usual caveat applies: MIT grants rights in the code and documents, not in any third-party assets a deck might embed, and the README does not describe a separate asset licence for the beautiful-html-templates designs that the bold pack draws from.

On maintenance, the last push was on 2026-05-26, which is the same date as the v2.1.0 release, Bold Templates and Agent-Neutral Packaging. The previous release, v2.0.0, was on 2026-03-04. Two releases roughly three months apart, then no pushes for the following months, is a project that moves in bursts rather than continuously. The repository is not archived. Upgrade cost is low by construction: there is no package to bump, so an upgrade means re-copying SKILL.md and the support files, or re-running the marketplace install. The real cost is re-testing a template you already used, because a restructured SKILL.md can change how the agent picks previews.

Editorial conclusion

Adopt Frontend Slides if you already drive Claude Code or another filesystem-capable agent and you need a one-off deck that must survive without a build pipeline: a single HTML file with inline CSS and JS is something you can email or drop on any static host. Do not adopt it if you need a maintained slide framework with a versioned component API, or if your decks are edited by non-technical colleagues on a schedule, because the output is generated code rather than a constrained editor. Verify first that your agent can read the repository files, that the PPTX extraction step handles your file's embedded assets, and that the bold template you pick actually renders at your target viewport before you commit a talk to it.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes