# slides-grab: an agent-first slide workflow where you point at the region you want changed > slides-grab treats slides as self contained HTML and CSS files, gives an agent a plan, design and edit workflow, and adds a browser editor with bounding box selection so a change request can target one element instead of a whole deck. The exports to PPTX and Figma are labelled experimental, and a design gate blocks export until a receipt is recorded. **NomaDamas/slides-grab** — Best harness + editor + linter for generating slides in Claude Code / Codex - Claude Design Open Source Alternative - Repository: https://github.com/NomaDamas/slides-grab - Website: https://nomadamas.github.io/slides-grab/ - Stars: 1,236 · Forks: 129 - Language: HTML - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/nomadamas-slides-grab ## Pointing at a region instead of describing a change The project states the problem it exists to solve in one paragraph. There are many AI tools that generate slide HTML, and almost none let you visually point at what you want changed and iterate in place. slides-grab fills that gap. The interaction is the whole idea. How? Just drag an area in the slides and ask the agent to edit it. And simple things like text, size, or bold can still be edited manually, just like in the 2024 era. That last clause matters, because it is the difference between a tool that requires you to go back to a text editor for a typo and one that does not. The stated rationale is that the whole slides are HTML and CSS, the language that, as the README puts it, is not a programming language but is the one AI agents outperform with. So the slides are beautiful, easily editable by AI agents, and can be converted to PDF or to experimental or unstable PPTX formats. That claim about HTML and CSS being the format agents handle best is the design decision underneath everything else, and it has consequences. A deck is a directory of slide files rather than a single binary, so an agent can rewrite one slide without touching the rest. The downside is that you have left behind the binary format that every presentation tool on earth reads, and the project is honest about that, since the PPTX and Figma routes are both labelled experimental or unstable. The agent workflow itself is four steps: Plan, where the agent creates a structured slide outline from your topic or files; Design, where the agent generates each slide as a self contained HTML file; Edit, with a browser based editor offering bounding box selection, direct text editing and agent powered rewrites; and Export, one command to PDF plus experimental PPTX or Figma export flows. ## A design gate stands between your slides and any export The most distinctive thing about this project is a mechanism that has no equivalent in a normal slide tool, and it is worth understanding before anything else. The packaged workflow relies on bundled SKILL.md files, bundled references/, and the slides-grab CLI. Exports through slides-grab pdf, slides-grab convert and slides-grab figma are blocked until slides-grab design-gate records a fresh proceed receipt for the current slide files. So there is a gate, and the gate produces a receipt, and the receipt has a freshness condition tied to the current slide files. The design gate is also listed among the commands that require an existing slides workspace containing slide-*.html. What this amounts to is a rule that you cannot export a deck that has not been through a design review step, and that the review is invalidated when the slides change underneath it. The purpose is to stop an agent from shipping a deck that nobody has looked at, and the receipt is the mechanism that makes the look happen. It is a workflow constraint rather than a technical one, and it is enforced in code, which is why it does not get forgotten. The trade is real. If your workflow is generate and ship, the gate is friction, and it is the kind of friction that gets removed by reaching for the underlying files directly. If your workflow is generate, review, fix, then export, the gate is the part that stops the second half of the loop from collapsing. ## The CLI surface, and which commands need what The command list is long but it divides cleanly, and the division is documented rather than implied. Workflow commands support --slides-dir with a default of slides. On a fresh clone, the discovery commands, which are --help, list-templates, list-styles and preview-styles, work without a deck. Then edit, edit-image, build-viewer, validate, png and design-gate require an existing slides workspace containing slide-*.html, and convert, pdf and figma additionally require a fresh Proceed design gate. The export commands have the most options, and the options are the interesting part. ```bash slides-grab convert --resolution 2160p # Higher-resolution raster PPTX export slides-grab convert --engine text # Export editable text with best-effort DOM extraction slides-grab figma # Export an experimental / unstable Figma Slides importable PPTX slides-grab pdf # Export PDF in capture mode (default) slides-grab pdf --resolution 2160p # Higher-resolution image-backed PDF export slides-grab pdf --mode print # Export searchable/selectable text PDF slides-grab png # Render one PNG per slide (default 2160p) slides-grab png --slide-mode card-news # Render square 1:1 PNGs for Instagram ``` Note what the modes imply. PDF capture mode is an image, PDF print mode is searchable and selectable text, PPTX with the text engine is editable text with best-effort DOM extraction, and PPTX at higher resolution is raster. Those are four different outputs with four different fidelity and editability tradeoffs, and the fact that they are separate flags rather than one setting with a quality knob is a sign the tool is being honest about the underlying problem. There are also utilities that have nothing to do with slides. slides-grab image generates a local slide image with codex-imagen by default and uses your local Codex ChatGPT login, so no API key is required. slides-grab fetch-video downloads a local video asset with yt-dlp. slides-grab tldraw renders a .tldr diagram into a slide sized local SVG asset. And slides-grab list-styles shows 92 selectable design styles by default, 95 resolvable including 3 source aliases, with --all showing all of them. ## Ninety five design styles, deduplicated into ninety two The style collection is a small data engineering problem, and the project documents it unusually precisely. slides-grab bundles 95 design styles. Thirty are derived from corazzon/pptx-design-styles, five are slides-grab originals, and 60 are PPT packs derived from epoko77-ai/design-diversity. Then the classification. The 60 design-diversity PPT packs are classified, direct duplicates are aliased to builtins and hidden by default, near duplicates are linked via relatedStyleIds, and net new packs are added. The result is that 92 are selectable by default while all 95 remain resolvable, and list-styles --all shows the aliases. The reason to care about this is not the number of styles, it is the fact that the aliasing is a deliberate mechanism rather than an accident. An agent picking a style by name needs the name to resolve to something, and a catalogue with near duplicates in it is a catalogue where the agent's choices become unpredictable. Aliasing the duplicates and linking the near ones with relatedStyleIds gives the agent a stable menu and a way to find the variations it has not seen. Agents can also create fully custom designs beyond the bundled collection, and the design gate exists precisely so that a custom design is reviewed before it is exported. The bundled catalogue is a starting menu, not the limit of what the tool can produce. ## Installing into an agent, with and without a clone There are three install paths, and which one you pick depends on whether you are using the tool or developing on it. For a coding agent, the README gives per agent instructions. You paste a single line into Claude Code, or into Codex, and that line asks the agent to read a raw installation document from the repository and follow every step. The two documents live at docs/installation/claude.md and docs/installation/codex.md. For development, you clone the repository itself. ```bash git clone https://github.com/NomaDamas/slides-grab.git && cd slides-grab npm ci && npx playwright install chromium ``` For a no clone install, the package is on npm. ```bash npm install slides-grab npx playwright install chromium npx slides-grab install-skills --target all --scope user ``` That last command installs the same shared Agent Skills plus lightweight runtime adapters into the Codex and Claude Code locations, and it is worth noting what it means for the tool to install itself into two other tools' configuration directories. The skills are shared, the adapters are per target, and the scope flag chooses user level rather than something machine wide. Node.js 20 or newer is required, and the Playwright Chromium download appears in every path because the visual validation and export paths are browser driven. That is the recurring dependency in this project and it is not optional. There is also a ChatGPT plugin build. ```bash npm run build:plugin ``` The archive is written to dist/ and contains the plugin manifest plus every published skill, and hosted ChatGPT can use the planning and design workflows directly. But export, visual validation, the local editor and image generation still require the local Node.js and Playwright runtime with filesystem access, and CHATGPT.md holds the exact support policy. That split is the honest way to describe it: the hosted plugin plans and designs, and the local runtime does the rest. ## The hosted plugin plans and designs, and the local runtime does everything else The division between hosted and local is the single most important operational fact about this project, and the README is careful about it. Hosted ChatGPT can use the planning and design workflows directly. Export, visual validation, the local editor, and image generation still require the local Node.js and Playwright runtime and filesystem access. That is a meaningful constraint for a team. If your workflow is: paste a topic into a chat window, get a deck back, and email it, the hosted path covers the first part and leaves the rest to you. If your workflow is: generate locally with Claude Code or Codex, review in the browser editor, and export, then everything runs on your machine and the hosted plugin is not part of the loop at all. The repository layout reflects the same structure. The skills/ directory holds the packaged agent workflows as SKILL.md files with bundled references/, runtimes/ holds the runtime adapters, bin/ holds the CLI entry point which package.json points at./bin/ppt-agent.js, src/ holds the source modules such as codex-imagen.js, scripts/ holds the individual tools like html2pdf.js, html2png.js, html2pptx.js, figma-export.js, design-gate.js, validate-slides.js and editor-server.js, and templates/ holds the slide templates. There is a.codex-plugin/ directory for the plugin packaging, an artifacts/ directory, a showcase/ directory with its own manifest build script, a convert.cjs at the root, and tests/. The editor is described as pure JavaScript, and the README says you can easily add new features like adding new coding agents or changing designs. For a tool whose whole premise is that agents and humans work on the same files, an editor that is itself plain JavaScript is consistent, and it means the barrier to extending it is the same as the barrier to reading it. ## Conclusion slides-grab fits a team producing decks with a coding agent where the feedback loop is the bottleneck, because it lets a reviewer point at the exact rectangle of a slide that is wrong and hand that region to the agent rather than describing the change in prose. It does not fit a team that needs to deliver a stable .pptx to an external audience, because the PPTX path is described as experimental and unstable, and the Figma export is an importable PPTX rather than a real Figma file. Check three things before you commit. Check the export format you actually have to deliver, since the PDF path has capture, image backed and print modes while the PPTX path has a raster mode, a text engine mode and a Figma variant, and only the PDF modes are described as stable. Check the design gate, because the packaged workflow blocks slides-grab pdf, slides-grab convert and slides-grab figma until slides-grab design-gate records a fresh proceed receipt for the current slide files. And check the runtime, because export, visual validation, the local editor and image generation all need the local Node.js and Playwright setup even when the hosted ChatGPT plugin is used. The last push was on 2026-10-01, the newest release listed is v1.5.2 from 2026-09-06, and the license is MIT. ## FAQ ### What does slides-grab do? It is an agent first presentation framework for planning, designing and visually editing HTML slides with Claude Code or Codex, then exporting to PDF or experimental and unstable PPTX and Figma formats. The editor supports bounding box selection, direct text editing and agent powered rewrites. ### What is the design gate in slides-grab? Exports through slides-grab pdf, slides-grab convert and slides-grab figma are blocked until slides-grab design-gate records a fresh proceed receipt for the current slide files, so a deck has to pass a design review step before it can be exported. ### How do I install slides-grab? For an agent, paste the single line that tells it to read docs/installation/claude.md or docs/installation/codex.md. For a no clone install, run npm install slides-grab, npx playwright install chromium and npx slides-grab install-skills --target all --scope user. Node.js 20 or newer is required. ### Can slides-grab export to PowerPoint? It exports to an experimental and unstable PPTX. The convert command has a raster mode at higher resolution and a text engine mode described as editable text with best-effort DOM extraction, and the figma command exports an experimental Figma Slides importable PPTX. ### How many design styles does slides-grab bundle? It bundles 95, made up of 30 derived from pptx-design-styles, 5 slides-grab originals and 60 PPT packs derived from design-diversity. Direct duplicates are aliased to builtins and hidden by default, so 92 are selectable by default while all 95 remain resolvable with list-styles --all. ### What license is slides-grab released under? MIT, as declared in package.json with a LICENSE file at the repository root. The newest listed release is v1.5.2 from 2026-09-06, and the last push was on 2026-10-01. ## Sources - [License: MIT](https://github.com/NomaDamas/slides-grab/blob/main/LICENSE) - [NomaDamas/slides-grab on GitHub](https://github.com/NomaDamas/slides-grab) - [Project website](https://nomadamas.github.io/slides-grab/) - [README](https://github.com/NomaDamas/slides-grab/blob/main/README.md) - [Releases](https://github.com/NomaDamas/slides-grab/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nomadamas-slides-grab