SportsMeet app
A vibe-coded mobile app, and a playground for an Agentic Design System
SportsMeet is a side-project I’m building with Lionel. He’s leading the product while I’m focusing on making the experience better and on building the Design System that keeps the product consistent as it grows. A Design System built 100% with AI agents and readable by them.
Role
Partner
Tools
Design system lead for Era · UX for SportsMeet
Lionel Sellam, co-founder: product and engineering
Figma · Tokens Studio · Style Dictionary · Expo / React Native · Claude Code + Figma MCP
Era is the design system behind SportsMeet. It's written for two readers: designers, and the AI agents that now write much of the app's code. It wasn't designed on a blank canvas: it was retrofitted onto a live app, with AI agents doing much of the work and checks making sure they stay on-system. This page shows the workflow, step by step: what the AI did, what I did, and what each step left behind.
Era doesn't have one source of truth. Each layer has the source that fits it, and the repo decides what's valid.
Layer
Source
Components
Code: behaviour, states, accessibility
Icons
Code: icon package
Token names and rules
The repo's token contract, checked on every change
Tokens values
Figma
Audit
Before changing anything, an agent compares Figma and the code and ranks what's inconsistent. naming-audit from Design System Ops found 13 naming problems; the riskiest, "Secondary" meaning two different things, had already caused three dark-mode bugs. Typography started the same way: 682 texts counted, 504 with a hard-coded size.
AI: ran the audit and the counts · Me: chose what to fix first · Left behind: a dated audit report
Decide
Every structural choice is mine, written down as a decision record, so people and agents can read the why. The naming audit became a token contract the same day: one vocabulary from Figma to code.
For hard calls, grill-with-docs from Matt Pocock's skills has the agent question my decision against the project's docs until it holds up.
AI: drafted options and challenged them · Me: decided · Left behind: decision records (the token contract, the source of truth by layer)
Draft in Figma
Through the Figma MCP, AI can create variables, text styles and components directly in the Era file, with the appropriate Era tokens already bound to them.
But I don't let it run unchecked.
The AI can create and iterate. I review, edit and approve the result in Figma before anything reaches code. That distinction is important to me. I'm not trying to remove the designer from the process. I'm trying to move the designer towards the decisions where human judgement matters most.
AI: built the drafts in Figma · Me: reviewed each one before anything reached code · Left behind: the Era Figma file
Review
I approve, reject or redirect each draft. I review at fixed checkpoints in each plan, not only in Figma. A dark-mode fix that looked obvious, lightening the grouped-page background, would have pushed brand and danger icons below 3:1 contrast on 13 screens; I kept the page colour and added a new fill token instead.
AI: built each area and listed what it couldn't verify · Me: checked it on a device, then approved, rejected or redirected · Left behind: signed-off checkpoints in each plan
Generate
Nothing generated is edited by hand. Token values go from Figma to the repo, where a check rejects any token without a description or a code name; today every token passes. Icons and components go the other way, from code to Figma. Illustrations are drawn in Figma and generated into components.
AI: ran the pipeline and the generators · Me: approved each diff · Left behind: one generated token list that docs, lint rules and agents all read
Migrate
Old patterns leave the code area by area, shared components first, each checked on a simulator in English and French. Large migrations start with planning-and-task-breakdown by Addy Osmani: icons took 28 tasks, typography 25. Colours are in progress, with 91 hard-coded values left.
AI: migrated each area to plan · Me: checked it on a device and approved every commit · Left behind: the warning count, falling
Guard
A rule in a doc is a request: an agent can read it and ignore it. In Era the key rules run on every change, and the message names what to use instead. Typography went from 591 off-role texts to 0, and the rule now blocks merges. An unknown or misused colour token also blocks; hard-coded colours still warn until their count reaches 0. Checks need checking too: once, a config change silently turned the hex-colour check off (123 warnings to 0) while lint still passed.
Accessibility is enforced the same way. A 14 September audit found dark icons below 3:1 contrast and icons that didn't grow with text size; both became rules:
Every icon colour reaches 3:1 in both themes, no icon is under 16pt, and status text passes 4.5:1 on the page and on its tint.
An icon-only button without a screen-reader label fails the type check. Every migrated area is also checked with VoiceOver, TalkBack and the largest text size.
AI: wrote code, hit the rule, fixed it · Me: wrote the rules and the exceptions, 20 for typography, each with its reason · Left behind: checks that run on every change
Documentation, in progress
Documentation is the part of Era I'm building now. It's written for two readers, and the agent is the stricter one: it reads exactly what's there and nothing else. What exists today is small and precise:
Every token says what it's for. Each one carries a "use for" description and its code name, and a check fails any token that doesn't. Today all of them pass.
One guide to the naming rules, which points to the generated token list instead of copying it, so it can't go stale.
Decisions are recorded with the options I rejected and why, so an agent doesn't reopen a settled question.
Procedures are skills. Adding a token, from the Figma name to the final check, is one skill an agent follows step by step.
What's next, and how I'll know it works
Era will tell an agent when to use something, not just what exists: component docs that state intent, small rule files loaded only where an agent is working, and content rules for the text agents write.
Then the test that matters: five fixed UI tasks given to an agent, with the checks counting how often it goes off-system. Run once as a baseline, then after each of these lands. If one doesn't lower the count, it isn't working.