open-slide: a React slide runtime where the coding agent writes the pages
A slide framework built for agents.
At a glance
- What is it?
- open-slide is an MIT-licensed TypeScript framework that fixes every slide to a 1920x1080 canvas and lets arbitrary React components fill it, with agent skills, an in-browser comment loop, and static HTML/PDF export. It is at 2.0.0-beta.1, so treat the beta line as the thing you would actually be evaluating.
- Who is it for?
- Adopt open-slide if your deck is genuinely a React artifact and you already work inside a coding agent; skip it if you need a hand-editable GUI, a non-React team, or a stable release line, because the current published versions are 2.0.0-beta.0 and 2.0.0-beta.1 for both @open-slide/core and @open-slide/cli.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem open-slide picks: agents write code, slide tools want clicks
Most slide tooling assumes a human dragging boxes on a canvas or filling a template. A coding agent cannot operate that surface well. It can write files. open-slide takes the position that a deck should be source code the agent can author, and that the framework should supply everything around the content: canvas, scaling, navigation, hot reload and present mode. The README frames this as slides being "visual code" and open-slide being "the missing runtime" between a prompt like "make slides about X" and a presentable deck. The audience is narrow and specific: people who already run Claude Code, Codex or Cursor in a terminal next to their repository and would rather describe a deck than place text boxes. If your workflow does not include an agent, the pitch mostly evaporates, because what remains is a React app with a fixed canvas and a viewer.
One canvas size, arbitrary React: the core design decision
Every slide renders into a fixed 1920x1080 canvas, and pages are arbitrary React components rather than a constrained DSL. That single choice explains most of the rest of the project. A fixed canvas means layout maths stays predictable: the agent writes against one coordinate space, and the framework handles scaling to whatever viewport the deck is shown in. Arbitrary components mean nothing is off limits, including third-party React libraries, but also that nothing is validated. There is no schema stopping an agent from producing a page that overflows or overlaps. The README points to a /slide-authoring skill described as the technical reference for the canvas, type scale, palette and layout rules, which the agent reads before writing. That is the mitigation: constraints live in a document the agent is told to consult, not in a compiler that rejects bad output. Whether that is enough depends entirely on how obedient your agent is on a given day, and that is a real risk to weigh rather than a footnote.
The comment loop is the most interesting mechanism here
open-slide ships a dev-server inspector. You click an element and attach a comment such as "make this red" or "shrink the headline". Those comments are persisted as @slide-comment markers in the source files. Running /apply-comments makes the agent apply every pending edit and then clear the markers. This is a cleaner feedback channel than pasting screenshots into a chat window, because the comment is anchored to a source location rather than to a description of a location. It also means the review state lives in the repository and shows up in diffs, which is either useful or noisy depending on how your team reads pull requests. The README describes the loop as present, click to comment, /apply-comments, repeat. Nothing in the material indicates how markers behave when two people comment on the same element, or what happens if the agent edits the element and the marker no longer matches. Verify that on your own deck before you build a workflow around it.
Getting a workspace running
The scaffolder is the entry point: npx @open-slide/cli init my-slide, then cd my-slide and pnpm dev. The generated workspace is deliberately thin. According to the repository layout, Vite, React and tsconfig stay hidden inside @open-slide/core, so the scaffold exposes slides rather than build configuration. You then either drive the deck through your agent or edit slides/<id>/index.tsx directly. The README states the scaffolded workspace ships with agent skills preconfigured for Claude Code, and points to CLAUDE.md for what it calls the hard rules. Note the package manager: the quick start uses pnpm, and the monorepo itself is pnpm plus Turbo, with pnpm install, pnpm dev, pnpm build, pnpm check and pnpm lint documented for contributors. If your team standardises on npm or yarn, confirm the generated workspace works there before you plan around it. The framework itself is consumed as @open-slide/core, and the demo app under apps/demo consumes it through workspace:*, which is how the maintainer develops against local changes.
Export, present mode, and what static output actually buys you
Present mode is fullscreen playback with keyboard navigation, plus a presenter view with current and next slide preview, speaker notes and a timer. Export produces either a self-contained static HTML site or a print-ready PDF, and the README lists Vercel, Cloudflare Pages, Zeabur, Netlify and any static host as deployment targets. The claim worth taking seriously is that the build is plain static with no server and no runtime. That is the strongest practical argument for open-slide over a hosted slide service: the artifact is files you can archive, diff and serve from object storage. It also means interactive behaviour in a slide is limited to what runs client-side. If a deck needs live data, authentication or server-side rendering at view time, the static export is the wrong output and you would be maintaining a separate hosted path. The README does not describe such a path, so assume you would be building it yourself.
Where open-slide is the wrong tool
Three cases stand out. First, collaborative editing. open-slide has no described multi-user editing surface; the editing surface is an agent plus source files, and the only built-in collaboration primitive is a comment marker in a file. A marketing team that expects two people in the same deck at the same time will be fighting the design. Second, non-React shops. Pages are React components, the runtime is a Vite plugin, and the CLI is TypeScript. There is no documented path for authoring slides in another language or templating system, so a Python or Go team would be adopting a React toolchain to make slides. Third, anyone who needs a stable release. The most recent releases listed are @open-slide/core@2.0.0-beta.0 and 2.0.0-beta.1, plus @open-slide/cli@2.0.0-beta.1, all dated 2026-09-02. The README's own quick start uses npx @open-slide/cli init without pinning a version, which on a beta line means the resolved version can move under you. Pin exact versions in package.json if you build anything you intend to keep.
Alternatives, and the actual difference in approach
The obvious comparison is Slidev, which also treats slides as code and also targets developers. The difference is the authoring model. Slidev centres on Markdown files with a Vue component escape hatch and a theme and addon ecosystem; the primary artifact is text a human writes. open-slide inverts that: the primary artifact is a React component tree that an agent writes, with Markdown-style brevity nowhere in the described workflow, and the framework's job is to keep the agent inside a fixed canvas with a documented type scale. If you want to hand-edit a deck in a text editor and keep it readable in a diff, Slidev's Markdown-first model is the better fit. If you want the deck to be a React application with full control over every pixel and you are comfortable reviewing generated TSX, open-slide is aimed at exactly that. A second comparison is the hosted presentation tools with an AI generation feature. Those produce a deck inside someone else's editor, which is convenient until you want to version it; open-slide's static export and source-file model are the counter-argument, at the cost of requiring a local toolchain.
Licence, maintenance, and what to check first
The project is MIT licensed, copyright Yiwei Ho, which permits commercial use, modification and redistribution provided the licence and copyright notice are retained. That is a permissive baseline and imposes no copyleft obligation on your decks or your fork. This is a description of the licence text, not legal advice; have counsel review it if the deck ships inside a product. Maintenance signals in the material are mixed. The repository is not archived, the last push is 2026-09-10, and releases landed on 2026-09-02, so the project is active. But the published line is beta, the monorepo is small (core, cli, one demo app), and the README carries a Ko-fi link and a Vercel OSS Program badge, which suggests a maintainer-funded project rather than a company-backed one. Plan for upgrade cost accordingly: pin @open-slide/core and @open-slide/cli to exact versions, keep your slides in slides/<id>/index.tsx as the README prescribes, and treat CLAUDE.md as the contract your agent follows. When you move to 2.0.0 stable, the diff in that file is what tells you whether the upgrade is safe.
Editorial conclusion
Adopt open-slide if your deck is genuinely a React artifact and you already work inside a coding agent; skip it if you need a hand-editable GUI, a non-React team, or a stable release line, because the current published versions are 2.0.0-beta.0 and 2.0.0-beta.1 for both @open-slide/core and @open-slide/cli. Before committing, run npx @open-slide/cli init on a scratch directory, open the dev server, click one element and leave a comment, then run /apply-comments and inspect the resulting diff in slides/<id>/index.tsx: that diff is the whole product, and if it is messy the framework is not for you.
Community notes