agentleFS
Sign inStart free
conscientiousnessconscientiousness/herdr-pstack-orchestrator/skills/control-ui/SKILL.md

control-ui

Skill1 starsChanged 16 days agoMITView on GitHub

Build or adapt a local browser/CDP harness to drive and inspect a web, IDE, or Electron UI. Use for local UI verification, screenshots, accessibility snapshots, perf profiles, visual diffs, or reproducing UI bugs.

We split this skill into the rules it gives an agent

16 rules. 0 are common, 15 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 16 edited versions we read keep these.

  • 15

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use local browser automation to verify UI behavior with evidence.

    line 8
  2. Distinctive:

    Start the app locally using the repo's documented dev command.

    line 20
  3. Very specific:

    Prefer accessibility roles, labels, and stable data-* selectors over coordinates.

    line 25
  4. Distinctive:

    Use the repo's installed browser tooling when possible.

    line 29
  5. Distinctive:

    Do not add Playwright as a project dependency just for this probe unless the user asks.

    line 42
  6. Distinctive:

    Verify the expected state change.

    line 81
  7. Distinctive:

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

    line 86
  8. Distinctive:

    When multiple app windows/tabs share a debug port:

    line 96
  9. Distinctive:

    Prefer a positive marker for the surface under test, such as an app root selector.

    line 98
  10. Distinctive:

    Use a negative marker to avoid the wrong surface when necessary.

    line 99
  11. Distinctive:

    If no page matches, list available page titles and URLs instead of guessing.

    line 100
  12. Distinctive:

    Do not rely on stale element references after navigation or structural changes.

    line 104
  13. Distinctive:

    Avoid coordinate clicks unless a fresh screenshot was captured immediately before the click.

    line 105
  14. Distinctive:

    Keep test data local and disposable.

    line 106
  15. Distinctive:

    Do not store screenshots or heap snapshots from privacy-sensitive workspaces unless the user explicitly agrees.

    line 107
  16. Distinctive:

    Do not hard-code selectors, ports, or script paths from another repository.

    line 108

“Common” is measured: kept by at least 6 in 10 of the 16 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free