From Jira to PR: How we built agent-driven pipelines for design system changes

Design system work follows a well-defined loop: read the ticket, check the Figma spec, find the right component primitives, apply the right tokens, write the Storybook stories, run the tests, open the PR. The steps are consistent enough that when we looked at our design system backlog, we didn't just see a list of tasks; we saw a set of instructions waiting to be executed. So we set an agent loose on the loop. At first, it was a semi-hot mess. But then we gave it the right context, and boom, it has completely changed how we improve our Design System. Here’s our approach on what we did and what we learned. Why we started with our design system Every team considering agentic coding faces the same question of where to begin. The tempting answer is your largest codebase or your most complex feature. The right answer is wherever the work is most well-specified, and the feedback loop is fastest. Our React component library, the web layer of our design system, happened to be both. Conventions are strict by design: that's the whole point of having a design system. The output shape is predictable and well-documented: a component, some design tokens, a story, and a test. The blast radius of any change is traceable. And if a token is wrong, the tests catch it automatically, without a human having to notice. That combination of explicit conventions, predictable outputs, and automatic validation describes exactly the kind of bounded context where agents do well. When we looked at where to prove the pattern before adapting it to larger, messier codebases, the design system was an obvious answer. What happened when we pointed a general-purpose agent at our design system The first attempt was to take a well-scoped ticket, hand it to a capable coding agent, and see what comes out. The results were instructive, and not in the way we hoped. The agent could read the ticket and navigate the codebase. But without design system-specific context, it filled knowledge gaps with confident-sounding guesses. It placed tokens at the wrong tier in the hierarchy. Reached for raw HTML elements instead of the correct component primitives. The agent often chose components that looked right in isolation but were semantically wrong for the system, the kind of inconsistency a developer would catch immediately because it breaks patterns that only make sense in the context of the product as a whole. It opened PRs that didn't follow the team's merge template; the code was often compiled, and tests even passed, but the output wasn't idiomatic. It was close enough to look right yet different enough that a reviewer had to do substantial correction work before anything could merge. We hadn't saved developer time by making it easier to open a PR; instead, we'd moved the work downstream. Without institutional knowledge, the agent’s work was insufficient. It knew how to write React, but it didn't know how our design system writes React: the specific directory structure, the token tier model, the CI conventions, and the component primitives we use instead of raw elements. That knowledge lives in the heads of everyone who works on the system, not in any file the agent could easily read. The fix: making tacit knowledge explicit with agent skills The solution was to stop expecting the agent to infer what experienced contributors know implicitly and start encoding that knowledge as explicit, executable instructions. We wrote a set of skills covering the core design system contributor workflows that included Scaffolding a new component Defining tokens Writing Storybook stories Adding icons across platforms Opening a merge request Debugging a CI failure Tracing cross-platform impact from a token change Each skill provides the agent with exact file paths, naming conventions, import patterns, and build commands to make them executable by our agent. We also exposed Knox through MCP for consumer-facing workflows where agents don’t necessarily have the Knox repo available but still need authoritative guidance on components, design tokens, and interaction patterns. This gave agents a way to ask the design system what exists, how to use it, and which patterns are appropriate without relying on guesswork or outdated copied context. We folded in our existing builder-facing documentation, including real examples from the product, so the agent could anchor its decisions in consistency. Instead of the agent inferring what's in the system by reading source files, it can ask our design system directly. Our MCP server also added documentation on the user’s intent and the problem a specific component would solve. It enabled the agent to not only make it visually correct but also function as the user would expect in the product UI. Right away, the agent’s output improved. It stopped guessing conventions because the repeated contributor workflows were now explicit. It had focused skills, clear commands, and a human-qualified ticket to work from. How to do th

Excerpt shown under the publisher's RSS terms · 200 words · full text and figures are on the publisher's site