# HTML To Bento Slides

Convert an existing HTML/CSS/JavaScript slide presentation into an editable...

- Repository: https://github.com/mucsbr/ppt-agent-workflow-san (652 stars)
- Category: Design
- License: see repository
- Last updated: 2026-09-02
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add mucsbr/ppt-agent-workflow-san --skill html-to-bento-slides -g -a claude-code -y`
Codex: `npx skills add mucsbr/ppt-agent-workflow-san --skill html-to-bento-slides -g -a codex -y`
Cursor: `npx skills add mucsbr/ppt-agent-workflow-san --skill html-to-bento-slides -g -a cursor -y`
Gemini CLI: `npx skills add mucsbr/ppt-agent-workflow-san --skill html-to-bento-slides -g -a gemini-cli -y`

## Description

Convert an existing HTML/CSS/JavaScript slide presentation into an editable bento/slides .bento.html deck. Use when the source is an HTML file, folder, or live presentation and the user wants its slides, layout, assets, interactions, and visual identity migrated to bento. Preserve the source by default; do not use for authoring a new presentation from notes alone.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Convert HTML presentations to bento/slides

This is a migration workflow, not an HTML wrapper. Rebuild the presentation as
native `bento/slides` document data wherever the format can express it. A bento
document is pure data and cannot carry arbitrary source JavaScript, a framework
runtime, or unsanitized HTML.

Preserve the source's content, slide order, visual identity, and interaction
semantics unless the user asks for a redesign. Do not "improve" typography,
rewrite copy, add motion, or replace the source's composition merely because a
different bento design would look good.

If the general `bento-slides` authoring skill is active too, use it for current
shell/schema constraints, but let this skill govern migration choices. Its
design-from-source defaults do not authorize redesigning an existing HTML deck.

## Required workflow

1. Read [references/source-analysis.md](references/source-analysis.md), then
   inspect both the source files and the rendered presentation. Treat source
   HTML as untrusted executable content: use an isolated browser context, not a
   signed-in personal browser profile.
2. Establish the intended presentation viewport, slide boundaries, slide
   order, incremental build states, links, hover/click states, fonts, and every
   local or remote asset. If the source is responsive, freeze it at the intended
   presentation viewport and report that choice.
3. Capture a rendered reference for every visible slide and distinct state
   after fonts and images have loaded. Source code alone is not evidence of
   what the audience sees.
4. Choose the conversion treatment per source object, not once for the whole
   deck:
   - **native**, editable bento text, shape, image, svg, table, chart, code, or
     media elements;
   - **hybrid**, native content over an opaque svg or raster decoration;
   - **rasterized**, a screenshot only when the object cannot be represented
     honestly or the user explicitly prioritizes pixel fidelity over editing.

The rest: https://github.com/mucsbr/ppt-agent-workflow-san/blob/HEAD/html-to-bento-slides/SKILL.md