Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
cursor avatar

Control Ui

  • 1.3k installs
  • 2.5k repo stars
  • Updated August 5, 2026
  • cursor/plugins

control-ui is a Cursor plugin skill that builds or adapts a local browser or CDP harness to drive, inspect, and verify web, IDE, or Electron UIs with evidence.

About

control-ui is a Cursor plugins skill for building or adapting a local browser or Chrome DevTools Protocol harness to drive and inspect web, IDE, or Electron UIs. It reuses existing Playwright, browser, or Electron harnesses when present; otherwise it assembles a temporary harness around a dev server or Chromium debug port. Developers use control-ui to reproduce UI bugs involving focus, keyboard input, scrolling, and rendering, and to verify visual or accessibility changes with screenshots, a11y snapshots, perf profiles, and visual diffs. Reach for control-ui when chat-only verification is insufficient and browser evidence is required.

  • Visual panels for agent job control
  • Start, pause, and inspect runs in UI
  • Surfaces status beyond chat transcripts
  • Improves operator steering of plugins
  • Pairs UI with agent runtime hooks

Control Ui by the numbers

  • 1,269 all-time installs (skills.sh)
  • +203 installs in the week ending Aug 5, 2026 (Skillselion tracking)
  • Ranked #317 of 2,245 Frontend Development skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/cursor/plugins --skill control-ui

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs1.3k
repo stars2.5k
Last updatedAugust 5, 2026
Repositorycursor/plugins

How do you verify UI bugs with browser automation evidence?

Give operators a visual control surface in Cursor plugins to start, pause, inspect, and steer agent jobs instead of relying only on chat transcripts and opaque background runs.

Who is it for?

Cursor plugin authors or frontend engineers who need browser-driven UI verification with screenshots, a11y snapshots, or perf evidence.

Skip if: Pure API backend work with no UI surface or teams that already maintain a complete Playwright CI suite covering the same scenarios.

When should I use this skill?

A UI bug needs browser reproduction, visual diff verification, accessibility snapshots, or perf profiling via local CDP or Playwright harness.

What you get

Local browser or CDP harness, UI reproduction scripts, screenshots, accessibility snapshots, and perf profiles

  • Browser automation harness
  • Screenshots and a11y snapshots
  • UI reproduction scripts

Files

SKILL.mdMarkdownGitHub ↗

Control UI

Use local browser automation to verify UI behavior with evidence. First reuse the repo's own Playwright, browser, or Electron harness if it exists; otherwise assemble a temporary local harness around the app's dev server or Chromium debug port.

What It Is Used For

  • Reproducing UI bugs that depend on real browser focus, keyboard input, scrolling, resizing, or rendering.
  • Verifying visual or accessibility changes with screenshots and snapshots.
  • Checking local web, IDE, or Electron behavior before shipping.
  • Capturing console logs, network logs, CPU profiles, traces, or heap snapshots.
  • Creating before/after evidence for verify-this.

Setup Pattern

1. Start the app locally using the repo's documented dev command. 2. Discover existing local harnesses: Playwright tests, Cypress specs, Storybook, browser scripts, Electron launch scripts, or snapshot tools. 3. For a web app, connect to the local URL with the existing browser tooling. 4. For Electron/Chromium, enable a remote debugging port when supported. 5. Select the correct page by stable app markers, not by tab order alone. 6. Prefer accessibility roles, labels, and stable data-* selectors over coordinates.

Generic Web Harness

Use the repo's installed browser tooling when possible. If the repo already has Playwright, a minimal one-off probe looks like:

import { chromium } from "playwright";

const browser = await chromium.launch();
const page = await browser.newPage({ viewport: { width: 1280, height: 800 } });
await page.goto("http://127.0.0.1:<port>");
await page.getByRole("button", { name: /submit/i }).click();
await page.screenshot({ path: "/tmp/ui-harness-after.png", fullPage: true });
await browser.close();

Do not add Playwright as a project dependency just for this probe unless the user asks. Prefer existing dev dependencies or external browser tools already available in the environment.

Generic CDP Harness

For Electron or a Chromium app launched with --remote-debugging-port=<port>, connect over CDP:

import { chromium } from "playwright";

const browser = await chromium.connectOverCDP("http://127.0.0.1:<debug-port>");
const pages = browser.contexts().flatMap((context) => context.pages());
let page;
for (const candidate of pages) {
  if (await candidate.locator("<app-root-selector>").count()) {
    page = candidate;
    break;
  }
}

if (!page) {
  console.log(await Promise.all(pages.map(async (p) => ({
    title: await p.title(),
    url: p.url(),
  }))));
  throw new Error("No matching app page found");
}

await page.screenshot({ path: "/tmp/ui-harness-cdp.png", fullPage: true });
await browser.close();

Replace <app-root-selector> with a stable marker from the current repo, such as a root app node, landmark, or product-specific data-* attribute.

Interaction Loop

1. Capture a page snapshot or screenshot before acting. 2. Choose a target from the latest page structure. 3. Perform exactly one structural action: click, type, keypress, drag, scroll, navigate, or resize. 4. Capture a fresh snapshot/screenshot. 5. Verify the expected state change. 6. Save artifacts for before/after comparisons when the user asked for proof.

CDP Capabilities

Use raw CDP only when higher-level browser APIs are insufficient:

  • Performance: CPU profiles, traces, paint flashing, FPS meter, layout shift inspection.
  • Memory: heap snapshots and forced GC for leak investigations.
  • Network: request blocking, throttling, cache disablement, request/response logs.
  • Rendering: viewport changes, color scheme emulation, reduced motion, accessibility checks.
  • Debugging: console streaming, exception capture, DOM snapshots.

Page Selection

When multiple app windows/tabs share a debug port:

  • Prefer a positive marker for the surface under test, such as an app root selector.
  • Use a negative marker to avoid the wrong surface when necessary.
  • If no page matches, list available page titles and URLs instead of guessing.

Guardrails

  • Do not rely on stale element references after navigation or structural changes.
  • Avoid coordinate clicks unless a fresh screenshot was captured immediately before the click.
  • Keep test data local and disposable.
  • Do not store screenshots or heap snapshots from privacy-sensitive workspaces unless the user explicitly agrees.
  • Do not hard-code selectors, ports, or script paths from another repository. Discover the current repo's local app markers.
  • Clean up dev servers, debug sessions, and temp profiles when done.

Related skills

FAQ

What does control-ui use to verify UI behavior?

control-ui uses local browser automation via Playwright, Chromium CDP, or Electron harnesses to drive UIs, capture screenshots, accessibility snapshots, perf profiles, and visual diffs for evidence-based verification.

When should you use control-ui in Cursor plugins?

Use control-ui when UI bugs depend on real browser focus, keyboard input, or rendering and chat-only inspection is insufficient—especially for visual, accessibility, or perf verification before release.

Frontend Developmentagentsautomation

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.