Prototype a desktop automation app, operator UI first.

The split nobody draws

A desktop automation tool is two products glued together. One is an operator console: dashboard, workflow builder, run history, schedule editor, credentials, action library, console output. The other is an engine: code that opens apps, clicks buttons, reads files, watches events on whatever operating system you target. Most teams blend them and disappear into engine work for a month before showing anyone a UI. By then the operator workflow is wrong, but the engine is half-built around the wrong workflow, and you start over.

The cheap move is to build the operator console as a clickable mock first, watch a real operator try to use it, and only commit to engine work once the workflow shape stops shifting. mk0r is good at this because the prototype is real React running in a real Vite project, not a Figma stack. You can wire mock data to mock state, click around like a real app, and the agent will iterate the surface in plain English while the operator watches over your shoulder.

What goes in the operator console

Six surfaces show up on every desktop automation tool worth shipping. None of them need an engine to render. All of them need to be argued about with real users.

The desktop default, in one line of source

Most AI app makers default to a phone frame because they were built around mobile prototyping. That makes a desktop automation tool look like a toy. mk0r is the inverse. The preview iframe defaults to unconstrained desktop viewport. Here is the file that decides it.

// src/components/phone-preview.tsx (excerpt)
export type DeviceMode = "desktop" | "mobile";

const DEVICE_SIZE: Record<DeviceMode, { w: number; h: number } | null> = {
  desktop: null,                  // <-- unconstrained viewport
  mobile: { w: 390, h: 844 },     // opt-in via DeviceSwitcher
};

export function AppPreview({
  /* ... */
  deviceMode = "desktop",         // <-- desktop is the default
}: AppPreviewProps) { /* ... */ }

A null device size means the iframe is not boxed; it spans the panel. So the workflow builder has room. The run history table has columns that fit. The schedule editor opens at the size a real user will see it. The phone frame is one click away if you want a mobile companion view, but it is not the default. That single null is one of the few places in the file system where a one-character change would turn the product into a different one.

Four steps from sentence to clickable console

Total wall-clock from the first sentence to a stakeholder-clickable URL is usually under ten minutes for the first draft, plus however long the iteration loop runs. The agent verifies its own work in a headed Chromium session inside the sandbox before the preview repaints, so you rarely see a broken intermediate state.

Be specific about what you can and cannot ship

The honest list. The first one is what the prototype delivers. The second one is what stays out of reach until you wrap it in a native runtime.

The strange recursion: mk0r runs desktop automation to verify your prototype

The sandbox the agent works inside is itself a desktop automation environment. The Dockerfile at docker/e2b/e2b.Dockerfile installs Xvfb (virtual frame buffer for headless X11), x11vnc, websockify, headed Chromium, and @playwright/mcp@0.0.70 as an MCP server. After every file write, the agent can drive that headed browser through Playwright, take a real DOM snapshot, capture console messages, and read it all back. If a required panel is missing or an error renders, it patches the code and runs the check again before your preview repaints.

That is real desktop automation, just at a layer most builders never expose. You are using a tool that does desktop GUI automation against a virtual frame buffer to design a tool that will eventually do desktop GUI automation against your operating system. Different abstractions, same primitive. Useful to know when you start writing the engine, because the mental model carries over.

The handoff: prototype to engine

When the operator UI stops being the unknown, the prototype has done its job. Five steps move you from a sandbox preview to a desktop binary an engine team can ship.

The React code does not care. Tauri ships a roughly 600 KB binary that wraps a system webview. Electron is heavier (about 80 MB) but ships with a known Chromium. Both let you reuse the prototype code unchanged and bridge to native automation through IPC. Pick on size, license, and platform support, not on whether the prototype survives the move (it does, in either case).

One concrete first prompt

If you want a starting point that consistently produces a useful first draft, paste this verbatim into mk0r and iterate from there:

A desktop control panel for a workflow automation tool.
Left sidebar: searchable list of saved workflows, plus a "New workflow" button.
Main area: node-based workflow builder with trigger / action / condition / output blocks, drag to connect, edit a node by clicking it.
Right sidebar: last 10 runs with status pill (success, failed, running), duration, and timestamp; clicking a run opens a slide-over with the streaming log.
Top bar: workflow name, run-now button, schedule editor (modal with cron picker), and a kill-switch.
Style: clean, generous whitespace, one teal accent, no emojis, no rounded card grid; every panel takes up the full available height.

That prompt is opinionated on purpose. It names the surfaces, names the interaction style, and forbids the generic-AI default of every panel being a uniform rounded card with an emoji. Iterate from there: rip out the node graph and ask for a YAML editor instead, replace the sidebar with a tab bar, swap the modal schedule for an inline editor in the top bar. mk0r will hold the rest of the layout still while it changes the one thing.

Frequently asked questions