control-ui
Skill2 starsChanged 46 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.
19 other projects use a version of this, 6 of them edited.
Adopted by
Most recently taken up by
- paramcodes/skillsedited, first seen Nov 8, 2026
- ArchitektApx/cursor-skills-for-claudeedited, first seen Nov 1, 2026
- AnastasiyaW/codex-claude-code-configtheir own version, first seen Oct 30, 2026
- conscientiousness/herdr-pstack-orchestratoredited, first seen Oct 20, 2026
- ngcto/oh-my-pstacktheir own version, first seen Oct 20, 2026
- OpenClawAndroid/openclaw-android-assistanttheir own version, first seen Oct 17, 2026
Used with
Projects with it also use discord-e2e, openclaw-repair-sweep and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
molt-botSkilldiscord-e2e
Test Discord with Convex-leased QA bots: check credentials without a Gateway, exercise owned messages, or prove OpenClaw replies, files, threads, reactions, streaming, and typing. Distinguish API and Gateway evidence from manual user interactions.
Also in 10 projects that use this
molt-botSkillopenclaw-repair-sweep
Run scoped OpenClaw issue/PR repair campaigns: coordinate workers, prove root causes, and land or close verified work under the requested authority.
Also in 10 projects that use this
clawdbotSkillopenclaw-performance
Performance work in OpenClaw: a slow or heavy flow (latency, CPU, memory, SQL, RPC, renders), writing or reviewing a perf PR, or adding a cache. Count the work, delete waste first, cache last.
Also in 7 projects that use this
clawdbotSkillplugin-sdk-impact
Count Plugin SDK consumers across live ClawHub releases and bundled OpenClaw plugins before deprecation, removal, or behavior changes; supports public release-date filters.
Also in 7 projects that use this
supermansuper563-opsSkillauto-qa
Continuously audit, live-test, and stress-test the current OpenClaw codebase across at least ten independently scoped subsystem lanes; default to 100 independently verified, landed root-cause fixes, maintain an evidence-backed report, and announce each merged pull request immediately. Use for OpenClaw-wide autonomous QA, live-provider campaigns, gateway, CLI, web, plugin, native-app, scenario, packaging, and extended soak testing.
Also in 10 projects that use this
clawsoulsSkillchannel-message-flows
Use when running QA Lab channel message flow evidence.
Also in 10 projects that use this
- +2 more from molt-bot
Other versions19 projects use a version of this.
Word for word · 0
None found.
Edited · 6
- anis-dr/skills★ 394% same
- conscientiousness/herdr-pstack-orchestrator★ 298% same
- ElyzeSolutions/skills★ 198% same
- khgouldy/skills★ 120% same
- ArchitektApx/cursor-skills-for-claude★ 098% same
- paramcodes/skills★ 080% same
Wrote their own version · 13
- moltbot/clawdbot★ 394ksame name
- steipete/warelay★ 394ksame name
- steipete/clawdis★ 394ksame name
- moltbot/moltbot★ 394ksame name
- clawdbot/clawdbot★ 394ksame name
- openclaw/openclaw★ 394ksame name
- molt-bot/clawdbot★ 391ksame name
- friuns2/openclaw-android-assistant★ 573same name
- OpenClawAndroid/openclaw-android-assistant★ 556same name
- AnastasiyaW/claude-code-config★ 214same name
3 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository29 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- architectSkill
- arenaSkill
- automate-meSkill
- blast-radiusSkill
- broSkill
- control-cliSkill
- create-verification-skillSkill
- deslopSkill
- figure-it-outSkill
- howSkill
- interrogateSkill
- maintain-verification-skillSkill
- make-bot-uiSkill
- no-commentsSkill
- poteto-modeSkill
- recallSkill
- reflectSkill
- setup-pstackSkill
- show-me-your-workSkill
- swarmSkill
- tddSkill
- teachSkill
- technical-writingSkill
- typescript-best-practicesSkill
- unslopSkill
- verify-pstackSkill
- verify-thisSkill
- whySkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
16 rules. 0 are common, 14 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 19 edited versions we read keep these.
14
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Use local browser automation to verify UI behavior with evidence.
- Distinctive: line 20
Start the app locally using the repo's documented dev command.
- Very specific: line 25
Prefer accessibility roles, labels, and stable data-* selectors over coordinates.
- Very specific: line 29
Use the repo's installed browser tooling when possible.
- Distinctive: line 42
Do not add Playwright as a project dependency just for this probe unless the user asks.
- Distinctive: line 81
Verify the expected state change.
- Distinctive: line 86
Use raw CDP only when higher-level browser APIs are insufficient:
- Distinctive: line 96
When multiple app windows/tabs share a debug port:
- Distinctive: line 98
Prefer a positive marker for the surface under test, such as an app root selector.
- Distinctive: line 99
Use a negative marker to avoid the wrong surface when necessary.
- Distinctive: line 100
If no page matches, list available page titles and URLs instead of guessing.
- Distinctive: line 104
Do not rely on stale element references after navigation or structural changes.
- Distinctive: line 105
Avoid coordinate clicks unless a fresh screenshot was captured immediately before the click.
- Distinctive: line 106
Keep test data local and disposable.
- Distinctive: line 107
Do not store screenshots or heap snapshots from privacy-sensitive workspaces unless the user explicitly agrees.
- Distinctive: line 108
Do not hard-code selectors, ports, or script paths from another repository.
“Common” is measured: kept by at least 6 in 10 of the 19 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.
Files
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
- Start the app locally using the repo's documented dev command.
- Discover existing local harnesses: Playwright tests, Cypress specs, Storybook, browser scripts, Electron launch scripts, or snapshot tools.
- For a web app, connect to the local URL with the existing browser tooling.
- For Electron/Chromium, enable a remote debugging port when supported.
- Select the correct page by stable app markers, not by tab order alone.
- Prefer accessibility roles, labels, and stable
data-*selectors over coordinates.
Generic Web Harness
Use the repo's installed browser tooling when possible. The probes below write screenshots to <scratchpad>, the scratchpad directory the system prompt names. 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: "<scratchpad>/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: "<scratchpad>/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
- Capture a page snapshot or screenshot before acting.
- Choose a target from the latest page structure.
- Perform exactly one structural action: click, type, keypress, drag, scroll, navigate, or resize.
- Capture a fresh snapshot/screenshot.
- Verify the expected state change.
- 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.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
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.

