I build the repos our teams use to design with AI

The problem

Designers were prototyping in Figma and their own separate repos. Each one worked fine on its own. But every new idea started from scratch, and nobody could pick up someone else's prototype and keep going.

There were no rules for how to structure a repo, contribute, review, or check quality. We had plenty of prototypes and nothing that added up.

I wanted one place where the work could build on itself.

My role

I tested the idea with a few experiments, then proposed the repo and built it myself. I worked with my design manager on requirements, and we set the roadmap together.

I made most of the architecture and implementation calls. When an internal tool already did part of the job well, I plugged it in instead of rebuilding it.

I still own the repo: the architecture, how people contribute, the quality checks, and the roadmap.

One required repo, not another optional tool

The main call was to put all of the team's prototyping in one governed repo instead of adding another optional tool.

That meant deciding a lot more than folder names. I designed:

• The folder structure
• The branching model
• Pull requests and approvals
• How designers contribute and update shared work
• How the repo gets distributed and maintained
• Which internal tools to integrate rather than rebuild
• How prototypes move toward engineering handoff
• Which automated checks protect quality

Now designers build on each other's work instead of redoing it, and PMs and engineers work in the same place.

How it connects

The repo doesn't try to do everything itself. It holds our shared context and rules, and connects to the MCPs, agents, knowledge bases, repos, and internal tools we already had.

You start with a design or product goal. The repo applies our guidance, pulls in the right tools, and produces a prototype or reusable piece of design. Then it goes through review, evals, and handoff.

I'm using generic names because the internal systems aren't public.

How people contribute

A whole team can only rely on a repo if there's a clear way to change it. So I set up how people use it, change it, and trust it.

Contributors work in branches and open pull requests. Approvals protect shared work. Automated checks cover:

• Evaluations
• Design-token compliance
• Content quality
• Accessibility

An AI prototype that renders isn't automatically good. The checks hold it to the same bar as the rest of our design work.

Getting the team ready

Designers had to work differently, too. Before the wider release, I trained the team on VS Code, GitHub, GitHub Copilot, branches, and pull requests.

That's what made the switch work. I didn't just hand people a repo and tell them to use it. They'd already picked up the basics before anyone asked them to contribute.

This was part of a bigger AI training effort across the design org, which I cover in its own case study.

What's next: engineering handoff

Right now I'm working on getting prototype decisions into development more cleanly. Designers and engineers are trying out reusable components, Storybook, versions, guided runs, and more structured backlog items that come straight from the repo.

This is still in progress. The repo fixed the scattered-prototype problem. Once more people used it, the next gap was obvious: the path from design to engineering.

What I learned

I think the biggest lesson is that adoption starts before launch. The structure, the contribution process, the checks, and the training all mattered because they gave people a reliable way to take part. Building the repo was only part of the work.