Building an AI pipeline for design delivery
Most AI design tools stop at generating a screen. I built a pipeline that takes a feature from brief to a checked build. AI does most of the work at each step, and I review at each gate.
Key contributions
- Designed and built an end-to-end AI design pipeline in Claude Code, from competitor research to build verification, now used by 6 PMs and designers across 10+ features
- Defined a spec format that maps every element to a design system component, with a discovery gate that stops the AI from duplicating existing components
- Automated localization from Figma to the CMS, cutting it from 1 day to 1–2 hours per feature
- Built a build-verification skill that measures the live page against Figma and reports every mismatch
Context & problem
At Collect2Day, localization took up a large part of every design delivery. Our design files were also made for people to read, which made them hard for AI tools or front-end engineers to use directly.
The Problem
- Localization was slow: copying strings out of Figma, translating them, creating CMS keys, and matching them back to the design
- Design deliverables weren't structured, so AI tools and front-end couldn't read them reliably
Goals
- Cut the time localization takes
- Make design deliverables that AI and front-end can both read, for smoother handoff
- Support the company's goal of adopting AI across teams
The pipeline
I built a set of AI skills that run in order. Each one produces a file the next one reads. AI does the generating, and I review at each step.
The first stage, /competitor-research, pulls real screens from competitor apps on Mobbin. Mobbin only has one search box, so the skill breaks a feature into search angles by app, component, pattern and flow.
How it evolved
- Mar 2026 · Built as a three-step pipeline: spec, build, review
- Apr 2026 · Moved the build onto the Figma REST API, with an access check before each run
- Apr 2026 · Turned it from my own setup into a plugin the team installs
- May 2026 · Added a component discovery gate after the AI invented components that already existed
Design highlights
Highlight #01 · /design-specGenerating the design spec
/design-spec turns a feature into a spec that maps every element to a design system component:
Early on, the AI invented components that already existed, so I added a gate: it must search the library and production Figma before proposing anything custom, and record a Component Decision Matrix.
| Element | Component | Data source |
|---|---|---|
| Back button | Icon Button · tertiary-on-brand | static |
| Page title | Text · Heading 1 / Bold | static |
| Progress count | Text · Caption / Regular | api.badges.summary |
| Completion % | Text · Heading 2 / Bold | unlocked / total |
| Progress bar | CUSTOM: ProgressBar · thick | derived |
Building screens from the spec
/figma-design reads the spec and builds the screens directly in Figma, using the components the spec already chose. Then I refine the result with prompts.
Component-first
Every element is an instance from the design system library, not a hand-drawn shape
Style-bound
Text styles and colour variables are bound, so there are no raw hex values
Follows the spec
Builds from the spec's Elements tables without re-picking components, entirely over the Figma REST API
Early runs exposed three problems:
| Problem | What I changed |
|---|---|
| Raw hex values leaked into builds instead of bound variables | Enforced variable binding, and added a check that scans for raw hex before every write to Figma |
| Every run needed Figma Desktop and a bridge plugin open | Moved the build to the Figma REST API, with an access check before each run |
| A custom card was built structurally wrong from a flat list of slots | Added two gates: the spec isn't ready until each custom component has a structure, and the build won't start without one |
TakeawayWritten rules were easy for the AI to skip. Turning them into gates that stop the run is what made them stick.
On one flow, a rebuild raised component coverage from 63% to 86%, with 126 bound tokens.
Highlight #03 · /cms-keysLocalization in one command
/cms-keys handles localization across one or more Figma frames in a single run. It drafts Traditional and Simplified Chinese, and the only job left for a person is reviewing the translations and publishing. Figma and the content system both sync against one content table:
PrincipleA designer should not maintain the same key in three places.
The hardest problems were failures that reported success:
| Problem | What I changed |
|---|---|
| The CMS form reported success while silently skipping some fields | Every value is read back after filling and checked, including the ones meant to stay blank |
| Picking text by rule either created junk keys or missed real ones | Scope now comes only from the CMS Key annotations designers add in Figma |
| A run could skip past the review step, and keys can't be deleted once created | Moved the approval check to right before anything is written, so nothing reaches the CMS unreviewed |
Checking the build against the design
/design-acceptance measures the live page against the matching Figma nodes and reports each mismatch. Filing those as Jira tickets automatically is the next step.
Three rules keep its numbers trustworthy:
Measure the page, not a screenshot
Retina screens double every value in a screenshot, so it measures the live page in CSS pixels
Wait for the real fonts
If the brand fonts haven't loaded, it stops, because a fallback font throws off every measurement
One match or an error
If a design element matches nothing on the page, or more than one thing, it reports an error instead of picking one
Why it mattersWhen the input can't be trusted, the tool stops instead of guessing.
Outcome
- Reduced localization from a full day to 1–2 hours per feature, across 10+ features
- Adopted by 6 PMs and designers, who run the pipeline on their own work as an installed plugin
- Enabled PMs to generate specs with
/design-specand build their own demos from them - Pipeline-built designs reached engineering with no reported issues
What I learned
AI works best when the design system is easy for it to read, which is why the spec maps every element to a component. Written instructions weren't enough on their own. The fixes that held were gates that refuse to run. And building tools with AI taught me to keep a clear line between what I've verified and what should work.