What I hadn't done before was whipping up an agentic context system around it. With Harmony — an open-source design system inspired by my Portfolio Template — I wanted to test the moment at which I stop treating an AI agent as a chat assistant and start treating it as part of my front-end architecture, giving it structured context about the reason it exists, its scope, personality, color usage, visual principles, typography, Figma specifications, and other important details so it can handle the translation while I focus on brand identity, design patterns, and the decisions that actually shape the product.

Primitives hold the raw Figma values: brand.500 is the orange, neutral.50 is the warm cream. Semantic tokens express intent: background.primary, content.onBrand, status.negative. Component tokens scope decisions to specific UI elements. Generated CSS bridges it all into Tailwind v4.

One direction. Never reversed. I've used this pattern before. I wanted to see if the agent could work alongside with me in the workflow, not replace, and free up the time I was still spending on the repetitive translation between Figma and code?

I started using Devin — an AI coding agent — with the Figma MCP, which lets it pull variables directly from my Figma file. No screenshots. No copy-pasting hex codes into messages. The agent reads the actual Figma variables, checks them against committed tokens, and generates the CSS.

The first sessions were chaos. I'd ask it to update a token, and it would load 40 files, get overwhelmed, and invent variable names. I'd ask it to build a component, and it would reference documentation examples that didn't match the actual generated output. The fix wasn't better prompts. It was better front-end architecture.

I wrote a file called CONTEXT.md, which is a retrieval router. For each type of task, it tells the agent exactly which files to load and which to ignore. Pulling a Figma spec? Load the design-to-token skill and the Figma workflow rules. Adding a semantic token? Load the token files and naming conventions. Building a component? Load the component skill and the component tokens. Nothing else.

That one file — a routing table for context — turned unpredictable sessions into reliable ones. I spent more time writing it than writing any prompt. it was a bit tedious since i love building process and getting right into things but it was totally the most valuable time spent because it meant I could trust the agent with the translation work and focus on the design work.

My folder names broke the agent. I'd organised procedures under .devin/workflows/. The platform convention changed to .devin/skills/. Thirty-eight references across twelve files pointed nowhere. The agent didn't complain — it just silently failed. A human would have figured it out. The agent needed every path to be exact. It taught me that in a token-driven system, naming isn't a label — it's a contract between the Figma spec and the generated code.

My documentation lied. Example token names in my docs showed --text-l-regular-size. The pipeline actually generated --text-xl-size. The agent treated the docs as the specification and wrote code against names that didn't exist. The generated CSS was fine. The docs were the bug. In a system built on communication between Figma and code, your documentation is the specification — not a summary of it.

While CONTEXT.md decides what to load, AGENTS.md decides how to behave. It defines the mission, the design signature, the canonical colour palette, the token architecture, the Tailwind v4 foundation rules, and the Figma MCP workflow. It also sets guardrails: the agent must never invent primitive values, never reverse the token flow, and never hardcode values in components.

The most important guardrail is source-of-truth precedence. When a Figma variable, a primitive JSON value, and a semantic alias all exist, the agent knows exactly which one wins. That single rule stops the agent from drifting when it sees conflicting examples across the repo.

Each workflow is documented as a Markdown skill in .devin/skills/. The agent reads the skill for the task, follows the steps, and checks the guardrails. Two skills run the whole pipeline: design-to-token for pulling Figma specs into tokens, and design-language-sync for propagating a change in docs/DESIGN.md through tokens, rules, and generated CSS.

There's also a WORKFLOWS.md for human operators. It has the exact prompt templates to paste into the agent chat, the one-way flow diagram, the trigger reference table, and a verification checklist. It stops you from accidentally breaking the source chain by asking the agent to edit theme.css directly.

The component-build skill turns a Figma component set into production components. The prop contract is identical across Vue, React, and React Native. The only thing that changes is the implementation layer: Tailwind v4 utilities for web, StyleSheet token objects for mobile. Every component ships all states — default, hover, focus, active, disabled, loading, error — plus an accessibility pass.

Every file has a role and a precedence. docs/DESIGN.md is human intent. tokens/primitives.json is the Figma export. tokens/semantic.json is intent. foundations/theme.css is generated. The agent maintains this structure; it must not scatter tokens or duplicate foundations elsewhere.

The foundations/theme.css file is generated from tokens/primitives.json and tokens/semantic.json. It exposes every colour step as a Tailwind v4 theme variable, with color-mix and var() references kept intact. No hand-editing. No drift.

Learn the vocabulary. Primitives and semantics aren't developer terms. They're design concepts expressed in a language code can comprehend. Understanding them didn't make me any more technical — it made my design decisions more precise and easier to communicate with the AI and other team members.

Architect the context before you prompt. A retrieval router, a naming convention, a typography system, accessibility rules, a one-way token flow, the constraints, and so on. These aren't configuration overhead. They're the front-end architecture that lets the AI agent do useful work instead of guessing.

AI doesn't replace your design thinking. It replaced the hours I spent typing #ff9500. It didn't replace the decision to make that orange the brand anchor. The intent — the brand identity, the patterns, the specifications — is still yours.

The real test of a design system is whether it can produce different surfaces without breaking. Harmony's tokens are designed to scale across three template families:

Editorial / portfolio sites — big Clash Grotesk titles, generous whitespace, media-rich sections. This is where the EM Mendoza brand lives: confident, gallery-like, story-driven.

Dashboards and admin tools — the same colour and spacing tokens become compact tables, controls, status chips, and data-dense cards. The neutral palette stays calm while the brand orange carries meaning.

Mobile apps — React Native with the same props and token objects, not CSS variables. Touch-first, compact density, identical brand expression.

The target audience isn't one industry. It's any organisation that leads with a strong visual voice: fintech needing trust, creative & event brands needing expression, public sector needing accessibility, and cultural organisations needing bold, gallery-like presence. The token layer stays the same; the templates change.

This VELO-NOIR e-commerce kit is an example of what the Harmony workflow can produce when context is treated as architecture. I used the same primitives, semantic tokens, and component patterns described in this article — primitives, semantic, component tokens, the one-way Figma-to-code flow, and the agentic context from CONTEXT.md and AGENTS.md — to describe the intent in plain language. The agent then generated a cohesive set of pages: landing, product detail, collection, editorial, contact, and checkout components. No hardcoded values, no drift between Figma and code. The same token source produced the dark palette, the spacing rhythm, the type scale, and the reusable card and form patterns.

The process followed the same three skills described earlier: design-to-token to extract Figma variables, design-language-sync to propagate changes across tokens and docs, and component-build to turn the Figma component set into React/Next.js markup. The result is a production-ready direction that a developer can hand off or extend without reverse-engineering the design.

Agentic context engineering is just one step. I want to dive deeper into AI and machine learning — to become also a multifaceted data scientist, but to understand how data analysis can inform design decisions, how machine learning can detect token drift or accessibility regressions, and how these disciplines feed back into the kind of front-end architecture I've been building. I don't have all the answers yet, but I'm actively pursuing them.

Harmony is in progress. The foundation is live. Next: building the full template cases from Figma into production React and React Native, with Code Connect mapping every Figma component to its code source. If you want to see more of how I work — or other experiments like this one — visit my about page or the playground.