From your writing to a deck — 16:9 HTML slides, exported to PDF or PPTX.
From an existing deck back to editable HTML.
Focus only on writing that keeps a human voice.
Installation · Modes · Examples · Pipeline · Skill anatomy
This came out of two observations.
First, a deck is decided in the writing. On top of prose that already has a voice in it, turning it into slides is close to mechanical work — where to break, what becomes a table, which figure leads, all of it is settled by the text before a single slide exists. There is no reason for a person to keep doing that part by hand. Written down as rules, it is work an AI can take over.
Second, an AI handles HTML far more easily than a PPT file. So the slides are built in HTML, and PDF and PPTX are exported from there.
You write. The skill does the rest.
/plugin marketplace add HiMyNameIsDavidKim/slide-drawer-skill
/plugin install slide-drawer@slide-drawernpx skills add HiMyNameIsDavidKim/slide-drawer-skillCopy the skills/slide-drawer/ directory into your project's .claude/skills/ folder:
cp -r skills/slide-drawer/ /path/to/your/project/.claude/skills/pip install playwright pillow python-pptx pymupdf
playwright install chromiumRestoring a PPTX also needs LibreOffice on PATH, for the conversion to PDF. The scripts check their own dependencies and print the install command if one is missing.
Claude Code · Cursor · Codex CLI · Gemini CLI · Windsurf · Cline · Continue · Any Agent Skills-compatible host
| Mode | Trigger | Output |
|---|---|---|
| Create | "turn this report into a deck" | Outline for approval, then HTML + PDF |
| Revise | "fix slide 12", "this card doesn't read well" | Targeted edit + partial re-render |
| Export | "give me a PPTX" | 13.33×7.5in PPTX, only when asked |
| Restore | "restore this deck", "이 PDF를 HTML로" | One semantic HTML file + PDF, at the source's page size |
Create runs through an outline gate — a slide-by-slide table is approved before any HTML is written. Which slides exist, what each one says, and which component carries it are settled there, so the writing that follows is the only thing left to judge.
The source is an ordinary engineering write-up. examples/ci-build-times.md, 815 words of prose:
## Where the time went
The pipeline has four stages, and they are not close to each other in cost.
| Stage | p50 | Share |
|---|---|---|
| install | 8m 30s | 71% |
...
Install dominates. It restores dependencies for twelve workspaces, and it was
missing its cache on roughly two runs out of three — a 31% hit rate over the
measurement window.The outline gate comes first. Nothing is written until this table is approved:
| # | Title | One-line point | Components |
|---|---|---|---|
| 1 | (cover) | Twelve minutes to under five, across twelve repositories | cover |
| 2 | Contents | — | toc |
| 3 | Where the time went: install is 71% of the run | One stage costs more than the other three together | accent + bars |
| 4 | The four stages | What each does, and why it costs what it does | table |
| 5 | A lockfile describes the repository, not a workspace | One lockfile covers all twelve workspaces | accent + grid2 + warnbox |
| 6 | Rollout: ① flag · ② measure · ③ roll · ④ gate | Four steps, one repository first | accent + flow + card |
| 7 | Result: 4m 40s at p50, from 12m 00s | The tail moved further than the median | kpis + grid2 |
| 8 | Summary | What we would tell another team | grid3 + accent |
Then the HTML, rendered and overflow-checked. Four of the eight slides:
 |
 |
 |
 |
Full result: ci-build-times.html · ci-build-times.pdf
Revision is mostly one edit repeated: the point is sitting in the first body sentence, and the heading is a topic label. Move the claim up.
✗ ● Where the cache key mattered
The lockfile does not say what the resolver produced. The key had to be built
from the resolved list, and the same rule was applied to both the save step and
the restore step.
✓ ● Resolved by keying on the resolved dependency list
The same rule was applied to both the save step and the restore step. The
restore step was verified by replaying last week's builds.
Nothing was deleted — the claim moved to where a skimmer sees it.
This one fell out of building the skill. It turned out to be needed far more often than expected, so it became a mode of its own.
No converter script. The pages are read as images and rewritten as semantic HTML — the donut, the table, and the tinted panels are rebuilt in CSS, and the deck keeps the source's own page size.
| Original PDF | Restored HTML |
|---|---|
 |
 |
Headings are <h1>, tables are <table>, and nothing that carries meaning stays locked inside an image. Decorative icons and paper texture are dropped on purpose.
source doc ──► outline (approved) ──► deck.html ──► deck.pdf
PDF / PPTX ──► page images ──► (read them) ──► deck.html ──► deck.pdf
The PDF is printed straight from the HTML, so its text stays vector and @page in template.html sets the page size. The deliverable is deck.html and deck.pdf — nothing else.
skills/slide-drawer/
├── SKILL.md ← Mode routing + delivery self-check
├── references/
│ ├── slide-writing.md ← The four-question gate, nine failure patterns
│ ├── language-notes.md ← Per-language line breaking, font stack, pitfalls
│ ├── design-system.md ← Frame, palette, type scale, components
│ ├── revision-protocol.md ← Request classification, sync, fallout
│ └── restore-export.md ← Restore contract, CSS traps, chart recipes
├── assets/
│ └── template.html ← The design system, runnable
└── scripts/
├── render_slides.py ← HTML → PNG, reports overflow + fill ratio
└── export_deck.py ← PNG → PDF | PPTX
Write the deck in whatever language the source is in. English, Korean, and mixed-script decks are covered today.
Language here is not a translation setting. A Korean deck breaks its lines at different places than an English one, needs a different font stack, and falls into different bad habits — so the skill carries separate notes per language and applies them while writing, not after. Adding a language means writing those notes, not changing the skill.
A PPTX from here is a picture of your deck, not an editable one. Each slide holds one image, so the text cannot be edited in PowerPoint. Generating real PowerPoint text boxes was tried and dropped — it forbids most of what this design system is built on, and PowerPoint swaps fonts anyway, which shifts every line break in the deck. Exact appearance was worth more than editing you could not trust. To change something, edit the HTML and export again.
There is one theme and you cannot switch it. The palette is contrast-checked and every size in the type scale was measured on a real deck. A theme picker would hand you one more decision at the moment you should be writing.
TBD — planned to take its look from the separate taste skill, rather than adding a picker here.
MIT — see LICENSE.
If this skill saves you a revision round, consider giving it a ⭐
⭐ Star · 🍴 Fork · 🐛 Issues · 💬 Discussions