I Built an OSS Tailwind Theme Generator With Claude Code

Most theme generators change a hex value and call it done. I wanted something different: a tool where switching from “Corporate” to “Playful” changes not just colors, but font personality, spacing rhythm, and border radius in a single click. Every visual decision encoded in tokens.

I also wanted to figure out what serious Claude Code development actually looks like — not one-shot prompts, but a structured workflow where the AI does the implementation and I do the architecture and review.

Why a Theme Generator

Every Tailwind project starts with the same question: what does this product feel like? The answer lives in tokens — but most developers hardcode values directly or copy a shadcn preset and move on. The theme never really gets designed.

Theme Studio is a free, open-source tool for exploring that question visually. Pick a personality preset, watch the UI components respond, copy the generated CSS variables. No account required. The output is plain CSS — no vendor lock-in.

It’s also a portfolio piece. Building a real UI tool in public is a better signal than describing one in a cover letter.

Token Architecture

The theme system uses a 3-layer token stack: primitives → semantic → component. No component references a raw value directly.

Every personality preset swaps the primitive layer only. Semantic and component tokens inherit the change automatically. Switch from “Midnight” to “Sand” and 300+ token values update in a single assignment.

Font personality works the same way: --font-family-sans and --font-size-scale are token values. A “Humanist” preset loads a different typeface than “Geometric”. No component knows which font it’s rendering — that decision lives in the token layer.

Building With Claude Code

The actual implementation was done almost entirely by Claude Code (Claude Sonnet in the CLI). My role: architecture, specs, review, decisions. Claude’s role: write the code that implements those decisions.

This division of labor sounds clean in theory. In practice, it requires constant calibration. The key lesson: the more precisely you define the contract before prompting, the less the AI invents things you didn’t ask for.

What worked well: giving Claude a typed TypeScript spec and a Markdown component description before asking it to implement anything. What didn’t work: vague prompts like “build a slider component.” Vague prompt → generic shadcn clone. Specific prompt with ARIA requirements, prop table, and interaction spec → something actually useful.

I also used Linear tickets as the task boundary. Claude works on one ticket at a time. The ticket defines the scope; anything outside it gets rejected at review. This keeps implementations focused and prevents feature creep between sessions.

The Component Pipeline

Each component follows a fixed pipeline before it can appear in the gallery:

The spec file is the most important artifact. It defines every prop, every variant, every keyboard interaction, and every ARIA attribute before any code is written. Claude implements against the spec; the review gate checks that nothing was missed or invented.

This gate structure is what makes AI-assisted development reliable. Without it, you end up reviewing a component that technically works but violates your accessibility requirements or adds props you didn’t ask for. With it, deviations are caught before they ship.

The trade-off is speed. Each component takes longer than a one-shot prompt. But the quality is consistent, and the spec files double as documentation.

What Shipped

The live version includes 11 components: Button, Checkbox, Input, Select, Switch, Radio, Slider, Combobox, Badge, Separator, and Tabs. Each is fully ARIA-compliant and keyboard-navigable. The theme switcher works across all of them simultaneously.

Personality presets: Default, Midnight, Sand, and Forest. Each swaps the full token primitive layer — colors, fonts, radius scale. The font switcher is independent of the color preset.

Export: CSS variable output that can be dropped into any Tailwind project. No framework dependency, no runtime requirement.

Honest Take

Eleven components is not a lot. The original plan included a full form system, a typography specimen view, and a live code editor. None of that shipped. The scope shrank as the per-component cost became clear.

The spec-driven pipeline works. The output quality is better than what I get from open-ended prompting. But it is genuinely slow — not because Claude is slow, but because writing a good spec takes real thought, and reviewing an implementation carefully takes more time than most people assume.

What I shipped is a real tool that solves a real problem. I use it myself before starting new projects. That’s the bar I care about.

The Claude Code workflow is the part I’d repeat on any future tool. Typed specs + ticket boundaries + explicit review gates = predictable output from an unpredictable system. That’s a pattern worth documenting.