There’s a conversation happening in a lot of product organizations right now that goes something like this. Leadership decides the team is going to be AI-led. Engineers start generating UI with Claude Code, or Cursor, or whatever platform the company has adopted. And the design team watches, increasingly alarmed, as correct components get used incorrectly, validation patterns appear from nowhere, and accessibility quietly disappears, and DesignOps practice is completely ignored.
The usual response is to put a designer in the loop on every implementation. Review the output. Catch what the AI got wrong. Send it back.
That’s not a solution. That’s a tax on your team’s time that grows with every sprint, especially in this world we’re living in right now.
I found a different way. And it’s now something I think every UX leader with an AI-led engineering team needs to build.
What a Skills Library Actually Is
An AI coding platform generates code by reading context. The better the context, the better the output. A Skills library is a set of machine-readable instruction files that the AI reads before it generates anything. One file per design system component, plus cross-cutting pattern files that encode the judgment that spans multiple components.
Instead of the AI guessing how to use your design system, it reads your Skills first. The result is UI that follows your standards by default, without a designer in the loop at generation time.
At Logility, I built 98 Skills covering 100% of our Assemble Design System components, plus 6 pattern Skills encoding page-level conventions like form validation, data list views, loading states, and empty states. The entire thing was packaged with a human-readable README and handed to our engineering architect for integration.
Zero designers are required at generation time. The standards persist and scale beyond the team’s immediate capacity. You can read the full case study here.
Why I Built It Myself
Our UX team is small. Four senior designers, one technical writer, all of them simultaneously doing strategic product work, adapting to new AI tooling, and keeping up with all of this tactical work that this tool can help lighten the load. The last thing they needed was a 50-hour side project.
So I built it instead. Not because it was the most glamorous work on my plate, but because protecting my team’s time and strategic focus is part of my job. A UX leader who lets their team get buried in implementation review cycles isn’t leading, they’re just watching the tactical work expand to fill every available hour, especially with a small UX team. If we had a larger team, or a different mandate coming down, I would have built this skill differently.
This is DesignOps. It just looks different in an AI-led environment.
The Portability Decision
Our engineering platform is a Claude Code instance built specifically for the company’s needs. I could have built the Skills library to be deeply specific to that platform’s conventions and called it done.
I didn’t, and I’m glad I made that call early. Instead of building something that only worked inside of this custom layer, I built something that could be adapted to any AI coding platform that reads context files. Claude Code, Cursor, Copilot Workspace, whatever your engineers are using or whatever they switch to next year. The methodology is the same. The file format is markdown. The content structure is transferable.
That decision meant the work I did at Logility became a methodology I could hand to one of my designers, who is now doing the same thing for a different design system at an acquired company. That’s the difference between a one-off implementation and a repeatable DesignOps practice.
What Goes in a Skills Library
Each component Skill covers the same ground. What the component is, when to use it, and when not to, UX rules that go beyond the Storybook documentation, working code examples tuned to your actual product domain, accessibility requirements, and explicit prohibitions covering the things the AI must never do.
That last section is the most important one. Every component Skill should end with a list of mistakes. Not guidelines. Prohibitions. The AI needs them stated clearly, or it will pattern-match its way into every anti-pattern your team has spent years trying to eliminate.
Beyond component-level Skills, the cross-cutting pattern files are where you encode the judgment that no single component can provide. How do you structure a form? What do you show when a data table is empty? When does a spinner make sense versus a skeleton loader? Those decisions live at the intersection of multiple components, and they’re exactly where AI-generated UI goes wrong most often.
The Constitution Layer
Above the Skills library sits the project Constitution, which is the document that makes your standards non-negotiable at the platform level. The UX section of the Constitution references the Skills library and states the rules in one place. Severity color mappings, accessibility baselines, notification standards, and form conventions.
Skills tell the AI how to use components. The Constitution tells the AI what it’s operating under. Together, they create a design governance layer that scales beyond the team.
What This Is Not
This is not a replacement for UX strategy, research, or systems thinking. The Skills library handles implementation. It does not handle whether you’re building the right thing, whether the information architecture makes sense, or whether the product actually serves the user’s needs.
That’s still human work. And by offloading the implementation review cycle to an AI that reads your standards, you give your team the time to focus on exactly that.
If you’re being pushed toward an AI-led engineering model, and most teams are right now, the question isn’t whether to resist it. The question is how to make sure your design standards come with it. A Skills library is one answer. It won’t solve everything. But it’s a start, and it’s better than putting a designer in the loop on every pull request for the rest of your career.
I wrote a step-by-step guide to building one. If you want it, reach out. You can also read the full case study on my portfolio.
Amber Hansford is a Director of UX based in Atlanta. She builds design organizations, DesignOps practices, and apparently AI governance layers. She writes about design leadership and the structural decisions that determine whether design has actual influence or just the appearance of it.
