Blog

Claude Code | 10 min read | 2026-04-25 | Updated 2026-04-26 | By Variant Team

How to Make a Slide Deck with Claude Code

A practical walkthrough for building a slide deck with Claude Code over MCP using Variant: prompt to draft, preview, hand edit, and export to HTML, PDF, or PPTX.

Author: Variant Team. Variant is built by a small team working on HTML-native presentation tools, MCP workflows, and agent-editable decks.

You can make a full slide deck with Claude Code by connecting it to Variant over MCP, then asking Claude to draft slides, preview them, edit specific ones, and export the result. The slides live as standard HTML and CSS, so you can hand-tweak them on a visual canvas or in a code tab without fighting a proprietary format.

#Quick answer

To build a Claude Code presentation with Variant:

1. Connect Variant's MCP server to Claude Code (OAuth or a scoped bearer token).
2. Ask Claude Code to call deck.create with your topic, audience, and rough outline.
3. Open the deck in Variant. Use slide.preview to spot-check what Claude built.
4. Fix anything off with slide.edit for one element, or slides.batchUpdate for multiple slides.
5. Polish on the canvas. Edit text, drag elements, swap an image. The code stays in sync.
6. Run deck.export for HTML, PDF, PPTX, or JSON.

That's the loop. The rest of this post walks through it with an example prompt, the MCP tools you'll actually touch, and the little traps that tend to cost people half an afternoon.

#Why use Claude Code for slides at all

Most AI slide tools generate something that looks fine in a thumbnail and gets annoying the moment you need to change a single bullet. You end up regenerating the whole slide because the tool can't reach in and edit one word.

Claude Code is different because it's an agent that already understands files, diffs, and structured edits. Pair it with Variant, where every slide is real HTML and CSS, and you get something closer to working with a real codebase than fiddling with a slideshow app. Claude reads the slide, edits the part you asked about, and leaves the rest alone.

A few things follow from that:

• You can ask for surgical changes. "Change the title on slide 4 to X" actually changes the title on slide 4.
• Slides are inspectable. If something looks weird, open the code tab and read it.
• Output is portable. A single self-contained HTML file is the canonical format. PDF and PPTX are there when you need them.

#What you need before you start

If you've never wired up an MCP server in Claude Code, the short version: you point Claude Code at Variant's MCP endpoint, finish the auth handshake, and the tools show up the next time Claude needs them. No SDK code on your end, and no tiny integration to maintain.

#Step 1: Set up Variant as an MCP server

In your Claude Code config, add Variant as an MCP server. OAuth is the easiest path because it handles refresh for you. If you're scripting this on a CI box, mint a scoped bearer token from your Variant settings and paste it into the server config instead.

Once it's connected, ask Claude Code something like "what variant tools do you have?" and you should see the toolset come back. The ones you'll lean on most:

• deck.create — generate a new deck from a prompt and outline
• slides.batchUpdate — change several slides in one call
• slide.edit — edit selected elements on a single slide
• slide.preview — render a slide image so Claude can actually see what it made
• deck.export — output HTML, PDF, PPTX, or JSON
• deck.versions.list and deck.version.restore — undo at the deck level when you mess up

There are more (asset uploads, selection inspection, and so on), but those six cover 90% of a normal session.

#Step 2: Write a prompt that gives Claude something to work with

The biggest mistake is treating Claude Code like a magic deck button. "Make me a deck about our Q3 launch" produces a deck that smells faintly of every Q3 launch. The fix is to write the prompt the way you'd brief a designer who has 20 minutes and no patience for missing context.

Here's the kind of prompt that actually works:

Use Variant to create a 10-slide deck for a 15-minute internal demo of our new vector search feature.

>

Audience: backend engineers and our two PMs. They already know what vector search is. They have not used our implementation.

>

Outline: 1. Title slide. Product name: Quill. Tagline: "Search your docs the way you'd ask a coworker." 2. Why we built this. One paragraph, then a stat: 38% of support tickets are duplicates of existing docs. 3. The old flow vs the new flow. Side by side. 4. Architecture. Boxes for ingest, embedding, index, retrieval, rerank. 5. Latency numbers. Bar chart, p50 and p95 against the previous system. 6. Live demo placeholder. Big screenshot slot, no chrome. 7. What's new for the API. Two code samples: search and filter. 8. Rollout plan. Three phases with dates. 9. Open questions. Bullets. 10. Closing slide. Just the product name and a Slack channel.

>

Style: dark background, restrained color palette, clean sans-serif. No stock photos.

Notice what that prompt does: it gives Claude an audience, a length, a per-slide outline, and a style constraint. Claude Code will hand that to deck.create and you'll get something close to what you actually wanted on the first try.

#Step 3: Preview before you start fixing

Once deck.create returns a deck ID, ask Claude Code to call slide.preview for each slide and look at the rendered images. This is the part people skip, and it's the part that saves you 30 minutes of back-and-forth.

Claude can compare what it intended to build against the actual rendered slide. If slide 5's bar chart is missing a label, Claude will see that in the preview and propose a fix without you needing to point it out. This is one of the practical wins of running an AI coding agent on a presentation: it can look at its own output.

A typical exchange:

Me: Preview slides 4, 5, and 7 and tell me what looks off.

>

Claude: Slide 4's architecture diagram has the rerank box overlapping the index box. Slide 5's chart is fine but the y-axis label says "ms" twice. Slide 7's second code sample wraps onto a fourth line that runs into the slide footer. Want me to fix all three?

Yes, you do.

#Step 4: Edit with slide.edit and slides.batchUpdate

For a single slide, slide.edit is the right tool. You tell Claude what to change and it edits just that element. The rest of the slide is untouched. No layout shift, no surprise rewrites of bullets you liked.

For multi-slide changes ("apply our brand color to every section header" or "change the footer on slides 2-9 to include the date"), slides.batchUpdate does it in one call. Faster, cheaper, and the deck stays consistent because all the edits go through one operation.

A useful pattern: ask Claude to plan the changes first, show you the plan, then run the batch. Something like:

Me: Walk me through what you'd change to switch the deck from dark mode to light mode, then make the changes.

>

Claude: I'd update the body background on every slide from #0B0B10 to #FAFAF7, swap the primary text color from #F4F4F4 to #111, and adjust the chart series colors on slide 5 so they still pass contrast. I'll leave the screenshot on slide 6 alone. Sound right?

Then it runs slides.batchUpdate once. Done.

#Step 5: Hand-edit on the canvas when you want to

Variant has a visual canvas. You can drag elements, retype text, swap images, and resize things directly. You can also flip into a code tab and edit the HTML and CSS by hand. The two stay in sync. Move a heading on the canvas, the code updates. Tweak a CSS property in the code tab, the canvas reflects it.

This matters because there's a class of edits that are faster to do by hand. Nudging a logo two pixels left. Swapping a placeholder screenshot for a real one. Picking the exact shade of teal you want. Don't bring an LLM into a fight that a mouse will win.

The reverse is also true. If you need to apply the same change across 30 slides, don't do it by hand. Ask Claude.

The point of code-native slides isn't "AI does everything." It's that the seams between AI edits, manual edits, and code edits all disappear, because everything is just HTML.

#Step 6: Export

When the deck looks right, export it. Claude can call deck.export with the format you want.

HTML is the canonical format for a reason. It's the thing Variant actually authors. PDF and PPTX are translations. They're good translations, but if you have the choice, share the HTML. It opens instantly, looks the same on every machine, and you can drop it on any static host in five seconds.

#A version safety net

Slides have a habit of getting "improved" into something worse. Variant tracks deck versions, and Claude can list and restore them. If you wreck a slide, ask Claude to call deck.versions.list, pick the one from before you wrecked it, and run deck.version.restore.

This is the part that makes experimentation cheap. Try the strange color system or the cleaner section break. If it goes sideways, roll back.

#A worked example, end to end

Here's how a 20-minute session might actually go.

1. You write the briefing prompt above and paste it into Claude Code.
2. Claude calls deck.create. You get a deck ID and a draft.
3. You open Variant in the browser, see the 10 slides.
4. You ask Claude to preview slides 4, 5, and 7. It catches the architecture overlap and the duplicate axis label.
5. Claude calls slide.edit three times to fix those.
6. You realize the title slide tagline isn't quite right. You click into it on the canvas and retype it yourself. Six seconds.
7. You decide the deck should be light mode. Claude plans the change and runs slides.batchUpdate.
8. You drop in the real demo screenshot for slide 6 by uploading it on the canvas.
9. Claude calls deck.export and hands you back an HTML file and a PDF.
10. You drop the HTML on a static host and send the link. You attach the PDF for the one person who refuses to click links.

That's a Claude Code presentation workflow that took less time than finding the meeting room adapter.

#Related reading

• Create a Presentation with Claude Code: Full Workflow
• Connect Claude Code to an MCP Presentation Editor
• Build Agent-Editable Presentation Decks with MCP

#FAQ

#Can Claude Code make a PowerPoint?

Yes. Build the deck in Variant via the MCP tools, then call deck.export with PPTX as the format. You'll get a real PowerPoint file. The HTML export is usually the better artifact, but PPTX is there when the audience needs it.

#Do I need to know HTML and CSS to use this?

No. If you only want to talk to Claude and tweak text on the canvas, you never have to look at the code. The point of code-native slides is that the code is there for you when you want it, not that you have to write it.

#How is this different from generic AI slide tools?

Two things. First, the slides are real HTML and CSS, so you can edit them surgically instead of regenerating the whole slide to fix one line. Second, the entire flow runs through Claude Code over MCP, so you get an actual coding agent that can read, edit, preview, and export instead of a prompt-in-deck-out black box.

#Can I use this with Cursor or Codex or another agent?

The MCP server is generic. Anything that speaks MCP can call the same 18 tools. Claude Code is the one we've used most, but the protocol is the protocol. If you're vibe coding in another agent, point it at Variant's MCP endpoint and you'll have the same tools available.

#Can I version-control my decks?

Yes. The HTML export is a single file. Drop it in git like any other source file. The JSON export is also stable enough to diff. Variant also tracks versions inside the app via deck.versions.list and deck.version.restore, so you've got two layers of safety net.

#A practical first test

Pick a deck you'd otherwise avoid until the night before. Not the board deck. Something smaller: a product update, a launch recap, a five-slide explainer for the team.

Write a tight prompt. Let Claude draft, preview, and edit. Hand-tune the bits that need a human eye. If the workflow saves you from the blank-slide stare and still leaves you in control of the final deck, it's worth keeping around.