Design new screens with your agent on your own design system, and review them on a Lens
Evidence status: Capability pattern grounded in current Oddlynew HTML page documents, Lenses, files, documents, comments and the agent's own code tools. It is not presented as a customer testimonial.
Who this is for
Designers, product people and engineers who already work with coding agents, and teams that want new screens and flows to start from their real design system instead of static frames that someone redraws in code later.
Outcome
You describe a screen or a flow. Your agent builds it as real HTML from your current design system, its tokens, components and patterns, and puts the result on a Lens next to the brief and the alternatives. You click through it on a laptop or a phone, say what to change, and the agent revises. What the team decided lives in documents, so the next screen starts from it.
The working pattern
Point the agent at your design system. Your agent reads the current system where it lives: your repository, with its own code tools, or documents in your organization that hold your tokens, components and rules. Write in the organization's AGENTS.md where the system lives and which rules a new screen must follow.
Write the brief as a document. What the screen is for, who uses it, what it must show, and the constraints. The brief is the record; the mockups are views of it (Choose a document, an HTML page or a Lens).
Let the agent build mockups as HTML pages. Each mockup is one HTML page document: a self-contained file with the design system's styles built in, so it looks like your product. Scripts inside the file make it clickable, so a flow can be tried, not only looked at (HTML pages: a whole HTML file as a document).
Lay them out on a Lens. The agent places the mockups as cards at desktop or phone size, side by side for alternatives, labels each with what it tries, and puts the brief beside them (Work on a Lens). Open any card to click through it.
Review and revise. Say what to change, or comment on the brief. The agent writes the decision into the brief and replaces the mockup with a new version; the history keeps every earlier one.
Hand it to code. The chosen mockup is already HTML built from your system, so your coding agent implements it from the same components in your repository.
Useful connections and plugins
Code tools in your agent: read the design system in your repository and implement the chosen screen.
Browser and screenshot tools in your agent: check a mockup at phone and desktop size before it goes on the Lens.
Image tools: for placeholder imagery, uploaded into the file.
Design tools your team already uses: a design file can be the source the agent reads from; the review happens on the Lens.
Availability depends on your client.
A good first task
Ask your connected agent: "Read our design system from [the repository path or our design system documents] and summarize the tokens and components a new screen must use. Then write a brief for [the screen] as a document, build three different mockups of it as HTML page documents using only our system, and lay them out on a Lens with the brief, each labeled with what it tries. Tell me which one you would pick and why."
Boundaries
The file holds its own styles. An HTML page cannot load your live stylesheet or fonts from outside; external resources are blocked. The agent reads the current system each time and builds it into the file, so rebuild a mockup when the system changes.
Mockups are views, not the record. Decisions, copy and requirements live in the brief and the documents it links. A comment cannot anchor inside an HTML page yet, so discuss on the brief.
It shows the screen, not production. A mockup uses invented or copied data and does not run your backend.
Everyone in the organization sees the Lens. Keep unreleased work for a smaller group in its own organization.
Why it compounds
Every review leaves a decision in the brief and in the design system's rules, not only a better picture. The next screen starts from your real system and from what the team already decided, and any agent your team uses, in design or in code, reads the same documents.