The problem
I give talks, and every deck started from zero.
Not the content — the scaffolding. The slide layouts, the theme, the way a code block animates, the pattern for a stat that lands. I'd rebuild the same six slide types every time, slightly differently, and the good ideas from the last deck never made it into the next one.
And the tools didn't help. Slide software wants you in a WYSIWYG editor, which is the wrong environment for someone who thinks in components and lives in a text editor. Markdown-based deck tools go the other way and give you almost nothing — you get bullets, and you're on your own for anything that looks designed.
Why I built it
The pieces should be reusable, and they should be yours.
Butai ships the substrate: a React deck engine, kits of slide layouts, video scenes and document patterns, a set of themes, and Claude Code skills that plan and assemble the content. Bring an outline, walk away with a deck.
The distribution model is the interesting decision, and I took it straight from shadcn: you don't import the slides, you copy them in. The engine is a package. The slides are source code that the CLI drops into your repo, where you own them and can edit anything. Nothing is locked behind a dependency you can't change. A slide layout that's 90% right is useless if you can't fix the last 10%, and that's the failure mode of every component library I've adopted and later regretted.
Themes work by contract, not by hex code. Slides are authored against tokens — accent, status colors, spacing — so switching a theme repaints the whole deck without editing a single slide.
There's also a thing Butai deliberately isn't: an authoring app. No storyboard editor, no visual studio. That got cut. The repo ships the building blocks and the skills that drive them; the writing happens in your own tools. Scoping a project by what it refuses to be is underrated.
How it works
A pnpm and Turborepo monorepo. Seven publishable packages — the engine, the token contract, the themes, and copy-in kits for slides, video scenes, docs, and motion — plus a Claude Code plugin with seven skills and a demo site you can run before adopting anything.
The part I'm most pleased with isn't a feature. It's the provenance guard.
Butai borrows ideas from a lot of places, and the honest way to do that is to write down exactly what you took and what you didn't. So there's a credits ledger, generated from source, and — more importantly — there are tests that enforce it. A test fails the build if a theme from an unverified-license pack shows up in the shipped CSS. Another fails if any recipe imports a paid GreenSock plugin, because shipping a copy-in kit that depends on non-redistributable code would quietly hand every user a licensing problem. The effects that need those plugins are documented as ideas; none of their code ships.
That's a boring engineering decision that I think says more about how I work than any of the features. Licensing isn't a policy document you write once. It's a test that runs.
Results
- Seven publishable packages, MIT licensed, public on GitHub.
- A deck engine, four copy-in kits, thirteen themes, seven Claude Code skills, and a CLI.
- Not yet on npm — the packages are prepped at beta and the publish is a deliberate, un-taken step.
Worth being straight about the timeline: the substrate was built in about two days, by an autonomous agent loop I set running and supervised. The repo still contains the run's plan, journal, and gap list. I'm not going to pretend that was two months of craftsmanship — but I will say that designing the phases, the contracts, and the guard tests such that an agent could build it correctly was the actual work, and it took considerably longer than two days.
What I'd do differently
I forked my own engine and then had to live with two copies. Butai's deck engine was extracted from the presentation app on this very site — and for a while both existed, drifting. Extraction is easy; retiring the original is the part everyone skips, and until you do it you have two systems and one of them is lying.
The demo gallery was broken for weeks and no test caught it. Every slide in the kit browser was rendering at full size inside a small frame, cropped to its top-left corner, frozen. The CSS was invalid and browsers had silently dropped it. Every test passed, because the tests asserted on text and the DOM — and the text was there, it was just invisible. A whole class of bug lives in the gap between "the element exists" and "a human can see it", and I had no coverage there at all.
I under-scoped the docs. The motion catalog confidently linked to two files that did not exist and cited a test that had never been written. Written by me, in a doc about how everything is verifiable. The lesson isn't "check your links" — it's that a doc which describes tooling should be generated from the tooling, or it will drift the moment you look away.