Building an agentic design system

One table shows pagination counts. Another just says "Next". UI elements look different on every page. Labels and other texts are wildly inconsistent. A designer updated Figma last week. An engineer couldn't find the design and copied something close. Nobody did anything unreasonable. The system just made inconsistency easy.

Most design systems try to solve this with better documentation. Write it down. Make it findable. Hope people read it.

An agentic design system takes a different approach: executable rules that check every change automatically.

Instead of documentation you hope people read, you write skills - Markdown files that agents (Claude, Codex) can run. Every time code changes, hooks trigger these skills to validate UX writing, accessibility, component usage, layout structure, and design standards. The agent sees the results and self-corrects before human review.

Skills make design decisions executable and testable, not just documented.

The problem with traditional design systems

Most teams maintain the same design system in multiple places: a Figma UI kit, Storybook component docs, and implementation code. Each tries to be a source of truth. Each shows a slightly different version.

This duplication creates inevitable drift. The Figma button has states the code doesn't. Storybook documents a variant that never made it to Figma. The implementation quietly added props that neither knows about. When someone needs to build something, they see three partial truths and infer the rest.

That works for a single button. It breaks down for a dense product with tables, filters, drawers, forms, empty states, and admin workflows. The cost: rework, slower delivery, inconsistent patterns, and constant debates about which version is "correct."

The shift: from documentation to skills

What if design rules could run like tests?

That's what skills do. Each skill is a Markdown file that defines rules and can be executed by AI agents to validate changes:

• UX Writing skill - Checks micro-copy, labels, writing rules, error messages, navigation texts
• Accessibility skill - Validates ARIA labels, keyboard navigation, color contrast, focus states
• Component skill - Ensures the right components are used in the right contexts
• Layout Structure skill - Enforces action placement, filter positioning, page structure
• Design Standards skill - Checks spacing, typography, color token usage
• UX Foundations skill - shares personas, jobs-to-be-done, scenarios, journey phases for better context

These aren't guidelines to read. They're checks that run automatically on every change.

How skills work: continuous validation through hooks

Every time an agent suggests a change, hooks automatically run all relevant skills before code is committed.

Hooks are automated triggers configured in your development environment that execute specific commands in response to events—in this case, running skill validation whenever code changes.

An agent builds a table with pagination. Before the change lands:

• Component Usage skill: ✓ Using the stable Table pattern
• UX Writing skill: ✗ Pagination says "Next" instead of "Page 2 of 15"
• Accessibility skill: ✗ Missing visible row count for screen readers
• Layout Structure skill: ✓ Actions are top-right aligned
• Design Standards skill: ✗ Using hardcoded gray instead of text-secondary token

The agent sees all five reports in seconds, fixes the three issues, re-runs validation, and only then considers it done. This happens before human review.

This is different from linting that runs once at commit time. Skills are part of the conversation. The agent doesn't just know the rules - it runs the checks on every prompt.

Skills, UI component library & Figma

Skills define the rules: components, patterns, UX writing standards, accessibility requirements, layout structure, user scenarios. Skills run during the conversation you have with your AI Agent (Claude, Codex), after every prompt, the agent suggests changes. By the time you review, a lot of quality issues are already caught.

The UI component library is where the actual code lives: reusable components, design tokens, routes, interaction patterns, and behavior. Storybook documents these implementations as the single source of truth.

Figma mirrors for review: presentation, discussion, flow layouts, stakeholder communication.

This means Figma is no longer the source of truth for designers. It remains valuable for exploration and presentation, but it's checked against skills and code. When things drift, the system reports it automatically.

What each skill does

UX Writing skill Enforces consistent product language. Checks button labels (verb-first: "Create agent" not "Agent creation"), empty state messages (specific to user context, not generic "No data"), error messages, navigation text, form labels, and destructive action wording. Makes sure "Create", "New", and "Add" don't all appear for the same action.

Accessibility skill Validates ARIA labels, keyboard navigation, focus states, color contrast, and screen reader support. Ensures every interactive element has proper accessible names and that information isn't conveyed by color alone.

Component Usage skill Answers "which component should I use?" Is this component stable, provisional, or deprecated? Should I use Table or DataGrid? When is a drawer appropriate vs. a modal? Which button variant for primary actions? Prevents agents from copying patterns that exist but aren't canonical.

Layout Structure skill Enforces consistent placement. Primary actions top-right. Filters above tables. Breadcrumbs at page top. Secondary actions grouped logically. Status indicators in consistent positions. Prevents every page from inventing its own layout logic.

Design Standards skill Checks token usage. Are you using bg-surface-secondary or hardcoded #f5f5f5? Spacing from the scale or random pixels? Typography from defined sizes or inline styles? Catches drift before it compounds.

UX Foundations skill Provides context about users and workflows. Shares user roles ('personas'), journey phases, jobs-to-be-done, and documented scenarios. Helps agents make product decisions, not just layout decisions. The difference between "No data" and "No agents created yet" comes from understanding user context.

Why this helps different roles

For product owners and business analysts: Clearer definition of done. Instead of debating every UI detail, you reference skills. "Does it follow the table pattern? Does it pass UX writing validation? Does it match the documented scenario?" Reduces rework and focuses reviews on actual product decisions, not inconsistency fixes.

For UX designers: Design decisions survive implementation. A choice you make isn't trapped in a Figma file or comment thread - it becomes an executable rule. Figma remains useful for exploration and presentation, but stable decisions get encoded in skills that agents and engineers actually follow. Less time re-explaining the same patterns.

For engineers: Less guesswork. Before building, check which component to use, which layout pattern to follow, what the copy should say. Build it. Let skills validate it. Fix issues. Ship. Fast implementation without creating a patchwork of reasonable-but-different choices.

For AI agents: Clear boundaries. Instead of inferring rules from whatever code exists, agents read explicit skills and run validation checks. They can move quickly without inventing new patterns or copying provisional code. The system tells them what's stable, what's deprecated, and what quality bar to hit.

The changing role of Figma

Figma doesn't completely disappear (yet)

Figma remains excellent for presenting flows, discussing layouts, reviewing scenarios, and making decisions visible. But it's no longer the source of truth.

The design system still has Figma files with components, variables, and scenario storyboards. But these are mirrors checked against skills and code using the Figma MCP. When they drift, the system reports it automatically.

Figma becomes a presentation layer, not a governance layer.

TL;DR

An agentic design system allows for making design decisions executable instead of just documented.

Traditional design systems say: "Here's how to build a button. Please remember to follow these rules."

Agentic design systems say: "Here are the rules. They run automatically. If you break them, you'll know it immediately."

The shift is from documentation you hope people read to validation that runs on every change.

Skills turn unwritten design culture into automated checks. Hooks make those checks continuous, not occasional. Agents follow the same rules humans set. Quality becomes measurable, not aspirational.

The result is a shared product language that survives hand-offs, implementation, reviews, automation, and iteration. Not just reusable components - reusable decisions.

Design decisions scale better, last longer, and stay consistent in a world where the barriers to development are lower than ever, more roles beyond engineering can build directly, and delivery speed continues to increase.