The interface, finally a file

Why does .gui exist?

AI has made software cheap to make. Anyone can describe an app and have one a minute later. But almost nobody has thought about the architecture underneath. Most AI-built interfaces are generated as HTML and code for one moment: hard to read, hard to change, and every regeneration piles more throwaway markup on top. As a way to keep interfaces, that isn't sustainable. The amount of garbage only grows.

And interfaces still have no open format of their own. They live inside proprietary design files, or get flattened into screenshots. Graphics got SVG; interfaces never got their equivalent. I wanted UI to be a file you can open, read, version, review and hand to an agent, and still render the same way years later.

Where did the idea come from?

From two places. Deck taught me file formats: eight years of writing PowerPoint's XML by hand, and reading how Sketch and Figma store a screen. And I have always loved the front end. I'm a big fan of how HTML and the W3C standards were designed, so I studied them closely: what made HTML universal, and what turned into baggage.

.gui keeps HTML's good parts: readable tags, nesting as containment, a file you can open in a text editor and understand, a shape every AI model already knows. It drops the rest: no head, no scripts, no DOM, no build step. The complexity lives in the renderer, not in the file.

I did a lot of exercises and testing before settling on that shape. The first decisions were the hardest ones: XML rather than JSON, not building on SVG, and not copying Figma's data model.

How does the format change?

Like a web standard, through RFCs. Every new tag, property or convention starts as a written proposal, is checked against the format's principles and earlier decisions, and is proven with real designs before it's accepted. Only then does the spec change, and the parser, renderer and kit follow from it. Rejected proposals stay on record, so the same ground isn't argued twice.

So far there are 56 RFCs: 42 accepted or implemented, 8 drafts, 4 rejected and 2 superseded. They're public in dotgui/core.

What is inside a .gui file?

A .gui file is a zip with three parts:

1. design.guix: an XML description of the interface.
2. assets/: images, icons and fonts.
3. preview.webp: a thumbnail any viewer can show.

What comes with it?

• Spec: v1.0 in dotgui/core, MIT licensed.
• @dotgui/kit: parser, validator, HTML renderer and quality scorer. No AI inside, on purpose.
• @dotgui/cli: lint, autofix, render and package. gui setup installs the .gui skill into Claude Code, Codex, Cursor and Gemini CLI. The CLI has no AI; your agent does the generating.
• Native renderer: Rust, compiled to WebAssembly, for PNG/PDF export and thumbnails.
• gui.farm: a public library of .gui screens, with an MCP server so AI agents can browse and contribute.
• Eval harness: real agents generate screens across styles, platforms and prompts, and each one is scored with lint, heuristics and an AI vision judge.
• Viewers: a web editor, a desktop app with macOS QuickLook, a VS Code extension and the <gui-embed> web component.

Where is it now?

.gui is an open, MIT-licensed spec at version 1.0, with the tools around it released as open source. It is still an experiment: the format is settling, and the RFC drafts show where it's heading next.

• Figma export: a plugin that saves any Figma selection as a .gui file is in review for the Figma Community.
• Round trip: pulling from and pushing back to Figma from the CLI is on the roadmap, so a design can move between Figma and an agent without losing fidelity.
• The library: gui.farm holds 185+ screens across web, iOS and Android, for people and agents to learn from.

How it started

1. May 2026Work starts on an open, text-based format for interfaces
2. 2026v1.0 spec, CLI, kit, embed and the Rust/WebAssembly renderer released as open source