Flow-Next Drive

The flow-next-drive skill drives any UI surface the way a real user would - a web app, a Chromium-backed desktop app (Electron / Windows WebView2), or a genuinely native app (macOS AppKit/SwiftUI, or a webview exposing no CDP), driven via the Cua Driver (MIT, provider-agnostic, background) / Computer Use, with a Cua Sandbox rung for headless/CI native runs. It detects the surface, picks the highest available driver on a ladder, and degrades gracefully when a richer driver is absent.

It is a router, not a single driver. The default rung - Vercel’s agent-browser CLI - is the only driver assumed present; every other rung is detected and optional. A pass succeeds with whatever the environment actually has: most cloud VMs, Linux, and CI have no Computer Use, so it is never a hard dependency and never on a headless/no-display path.

The full ladder (surface detection, the universal flow, the web rungs, the native rung with its install and permission steps, and how it degrades) is in Live-app QA & driving UIs.

When to use it

Verifying a deployed UI change matches the spec.
Driving or testing a web app, an Electron / WebView2 desktop app, or a native desktop app.
Reading documentation that has no clean text version.
Capturing baseline screenshots before a redesign.
Logging into a service and pulling structured data.
Light e2e probes that do not warrant a full test framework.

It orchestrates drivers - it does not reimplement them. The full native-desktop QA workflow (scenario authoring, bug filing, verdict) is a downstream /flow-next:qa concern; this skill provides the driver/actuation + the surface conditional.

Dynamic usage

Recipes that compose with drive in the cookbook:

Evidence-first - drive is how QA captures live-app evidence instead of narrating it.
Integration tricks - the surface-detection ladder works for your own automation prompts, not just QA.

Driver ladder and universal-flow structure inspired by Ray Fernando’s running-bug-review-board skill (Apache-2.0).