UpSkill Agentic Design System

Building an AI-driven operating system around a component library, so maintainers and AI agents can create, validate and maintain UI components side by side with minimal upkeep.

UpSkill Design Foundations

Role

Senior Product Designer

Main Goal

Agentic design system

Challenge

Production-ready components without 24/7 agent orchestration

AI generates UI fast, but the result only looks fine on the surface; by default it's expensive to run and unreliable. At scale it drifts: invented components, misused tokens, stale Figma files.

The real challenge is guiding the LLM to understand design intent and stay aware of the system's state, without 24/7 orchestration or costly live MCP calls.

Approach

Turning unpredictable AI output into reliable code

Where I started, and why it changed

Figma as the source of truth. It can't hold every state, accessibility rule or code-only property, and syncing it needed an Enterprise-only API. So code became the source and Figma a checked mirror.

A single large AGENTS.md file. It became tiered, loading rules by task instead of all at once.

One contract file per component. It became two: a metadata file on how to use a component, and a spec on how to build it.

The framework

The system follows the four parts of a common agent architecture, and keeps the model out of every part a script can handle.

  • Tools. More than 60 deterministic scripts, commands and workflows sync the system and prepare the data agents read, without spending a single token.
  • Memory. The repo is the single source of truth. It records what components mean, how work is done, why the system is this way and what is true right now, and agents load only the part a task needs.
  • Planning. Nine Claude commands handle design intent, like proposing a component API or generating one, and run only when a maintainer triggers them.
  • Guards. Automated checks stop bad changes before they merge, and an adversarial reviewer agent challenges interactive components. A status command shows maintainers each component's build and review state, and issues found in audits become new rules agents follow, so they aren't repeated.

Giving AI the right context at the right time

Each task loads only the context it needs: too much costs money and distracts the model, too little makes it guess. The system's memory lives in four layers an agent reads on demand. See memory layers

  • Intent: what things mean. Component contracts, token layers, docs and glossary, loaded only when a task touches them.
  • Procedure: how work is done. A small AGENTS.md loads in every session, kept under 8KB by CI. Detailed rules, commands and skills load on demand, so every developer and agent works the same way.
  • History: why it is this way. Decision records (ADRs) explain each structural choice, and handoff files let a fresh agent pick up where the last one stopped.
  • State: what is true right now. Snapshot files hold each component's lifecycle stage, token use and sign-off, rolled into one STATUS_QUO.md summary. Agents, the CLI, Storybook and Airtable all read from it, so nothing queries Figma live.

Loops that build, review and learn

Before building, the agent picks one of seven answers, from reuse to build new or escalate, each backed by a decision record.

The add-component loop then proposes an API and waits for my approval. That proposal becomes the spec that code and Figma are built from, followed by automated checks, my Storybook review and, for interactive components, an adversarial reviewer agent with a full behavioural accessibility review.

Other loops keep the system current: stale docs get rewritten and review findings update the rules.

Keeping only what tests prove

Context, loops and rules stay only if a test shows they help. Each test hid the answer key and recorded a prediction before the first run, so misses were reported instead of tuned away.

  • Context over loops. I deleted three shipped components and had the agent rebuild each one three times. Without the written rules and decisions, 6 of 9 builds came out clean; with them, all 9 did. The full review loop didn't add a single clean build and cost 1.7× more, so the adversarial reviewer and its full behavioural accessibility review now run only on interactive components.
  • Governance. I gave the agent 11 past build decisions with the answers hidden. It matched 10 and turned down every request outside the system's scope.
  • Figma fidelity. With the component contract, the agent rebuilt two Figma components with a 96% match in structure. From code alone it reached 40%, and my hand-built file scores 98%.
End to end pipeline diagram showing sense, scaffold, gate, review, and PR
End to end pipeline
CLI command displaying component build and review status
Components status CLI command
                                        
                                             "patterns": [...],
                                             "antiPatterns": [...],
                                             "accessibility": [...],
                                             "composition": [...],
                                             "tokens": [...]
                                        
Metadata schema, the semantic layer for LLMs
Agent context layer architecture diagram
Agent context layer architecture
Add component loop / LLM command
Add component loop / LLM command
Airtable governance table preview
Component workflow and token inventory
Solution

AI as infrastructure

Build quality goes up, in code and in Figma. Contracts define properties, states and behaviour, so code and Figma match beyond tokens.

It costs little to run. Scripts do the routine work and nothing runs around the clock, so cost follows actual work.

Every contributor reads the same source. Every touchpoint, from the Airtable board to Storybook, is generated from the repo, so no one updates one by hand or asks which version is current.

Governance guides every change. Before a component is added or modified, the agent checks it against the component specs and recorded decisions and recommends a path, so new maintainers decide with the system's history in hand, without having to learn it first.

App Storybook Docs

Impact

In numbers

  • 50% more components ready to ship: 9 of 9 clean builds against 6 of 9 for the same repo without its written rules.
  • 2.4× more accurate Figma components: measured across all 16 components linked to Figma, before and after contracts.
  • Zero model spend on routine work: 22 scripts, 37 npm commands and 7 GitHub Actions run with no AI calls.
  • 20 live API calls replaced by snapshots: across 7 commands, each read is up to 62× smaller and returns the same result every time.
  • Guided governance on 10 of 11 decisions: with the answers hidden, the agent recommended the path recorded in the decision history, and declined every out-of-scope request.
Result

Screens

Homepage - desktop, tablet and mobile views
Homepage - desktop, tablet and mobile views
Course Details - Dark mode
Course Details - Dark mode
Profile Settings - Dark mode
Profile Settings - Dark mode