open-slide turns every slide into a React component that your coding agent writes

A deck is a folder of React components on a 1920 x 1080 canvas

The central decision in open-slide is that a slide is code. Every page is a React component, and every component renders onto a fixed 1920 x 1080 canvas. The framework takes care of the parts that are tedious to rebuild for each deck: scaling that canvas to the browser window, navigation between pages, hot reload while files change, the editing layer and the present mode.

This matters because it decides who can maintain a deck. A slide built this way is a TypeScript file, not a binary document. It can be diffed, reviewed in a pull request and regenerated by an agent, but someone who only knows PowerPoint or Keynote cannot open it and nudge a text box without the dev server running. The fixed canvas also means the layout is designed once for a 16:9 frame; the framework scales that frame to the screen rather than reflowing content, so a deck written for a projector will look like a letterboxed projector slide on a phone.

The project is MIT licensed, written in TypeScript, and maintained at 1weiho/open-slide with documentation on open-slide.dev.

Scaffolding a deck with npx @open-slide/cli init

A new deck starts from the init scaffolder in the @open-slide/cli package:

npx @open-slide/cli init my-deck
cd my-deck
npm run dev

The first command creates a project from the template that ships in packages/cli. The second and third move into that folder and start the development server, which is where the canvas, hot reload, the editor and the agent panel all live. There is no hosted editor in this flow: the deck exists on your disk as a project, and you need Node.js with npm available to run it.

The runtime itself lives in a separate package, @open-slide/core, which bundles the runtime, a Vite plugin and the open-slide CLI. That split is visible in the release history: the recent tags are @open-slide/[email protected] on 12 October 2026, then @open-slide/[email protected] and @open-slide/[email protected] on 23 October 2026. If a deck breaks after an upgrade, the core package version is the first thing to compare, since the scaffolder only produces the starting template.

The agent panel borrows your existing Claude Code or Codex login

Pressing A on any slide opens the agent panel, which connects to the Claude Code or Codex CLI you already use and lets you drive it from the browser. From the home page, New deck asks for a description, and the agent writes the deck page by page while the canvas follows along. When you send a message from inside a deck, the current slide, page and selected element travel with it, so a request like make this bigger has a target without you naming a file or a component.

There are no API keys to configure. The SDK installs into the workspace the first time the panel opens, and it runs on the login you already have. The consequence cuts both ways. Setup is short if you are signed in to one of those two CLIs, but the in-browser panel is tied to Claude Code and Codex specifically. If your team uses a different agent, or your machine has neither CLI authenticated, the panel has nothing to talk to, and you fall back to the terminal workflow described below. The first panel open also writes an SDK into your project, which is worth knowing before you commit the workspace to a shared repository.

Bundled skills for agents that never touch the browser

For people who prefer the terminal, open-slide ships three skills: /create-slide, /apply-comments and /create-theme. They are meant to work with any coding agent, and Claude Code, Codex and Cursor are named as examples. This is the route for agents the browser panel does not connect to.

The trade is context. In the browser panel, the selected element and current page are attached to every message automatically. In the terminal you are back to telling the agent which file and which part of the slide you mean, the same way you would for any other React code. The skills cover the three jobs that make up most deck work: drafting pages, applying review notes and building a theme. Anything outside those still goes through ordinary prompting against the source files.

Comments are stored as @slide-comment markers in the source

Comment mode is the review loop. Press C, then click an element or drag across a region, and type a note. The note does not go to a separate database or sidebar; it is saved as an @slide-comment marker inside the slide source. The agent can then apply every pending comment in one pass, and the comment bar offers a one-click apply.

Keeping comments in the source has clear upsides. Reviewers can annotate visually without editing JSX, comments travel with the deck through Git, and the agent reads them from the same files it edits. The downside is that unapplied comments are part of your code. If you commit a deck mid-review, the markers go with it, and anyone reading a diff will see review notes mixed into component changes. Teams that keep decks in a shared repository should decide whether comments get applied before merging or are allowed to sit in the main branch.

Editing by hand: visual editor, themes and the assets manager

Not every change needs an agent. The visual editor supports dragging, resizing, alignment guides and inline text editing directly on the canvas. Beyond single elements, the framework includes themes, page transitions, step-by-step reveals and shared-element morphs between slides, which covers the animation vocabulary most talks use.

The assets manager searches brand logos through svgl and pulls fonts from Google Fonts. That is convenient for product and conference decks, where a slide often needs a company logo and a specific typeface, but it also means those two lookups depend on external services. The visual editor works on top of React components rather than a free-form document, so a hand edit still ends up as a change to the deck source that the agent will see on its next pass.

Present mode and a static build instead of a slide file

Presenting happens in the browser. Present mode gives fullscreen playback with keyboard navigation, and a presenter view shows the next slide, speaker notes and a timer. Because the deck is a web project, the natural way to share it is the static build, which deploys to Vercel, Cloudflare Pages, Netlify or any static host.

For audiences who need a file, open-slide exports to static HTML, PDF and PPTX. The PPTX export is what answers the question of opening an open-slide deck in PowerPoint, but it is an export, not a round trip. The deck's source of truth stays in the React files, and changes made to the exported PPTX in PowerPoint do not flow back into the project. If a colleague edits the exported file, someone has to carry those edits back into the source by hand or by prompting the agent. Teams that live in PowerPoint and only want an agent to generate a starting point should test that export on a real deck before committing to the framework.

Working on the framework itself means a pnpm monorepo

The repository is a monorepo with four parts. packages/core holds @open-slide/core, with the runtime, Vite plugin and open-slide CLI. packages/cli holds @open-slide/cli, the init scaffolder and project template. apps/demo is a local workspace for developing the framework, and apps/web is the website and docs.

Contributors use pnpm rather than npm:

pnpm install
pnpm dev         # run the demo against local core
pnpm build       # build all packages
pnpm typecheck
pnpm check       # biome
pnpm test

pnpm dev runs the demo against the local core package, which is the quickest way to reproduce a bug before filing it. Linting goes through Biome via pnpm check. The project asks contributors to read CONTRIBUTING.md before opening a pull request. The last push to the repository was on 29 October 2026, a few days after the 2.3.1 release, and the project is not archived. The name also collides with OpenSlide, a separate library for reading whole-slide images; this project has no relation to it, and searches for open slide python or supported file formats are about that other tool.

Editorial conclusion

open-slide suits developers who already run Claude Code, Codex or Cursor and are comfortable treating a presentation as a React project in a Git repository; the agent panel, comment markers and static build all assume that workflow. It does not suit people who want to open and edit decks in PowerPoint, people outside the Node.js toolchain, or anyone looking for the unrelated OpenSlide library for whole-slide microscopy images. Before adopting it, check that your agent CLI is logged in on the machine that runs the dev server, and export a sample deck to PPTX to see whether the result is good enough for colleagues who will never touch the source.

Frequently asked questions

Official sources

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