Windmill Preview Workflow

Use this skill any time the user wants to see, open, navigate to, visualize, or preview a flow, script, or app, and any time you've just finished writing one and want to offer visual verification.

The Windmill dev page renders the flow graph / script editor, lets the user step through steps, and live-reloads on every save. It runs locally via wmill dev and is reached on a localhost port.

Two independent decisions

1. Mode: proxy or direct?

wmill dev runs in two modes; pick by asking what kind of URL whatever will display the preview needs.

• Proxy (--proxy-port <port>), exposes the dev page on http://localhost:<port>/. Use it when the embedder you'll hand the URL to only accepts localhost URLs (most in-IDE / in-chat preview embedders do, because they sandbox cross-origin loads).
• Direct (default), the user's browser loads the dev page from the remote workspace's HTTPS URL; the local wmill dev only runs the WebSocket back-channel for live reload. Use it when the URL will be opened in a regular browser tab.

Default to direct unless you have a specific embedder that needs localhost.

2. Who starts the server?

• You start it in the background. Spawn wmill dev … (or wmill app dev …) yourself, capture the URL it prints, do whatever's next (open a tab, hand the URL to an embedder).
• The runtime starts it from .claude/launch.json. Some runtimes (currently the Claude Desktop / Claude Code MCP preview integration, tools prefixed with mcp__Claude_Preview__) can read a launch.json configuration and launch the dev server on demand when you invoke their preview tool. Only take this path if you actually have such a tool, otherwise nothing reads the file and wmill dev never starts.

The two decisions compose. The common cases: