You Can't Paste Taste

I learn design by taking it apart. I open an app I admire, walk through one of its flows, and try to work out why each step sits where it does. Mobbin is where I do that. It has the flows and screens of thousands of real apps, and for the work I do it is the reference I reach for most.

The trouble was that whatever I worked out there never made it out of my head.

I would study how Duolingo warms you up before it asks you to commit, or the way a good checkout holds off on account creation until you already want the thing in your cart. I understood it. Then I would sit down with an AI to build something, and I had no way to give it what I had learned. I could write a paragraph. I could paste a screenshot. Neither one carries the part that mattered.

A screenshot is a photograph of a decision

A flow on Mobbin is not really a set of images. It is a set of decisions. Which step comes first. What gets asked now and what waits. Where the primary button sits, what the empty state admits to, how much got cut so one goal stays in view. The decisions are the part worth studying. The pixels are just where they happen to land.

A screenshot keeps the pixels and drops the decisions. Paste three screens into a chat and the model gets three nice pictures with nothing connecting them. It cannot tell they are steps one, four, and seven of the same journey, or which control is the one that matters, or that the third screen exists only to calm someone down before they pay. So it fills the gaps with a guess. A guess off the surface is the exact thing I was trying to avoid by studying a real app instead of inventing one.

Everything else I build is already shareable

Mobbin sits behind a login, and there is no public API. As a person, that is fine. I sign in, I look, I learn. But it means the reference is stuck at the one point in my process I cannot hand off: me, sitting there, looking.

Everything else I make is already shareable. Code sits in a repo an agent can read. Notes are files. Decisions are in the commit history. The design reference, which does more to shape how a feature feels than most of that, was the one input locked inside my own attention. That was the bottleneck. The bottleneck was me.

I did not want a cleaner way to paste screenshots. I wanted the reference to live in the project the way the code already does.

Reverse-engineering is mostly writing down what I already do

So I wrote down what I do on Mobbin, step by boring step, and handed the boring parts to a tool.

I sign in with my own account. I search. I open a flow and read it in order. I clock the patterns and the individual pieces. I keep a link back to the source. I decide what is worth saving. Almost none of that needs me. A script can do it with my own session, on my own machine. The only step that does need me is deciding what matters.

That is what I built: a small local-first tool, a set of agent skills over an MCP server, that does the mechanical part and hands the judgment back to me. It runs on my login, keeps everything on the machine, and automates the reading I was already doing by hand.

None of this sits on solid ground. With no public API, the whole thing leans on internal endpoints, and those move. One of them disappeared a few weeks ago and I had to rebuild how cross-app search works. That is the tax on a tool like this: you keep it running yourself, and in return you get to close the gap.

Capture the structure, not the pixels

When I find a flow worth keeping, one command saves it into the project. What it saves is what a screenshot loses:

• the steps, in order, instead of a folder of images
• the screen and source URLs, so the path back to the original stays intact
• the pattern and hotspot data, so the main action is marked as the main action
• the individual elements, so "the card with the trust badges" is something the AI can point at
• a perceptual hash, when I want one, so later I can ask what else looks like this and get a real answer

Single screens and whole marketing-site sections work the same way. It all goes into a store that sits next to the repo, so the reference travels with the work instead of with me. A capture I made for a checkout redesign is still there three sessions later, still tagged, still explaining itself, and any agent I point at the project can read it. My taste did not move into the file. The structure my taste was reacting to did, and that turned out to be most of what I needed.

Adapt, don't copy

The piece I care about most is the one that will not let me copy.

Once an AI can see a reference cleanly, the lazy move is to clone it. That is a mistake. A reference flow is not a stencil. It is closer to a worked example, showing how a team that had done this before sequenced the steps, took out the friction, and kept the momentum up. The job is to lift that structure, leave their brand and domain and look behind, and rebuild it inside your own product and your own constraints. Clone the surface and you get a costume. Adapt the structure and you get something that belongs to the product you are shipping.

So the skill that sits on top is not "rebuild this screen." It runs a pipeline. Study the flow. Pull out what transfers. Take an honest look at where the project is today. Then write a flow spec and a task plan that fit this codebase, and if I sign off, build it. "Make our onboarding feel like Duolingo" turns into a spec, a plan, and a diff, with the reference cited the whole way down.

AI as a design partner

This is the shift I was after, and it is quieter than it sounds. My AI could always write the code. What it could not do was see my sources, so it was a strong builder working from a thin brief. Now the reference sits in the project as something it can read, and when we disagree about how a feature should feel, we are at least looking at the same thing.

That is the part of "partner" that was missing. I do not want to hand a machine a finished spec. I want one that studies what I study and pushes back. Writing the component was never the hard part. Building the right thing, for a reason you can name, is the job. Good reference, saved with its structure intact, is how you feed that.

Where to start

If you use Mobbin as much as I do, the setup is short:

npm install -g @aos-engineer/mobbin-mcp
mobbin-mcp auth
mobbin-mcp skills install

The install drops those skills into whatever agent you already run. From there you can search Mobbin, save a flow or a screen into your project with its structure intact, and hand the whole thing to an AI that can finally see what you were looking at.

It will not give the model your taste. Nothing will. But it keeps your taste from dying at the login screen, and that is the difference between an AI that guesses and one that works next to you.