Builder.io open-sources /visual-edit: a Figma-style visual editing canvas for local apps

The Builder.io team has open-sourced the core Skill "/visual-edit" in its Agent-Native system, which the official description calls 100% free and open-source. Its surface description is very intuitive: put a running local app into a Figma-style infinite canvas, letting users visually view pages and change styles. But what truly defines this product form is the next step—visual changes on the canvas are handed back to a coding agent to write back into the source code, rather than the canvas directly changing code.

This split is not an implementation detail, but the skeleton of the entire Skill. Changes the user makes on the canvas accumulate into a pending batch and are never written directly to source code; the agent uses get-visual-edit-pending to retrieve the pending changes, write them into the source code, HMR automatically refreshes the canvas, and after confirmation the batch is closed. In other words, the canvas is responsible for "expressing intent," and the agent is responsible for "putting pen to paper as code," with a batch that must be explicitly confirmed separating the two.

If the canvas were only static screenshots, then "visual editing" would degenerate into drawing boxes on an image, and after making changes you'd still have to rely on your brain to translate them into code. The source emphasizes that each screen on the canvas is a live route page rather than a static screenshot, so what you see is always the real state. This is the key difference from traditional design-spec annotation tools: what you face is a page rendered by a running dev server, not a snapshot at some point in time.

The invocation method is also designed around this point: call open-visual-edit and pass in routes (such as /, /pricing) and viewports (desktop, mobile, etc.), and it will create the canvas, arrange the screens, and return a link. By default the canvas lays out 3 to 7 screens, arranged in a grid of one frame per route × per viewport. Besides normal pages, the canvas proactively includes URL-addressable states such as empty states, loading, errors, and modals; unless the user explicitly requests a full audit, the canvas does not spread out all routes.

There is an easily overlooked constraint here: before use, you need to ensure the dev server is running, and a server started by the agent itself must use AUTH_DISABLED=1 to avoid treating the login page as the target. This shows that the canvas's authenticity depends on a running local environment, not an artifact that can be packaged offline.

Separating "visual editing" and "writing source code" has the most direct benefit of making the security boundary statable. The boundaries listed by the source include: canvas edits are always pending proposals, and modifying code goes only through the single path of the coding agent; structural modifications (reordering, .map() lists, shared components) are rejected from direct writing and must be handled by the agent; writing local files requires the user to manually click a consent popup, the agent cannot self-authorize, and sensitive files such as .env are always excluded.

The sharing scenario is also handled separately: a share link only renders a sanitized snapshot, and visitors cannot touch the user's localhost. Login-free availability relies on one-time short-lived credentials rather than an account session, while account-level saving and sharing still require login. These constraints together point to one judgment: the designer of this Skill does not treat "letting users change whatever they want" as the selling point, but treats "who, under what conditions, has the right to change which layer" as the core question.

It should be noted that the above boundaries all come from the source's statements and are source_claim, with no first-party repository documentation or third-party verification yet.

The access methods given by the source degrade by priority: MCP App (canvas and conversation side by side), hosted MCP connector, browser WebMCP. In addition, browser controllers capable of executing JS, such as Playwright and CDP, can also be used directly without installing anything.

This degradation chain itself reveals an orientation: prioritize putting the canvas and conversation in the same interface, and only then access through a hosted connector or a browser-side protocol. But the source does not explain the specific availability status or limitations of the hosted MCP connector and WebMCP, so this path can currently only serve as a directional description and cannot be treated as a list of already-available capabilities.

The evidence strength must be made clear. All functional details come from a single X post (including paraphrase and official promotional language), with no first-party repository documentation or third-party verification. The X post was published on 2026-10-01 and shows 65 views. The open-source repository address appears in the source only in the form of the short link t.co/kt6cxDipvo and github.com/BuilderIO/skil…, with no complete verifiable link provided.

Expressions in the source such as "Figma-level visual editing," "works with any agent or model," and "multiplayer collaboration" are official promotion, and the source gives no specific verification. The source also does not explain the Skill's release date, version number, or supported tech stack range, and provides no quantitative metrics such as performance, accuracy, or user numbers. Therefore, all functional descriptions in this article should be read as source_claim, not confirmed facts.