Building a prototype in code has gotten fast enough that it’s often the quickest way to think. You wire up real components and real interactions, easing and all, and you have something running on localhost in an afternoon. That speed is the whole point.
The trouble starts the moment you need someone else’s eyes on it.
A live prototype is a great build artifact and a poor review artifact. A design lead can’t drop a comment on one specific state. An engineer can’t see the flow laid out end to end. A PM has a question about a screen buried three interactions deep, and the only way to answer it is to run the prototype again and try to land on the exact moment. The thing that makes a prototype good for building is the same thing that makes it hard to align on. It only exists in motion.
Amy Lima built a skill for exactly this, and she invited me over to Figma to get into it with her. The premise is simple: the canvas is good at the part the prototype is bad at. Flows sit still. You can see them next to each other and point at a single state to leave a note beside it. Her skill gets the prototype out of motion and onto the canvas without anyone redrawing it by hand.
What Amy’s skill does
The skill takes a running localhost prototype and rebuilds it inside Figma through the native MCP. Each interaction flow becomes its own frame. The frames are assembled from your design system components, not flattened screenshots. And every frame gets annotated with what’s happening: the state, the transition, and the implementation detail underneath.
You run it from your editor, point it at the Figma file you want it to write to, and let it work. A minute or two later, the flow that was trapped in a browser tab is sitting on the canvas as something a team can actually look at.
That part demos well. The part I kept reacting to on the show goes deeper.
The annotations are the actual product
I’ve argued for a while that for AI, declared documentation beats designed documentation. A description field or an annotation returns structured text an agent can read. A pretty frame on a canvas makes that same agent reconstruct meaning from a node tree and guess.
Amy’s skill is that idea pointed in one direction. The annotations it writes are interaction and implementation detail in plain text, pinned to the design. A design manager reads them to give feedback. A developer reads them to build the thing. And the next agent that opens the file reads them too, instead of inferring intent from layout.
What comes out is the intent behind the prototype, captured as text where it’s useful. Not a screenshot of it. Designer intent and developer intent land in the same place, in a form that survives the handoff.
I’ll be honest about one thing I admitted on camera: the annotation detail it produces is more than I’d write by hand on a normal day. That’s not a small point. The tedious documentation you skip when you’re busy is the documentation an agent needs most.
Parity falls out for free
There’s a quieter capability in the output. When the skill rebuilds the prototype from your design system, it flags anything that doesn’t map cleanly. Amy calls these design system gaps, though “gap” isn’t quite the right word. Sometimes they’re new components you invented while iterating, which makes them candidates to contribute back to the system rather than mistakes to clean up.
Either way, it surfaces the drift and leaves the call to you. You don’t click through the prototype screen by screen hunting for where code and design diverged. The skill puts the divergence on the table, and a human decides whether it gets resolved on the code side or the design side. Design-to-code parity as a byproduct of doing the main job. It’s the part I get most excited about, and it’s where Amy and I spent the back half of the conversation.
Make the agent check its own work
The first run wasn’t clean. Frames overlapped. The spatial awareness was off. Useful, but not something you’d hand to a stakeholder.
This is the part where I earned my guest spot. The fix I pushed for generalizes well past this one skill. You don’t nudge the agent by hand and move on. The overlap is a repeatable failure, so you address it at the source and edit the skill itself. On the show we added a step that runs after the agent thinks it’s finished: before it reports done, it takes another pass through the output, re-examines the frames, and confirms nothing overlaps.
That step exists because AI will tell you the job is finished when it isn’t. It’ll set everything up, declare success, pat itself on the back, and leave you to find the mess. The validation pass works because it forces the agent to look again instead of trusting its own first report. New observation, not self-congratulation.
If that sounds a little like an eval, you’re not wrong. It’s a cousin. A self-check fixes this one run at runtime. An eval measures how often the skill succeeds across many runs. Same criteria underneath, different jobs. I’ll save that for its own piece.
Go look at what Amy built
None of this is exotic. A skill is an instruction set in a markdown file, sometimes pointing to scripts that run. What makes this one worth your time is the judgment Amy baked into it. It encodes a workflow most teams re-explain every time, including the documentation you’d skip and the checks you’d forget.
Credit where it’s due. Amy created this skill and brought me on to refine it with her on camera. We published it to the Figma community together, but it started as her idea and it’s her work. Getting to be the guest who pokes at someone else’s good thinking is a pretty great way to spend an afternoon.
The prototype-to-figma skill is public. Fork it, point it at your own design system, and tighten it for the way your team works: https://github.com/alima-max/prototype-to-figma-skill
