Token-Driven Design Meets Automated Delivery

When we started revamping the design system, the goal was to create a foundation that could scale quickly and adapt to multiple themes without fragmenting the component library. To solve for this, I relied on two complementary strategies: design tokens in Figma and a prompt-engineered approach to building a component-driven system from the ground up.

Setting Up Figma for Theming and Tokens

Figma’s introduction of variables and modes enabled true theme switching within the design file. I created a token structure that defined semantic variables by mapping dozens of tokens across themes. Examples include text-default, btn-primary-hover-bg, and table-header-bg, each tailored to support light and dark modes using Figma's native variable system.

This approach not only made it easier to maintain consistent styling across the UI, it also ensured that switching from one theme to another didn’t require duplicating components or redefining styles. Everything flowed through the token system.

For development handoff, I used a plugin that exported Figma variables and tokens directly as CSS custom properties. This eliminated the need for a manual translation layer and created a seamless bridge between the visual language in Figma and the implementation in code. The tokens could be dropped directly into the component system, keeping styles consistent and centralized across design and development.

Building a Component Demo System with Prompt Engineering

Once the tokens were defined, the next challenge was structuring a scalable system for documentation and demos. This is where prompt engineering played a critical role.

I used Claude to help scaffold a set of shell scripts that automate the creation and rendering of component demos. The idea was to feed Claude a combination of variable structures, component anatomy, and content structure, then use that to shape an extensible workflow that could generate:

• Migrated component HTML files from foldered content

• Static demo pages using a consistent stage template

• Auto-generated table of contents based on heading structure

Here’s a breakdown of how the system works:

1. migrate-components.sh
   Scans nested component folders and lifts each demo-content.html file into the top-level components directory for processing.
   
   

2. toc-generator.sh
   Parses headings in each HTML file, injects semantic IDs if missing, and creates a sidebar TOC with anchor links to improve scannability and UX.
   
   

3. demo-generator.sh
   Combines each processed component with a stage template, injecting the demo content into a predefined placeholder. The result: a clean, isolated preview page for every component.
   
   

4. build-demos.sh
   A single command that runs all three steps above, enabling anyone on the team to rebuild the component library with one script.

This pipeline became the backbone of our design system documentation. And because it was prompt-generated, the structure could evolve quickly, with no manual build process or brittle tooling required.

Conclusion

Design tokens allowed for visual consistency and theme scalability in Figma. Prompt engineering enabled automation, repeatability, and structured output on the development side. Together, they formed a system that was easy to maintain, easy to scale, and capable of adapting as our needs evolved.

By combining design-first thinking with AI-generated scaffolding, we created not just a design system, but a framework for continuous growth.