open-slide: a slide framework built for coding agents

What open-slide solves, and who it is actually for

Most slide tools assume a human dragging boxes. open-slide assumes the opposite: the README describes it as "the slide framework built for agents", where you describe a deck in natural language and your coding agent writes the React. The runtime owns the parts an agent is bad at guessing: a fixed 1920 x 1080 canvas, scaling, navigation, hot reload, and present mode. The agent owns content.

That split is the whole pitch. Pages are arbitrary React components rather than a constrained DSL, so anything you can render in React can be a slide. The target user is someone who already has Claude Code, Codex or Cursor open and would rather type a prompt than open Keynote. If your deck pipeline is a git repository and your reviewers read diffs, this fits. If your deck pipeline is a marketing team sharing a .pptx, it does not.

The mechanism: a canvas, a scaffolder, and comment markers in source

The repository is a pnpm plus Turbo monorepo with three entries. packages/core holds @open-slide/core, which the README describes as the runtime (home page, slide viewer, present mode, inspector), a Vite plugin, and the open-slide dev, build and preview CLI. packages/cli holds @open-slide/cli, the npx scaffolder that generates a minimal workspace where Vite, React and tsconfig stay hidden inside core. apps/demo is an example workspace consuming core via workspace:*, used for local framework development.

The feedback loop is the interesting part. The dev server ships an in-browser inspector: you click an element and attach a comment such as "make this red" or "shrink the headline". Those comments persist as @slide-comment markers in the source. Running /apply-comments makes the agent apply every pending edit and clear the markers. The loop the README states is present, click to comment, /apply-comments, repeat.

Two skills ship with the scaffolder. /create-slide drafts a deck end to end, asking four scoping questions (topic and aesthetic, page count, text density, motion versus static), picking an id, planning structure, then writing pages. /slide-authoring is the technical reference for the canvas, type scale, palette and layout rules, read by the agent before it writes. Both are conventions the agent has to honour, not enforced by a compiler.

Installing open-slide and authoring your first deck

The README gives a single scaffold command. It generates a workspace with agent skills preconfigured for Claude Code, so run it from the directory where you want the project to live.

npx @open-slide/cli init my-slide
cd my-slide
pnpm dev

After pnpm dev, the dev server serves the deck with hot reload. From there you either drive the deck through your agent or edit slides/<id>/index.tsx directly. The README points at CLAUDE.md for the hard rules the agent must follow; that file is at the repository root, alongside AGENTS.md and a .claude/ directory.

If you are working on the framework itself rather than a deck, the root package.json defines the monorepo scripts. The README lists install, dev, build, check and lint, and the package scripts also expose typecheck, test and test:e2e.

pnpm install
pnpm dev      # runs the demo against the local @open-slide/core
pnpm build    # builds all packages
pnpm check    # type-checks all packages
pnpm lint     # lints via biome

Export is described as one command producing either a self-contained static HTML site or a print-ready PDF. The README does not spell out the exact export flags, so check the CLI help before scripting it.

Where open-slide gets in the way

The comment-marker loop is a real design bet, and it has a failure mode the README does not address. Markers live in source as @slide-comment. If an agent edits a component and drops or renames the element a marker was attached to, the README does not document what happens to that pending comment. There is no stated rollback for /apply-comments either. Treat unresolved markers as something you review in the diff, not something the tool guarantees.

The 2.0.0 line is also published as beta. The recent releases show @open-slide/[email protected] and beta.1, plus @open-slide/[email protected], all dated 2026-09-02. The last push to the repository was on 2026-09-10, which is recent, but a beta version number is a beta version number: pin what you install and read the changesets before upgrading.

Finally, the framework is React and TypeScript only. Pages are React components, so a Python or Go team gets nothing here. The related searches for "Open slide python" and "OpenSlide" point at a different project entirely, an unrelated library for reading whole-slide microscopy images. Nothing in this repository has anything to do with that.

open-slide against Reveal.js and Slidev

Reveal.js and Slidev both target a human writing Markdown or HTML by hand. Slidev in particular is a Vue and Vite tool where you author slides in Markdown files and the framework compiles them. The unit of authoring is a Markdown document.

open-slide moves the unit of authoring to a React component and assumes an agent writes it. That difference shows up in the tooling around it: the scaffolder ships skills rather than a theme gallery, the inspector writes comments back into source instead of offering a visual editor, and the canvas is fixed at 1920 x 1080 with a documented type scale the agent is told to read. If you want to type Markdown yourself, Slidev is the shorter path. If you want an agent to produce the deck and you want to review it as React, open-slide is the one built for that.

Maintenance, licence, and what an upgrade costs

open-slide is MIT licensed, copyright Yiwei Ho. MIT is permissive: you can use it commercially, modify it, and redistribute it, provided the copyright notice and licence text are kept. That is a description of the licence terms, not legal advice; check them against your own policy.

The repository is not archived and the last push was on 2026-09-10, so the project is moving. The release cadence visible in the releases is concentrated: three packages published within about an hour on 2026-09-02. Upgrades run through Changesets, with the root scripts changeset, version-packages and release, and a .changeset/ directory in the tree. For consumers that means version bumps arrive with changelog entries rather than silent patches, which is the good case.

The cost sits in the beta. Because 2.0.0 is pre-release, expect breaking changes between beta versions, and pin exact versions in your deck workspace rather than floating on a range. The monorepo also keeps Vite, React and tsconfig hidden inside core, which keeps deck workspaces small but means a Vite or React upgrade is the maintainer's call, not yours.

Editorial conclusion

Adopt open-slide if your team already works inside a coding agent and treats a deck as a React codebase: the scaffolder, the /create-slide and /slide-authoring skills, and the static HTML and PDF export all fit that workflow. Skip it if you need a WYSIWYG editor, a non-React stack, or a stable API today, because the 2.0.0 line is still published as beta. Before committing, run npx @open-slide/cli init my-slide, open the dev server, and confirm the scaffolder writes the agent skills your tool actually reads; the README points to CLAUDE.md for the hard rules but does not document what happens when a comment marker is left unresolved.

Frequently asked questions

Official sources

1. 1weiho/open-slide on GitHub
2. License: MIT
3. Project website
4. README
5. Releases