Bento Puts Slides in One HTML File

Bento is a Show HN project from its creator that turns a slide editor and deck into one HTML file. It deals with a specific annoyance: developers were making web-based decks with Claude Code, Anthropic's coding agent, then needing the agent or a manual code edit for every small slide tweak. Bento is a self-contained HTML slide deck: the editor, viewer, data, animations, and shared editing live in one file. The useful takeaway is not “make every deck an app”; it is to keep agent-editable data obvious, and use claude code hooks only as a small boundary when the file also contains code.

Open the file, edit the deck, keep the app

Bento’s pitch is wonderfully literal. You open one HTML file in a browser, edit the deck there, present from the same file, and keep working without an install or cloud login.

The creator described the default deck as roughly 560 KB and able to work offline after you have the file. That matters because a deck becomes something you can email, commit, grep, diff, and archive without a service account hanging off the side.

The clever part is the split inside the file. Near the top, Bento keeps a plain JSON block for slide data. The app itself is bundled separately, reportedly as a base64 blob loaded by a small shim.

That split is why developers paid attention. The JSON gives Claude Code or a human a sane edit target. The bundled app keeps the deck portable.

The trap is pretending the blob does not matter. Base64 makes people nervous, and fairly so. If your repo requires every shipped line to be reviewed as normal source, a bundled app blob is a policy decision, not just a packaging trick.

Notice why developers liked it

The story landed because many engineering decks have quietly become frontend projects. A design review deck might use React components, Mermaid diagrams, screenshots, motion, and a tiny amount of state. That is great until changing one bullet means reopening the harness and asking an agent to patch JSX.

Bento removes that loop for small edits. The agent can help build the initial material, but the presenter can still fix a typo, move a slide, or change a label in the browser.

There is also a mood here. Developers are tired of renting every artifact they create. A deck that is “just a file” feels boring in the best way.

The honest objection was animations. Someone wanted one switch to turn all motion off, and that is the right kind of complaint. Slide tools used in real rooms need accessibility and calm-mode controls, not just impressive transitions.

Try Bento when the deck is a document

Bento is a good fit when the deck itself is the thing you want to preserve. Think architecture notes, a demo script, an investor update, a workshop handout, or a design walkthrough that should still open in five years.

It is less compelling when the deck is really a product surface. If you need auth, analytics, complex embeds, private data access, or strict supply-chain review, a single bundled file may be more cute than useful.

A practical test is simple: could you commit the file under docs/ and feel okay if someone opened it on a plane? If yes, Bento is worth a try. If no, keep the deck closer to your normal app stack.

Put a hook boundary around agent edits

In a Claude Code workflow, the safe experiment is narrow: let the agent edit Bento’s slide data, not the embedded application. That keeps the workflow pleasant without asking a coding agent to rewrite a portable app container by accident.

The official claude code hooks documentation is the place to check exact event behavior before you wire this into a real repo. In practice, the relevant idea is a PreToolUse boundary for file-editing tools: if the target is a Bento HTML file and the proposed edit appears to touch the app blob, stop the edit and tell the agent to work in the JSON block instead.

This is a convention, not a security system. It pairs well with a short repo note, a small review habit, and whatever MCP permissions you already use for private systems. For broader patterns, keep a lightweight page of Claude Code team conventions instead of hiding these rules in chat history.

One useful pattern is to review the file diff like a receipt. If the JSON changed and the app blob did not, the change is probably what you asked for. If a huge base64 region changed, pause and inspect before merging.

That same “make the boundary visible” habit shows up in Claude Code release work around explicit reviews; see Claude Code 2.1.215 Makes Reviews Explicit for the related review angle.

Copy this hook boundary before agent edits

Use this as a starting point, not as a universal rule. The marker patterns are intentionally conservative. Inspect a real Bento file first, then tune the grep pattern to the actual boundary between slide JSON and bundled app code.

# .claude/hooks/bento-slide-data-only.sh
#!/usr/bin/env bash
set -euo pipefail

payload="$(cat)"
file="$(jq -r '.tool_input.file_path // empty' <<<"$payload")"

# Only guard checked-in Bento decks.
[[ "$file" == *.bento.html ]] || exit 0

proposed_text="$(jq -r '
  [
    .tool_input.new_string?,
    .tool_input.content?,
    (.tool_input.edits[]?.new_string?)
  ] | map(select(. != null)) | join("\n")
' <<<"$payload")"

# Block edits that look like they rewrite the embedded app payload.
if grep -Eiq 'base64,|atob\(|BENTO_APP_BLOB|application/octet-stream' <<<"$proposed_text"; then
  echo "Bento deck edits should change slide JSON only. Do not rewrite the embedded app blob." >&2
  exit 2
fi

exit 0

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|MultiEdit|Write",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/bento-slide-data-only.sh"
          }
        ]
      }
    ]
  }
}

Before using it, install jq, make the script executable, and test it on a throwaway deck. Ask Claude Code to change one slide title, then ask it to “minify the whole HTML file” and confirm the second edit is blocked.

The trap is making the hook too clever. A hook should enforce a boring boundary. Put the nuanced instruction in your prompt or repo memory; put the hard stop in the hook.

Try one safe deck

Pick a small internal deck, make a copy as a Bento HTML file, and ask Claude Code to edit only the slide JSON. If the diff stays readable and the browser editing feels good, you have found a useful little file format trick.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Claude Code artifact first: a hook boundary, an MCP permission note, a slash-command workflow, a Claude skill outline, a review checklist, or a concise CLAUDE.md note when repository memory is the topic.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• What should teams know about claude code hooks?

  Start by writing down one visible team rule for Claude Code, not a loose preference. That is the practical core of claude code hooks documentation. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Claude Code artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a hook checklist, MCP permission rule, slash-command workflow, skill outline, or concise CLAUDE.md note. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Claude Code teams deciding which hook, skill, MCP boundary, slash-command workflow, review habit, or repository-memory convention to standardize next around “Bento Puts Slides in One HTML File.”
• Best first artifact: turn the named fix into a hook checklist, skill note, MCP permission note, review receipt, or concise CLAUDE.md convention when repository memory is the real topic before the next automated run.
• Best comparison angle: compare the workflow against the current Claude Code handoff, hook behavior, and MCP scope; keep the path that leaves the shortest auditable trail.

Further reading

• Bento — source
• Claude Code — hooks
• Anthropic — Claude Code product page
• Claude Code docs: en getting started

What to do next

Take this into the related training topic and test whether a new reviewer can defend the merge without replaying the chat.