Each slide is a React component, and the deck is a web app

The argument is against static slides, and against generated slides

The stated motivation comes in two parts and they are different complaints. The first is about AI output: generated decks tend to be slop, with generic layouts, walls of bullets, and nothing you would be proud to put in front of an audience. The second is about the medium itself: why are slides still static, given that agents can build anything. The answer the project gives is to hand the format to tools that already know how to build for the web, and let the result be a working page per slide rather than a picture of one. That is why the deck is a real web app, responsive on any screen, and shareable as a link rather than exported as a file. The second part of the answer is the authoring path, because the same claim is made about four different agents: Claude Code, Codex, Cursor and Bolt. Each of them is expected to compose the deck from the same component library, and the repository ships a skill file that teaches an agent how to theme, compose and write the deck, down to setting the tab title and the favicon.

A slide is a component, so it can fetch and render

The authoring model is one sentence: each top-level child of the Deck component is one slide. Compose them from the component library or write plain JSX, and the framework does the rest. The example makes the argument better than prose would, since the Cover takes a kicker, a title, a subtitle and a notes string, and the Slide takes a centre flag and a navigation label. Because a slide is an ordinary React component rather than a rendered artefact, a slide can fetch live data, mount a 3D scene, or embed the actual product being pitched. There is no plugin boundary and no template syntax to learn: the constraint is React, and the reward is that anything you can build for the web you can present. The project states that position without qualification, and the design of the rest of the repository follows from it. The chrome, the themes and the presenter tools exist to make a set of web pages behave like a deck.

The chrome is a paged deck, credited to Slidev

The framing is a classic paged deck and the project says which one it is borrowing from: a Slidev-style dock, a thumbnail sidebar, a grid overview, click-builds, annotations and a synced presenter mode. That is a deliberate choice, because the interesting alternative was a scrolling document, and the choice shows in the key map. Arrow keys and space move forward, but they reveal builds before they advance slides, so the keyboard model has two levels rather than one. Home and End jump to the first and last slide, S toggles the thumbnail rail, G opens a grid of every slide at once, A starts annotating with a pen, highlighter, shapes and an eraser, F goes fullscreen, P opens presenter mode in a second tab, H hides the interface entirely, and Escape closes whatever overlay is open. Deep links fall out of the same design, since the URL hash tracks the slide and a link can point straight at `/#7`.

Click-builds step backwards as well as forwards

Builds are the mechanism that replaces bullet-by-bullet reveals, and the syntax is small. Wrapping content in a Build element with a step number reveals it on the nth click, so a slide can stage its own content instead of relying on a list appearing all at once. The detail that matters is in the arrow keys: stepping forward reveals builds before advancing to the next slide, and stepping back rewinds the builds before returning to the previous slide. In a conventional deck, going backwards is usually all-or-nothing, which forces the presenter to plan around it. Here the build sequence is a timeline in both directions, so a rehearsal that overshoots a step is recoverable with the same key. The content inside a build is ordinary markup, so a build can wrap a paragraph, a chart or an entire interactive component.

Annotations are anchored to content, not to pixels

The annotation layer is the part of this repository worth reading even if you never present a deck with it. Annotations are described as content-anchored: a circle drawn around a statistic on a laptop rings the same statistic on a phone, wherever the layout moved it. That is a different design from the usual approach of storing strokes in screen coordinates, and it is the only way an annotation survives a deck that is deliberately responsive. A circle stored as a rectangle on a 1440 pixel screen is meaningless on a phone, so the mark has to be attached to the element it encircles and re-projected when the layout reflows. Drawings persist per slide, so they belong to the slide rather than to the session. The component doing the work lives in the deck engine directory alongside Deck, Slide, Build and Reveal, and it is grouped under the same chrome code as the presenter tools, which is where you would look if you wanted to see how the anchoring is resolved.

Presenter mode is a second tab talking over BroadcastChannel

Presenter mode opens a new tab with a timer, a preview of the next slide and editable notes, and the two tabs stay in sync through a BroadcastChannel. That is a browser API for same-origin messaging, so no server is involved, which matters for a deck that is a static web app being shared as a link. The design implies two different views of the same deck on two devices, the audience tab and the presenter's tab, and the channel carries the slide position between them. Notes are handled separately: a notes string on any slide appears in presenter mode, and edits made while presenting are persisted locally rather than being written back into the source. So a presenter can adjust their own notes during a talk without dirtying the repository, and the deck ships as the same artefact to everyone else. It is a small decision, and it is the difference between a presenter tool and a second window.

Twenty-nine components and a twenty-six slide demo

The component library is grouped by what a slide is doing, not by visual style. Structure has six: Cover, Agenda, Section, Split, Bento and Slide. Data has seven: Charts with bar, line and donut variants, Table, StatGrid, BigNumber, CountUp and VisualDashboard. Story has six: Quote, Contrast, Comparison, Timeline, Steps and Chat. Product has four: CodeWindow, BrowserFrame, Pricing and Team. Flair has six: Globe, TiltCard, SpotlightCard, Marquee, Accordion and Tabs. Every one of them is demonstrated in the bundled starter deck, and every one is responsive, which is the property that makes the content-anchored annotation system work. The starter deck is twenty-six slides and the dev server opens it directly:

git clone https://github.com/stackblitz/bolt-slides
cd bolt-slides
npm install
npm run dev

The fastest way to evaluate the project is to run it and delete. Which is exactly what the instructions say to do next: remove the demo slides from the app file and author your own.

One CSS file holds the theme, and nine directions live in the skill

Theming is a single file. Every colour, font, radius and shadow lives in the `:root` block of `src/styles/tokens.css`, and changing the primary token recolours the entire deck including the chrome, which is the test of whether a theme is real or decorative. Alongside it sits a base styles file for system styles. Nine ready-made theme directions are documented, but they are documented in the skill file rather than in the README, ranging from an editorial look to a dark technical one, which means the themes are instructions to an agent as much as presets for a human. The manifest is correspondingly small: three runtime dependencies, React, React DOM and the animation library, and no deck framework at all, since the engine in the deck directory is the framework. There is a build, a dev and a preview script and nothing else, no test and no lint, and the contributing guide asks for a typecheck and a build before pushing. The manifest also carries no version field.

Editorial conclusion

Judgment: Bolt Slides is best understood as a starting point rather than a product, and the giveaway is that the repository ships its own demo deck as the only content. Delete the slides in `src/App.tsx` and you are writing the deck yourself with twenty-nine components and one CSS file of tokens, which is a pleasant deal if you already build for the web and a poor one if you want a template-driven editor. The genuinely novel piece is the annotation anchoring, where a mark drawn on a laptop follows the same element to a phone, and that is worth stealing as an idea regardless of whether you use this repository. Two things to know before committing. There is no version field in the manifest, no releases, and no test or lint script, so the pre-push check the contributing guide asks for is a typecheck and a build. And the last push was 30 July 2026, so treat the component list as a snapshot rather than a maintained API.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. stackblitz/bolt-slides on GitHub