$ ~/registry/skill/openclaw-agents-skills-control-ui-e2e

SKILL

control-ui-e2e

Name: control-ui-e2e
Author: openclaw

Build, debug, and extend end-to-end tests for the OpenClaw Control UI.

Stars

★ 382,582

Source

GitHub

Updated

2026-07-11

// securityLow risk

Prompt only, no code
Open source
Community-trusted· 377.5k

Summary

This skill material is essentially prompt/documentation for local E2E testing of the OpenClaw Control UI, with no declared secrets or remote endpoints, and it comes from an auditable open-source GitHub repository with very high community adoption. Overall risk is low; the main caveat is that it describes local test processes, browser automation, and local artifact writes as part of the test workflow, not as standalone red flags.

CredentialsLow risk

The material explicitly states that no keys or environment variables are required, and the README further advises against using real provider keys, channel credentials, or a real Gateway; there is no indication of collecting, storing, or exfiltrating sensitive credentials.

Network egressLow risk

No remote hosts/endpoints are declared; the documentation describes a local Vite UI, mocked Gateway WebSocket flows, and local browser-based validation, with no factual sign of sending user data to unknown or unrelated external services.

Code executionLow risk

The system flags this as prompt-only; although the README includes local test commands involving node, pnpm, Vitest, and Playwright, these are developer-facing test instructions and do not mean the skill itself has built-in execution privileges or implicit code-running capability.

Data accessLow risk

The documentation mentions writing screenshots and videos to a local `.artifacts/control-ui-e2e/...` directory, but it does not declare broad access to sensitive local data, system-level resources, or permissions beyond what is normally needed for GUI testing.

Supply chainLow risk

The source is an open-source GitHub repository, and the system marks it as open-source with extremely high community adoption (about 377k stars), which materially improves auditability and trustworthiness; the undeclared license and unknown maintenance status are minor uncertainties, but not enough on their own to constitute a high-risk red flag.

Recommendations

Continue preferring mocked Gateway flows and local test data, and avoid using real credentials or production environments in E2E scenarios.
If you actually run the README commands, do so in an isolated development environment and review lockfiles and install scripts.
Keep screenshots, videos, and other test artifacts in local temporary directories and avoid accidentally committing or broadly sharing them.
Verify the repository license and recent maintenance activity to improve supply-chain and compliance assurance.

Audited by: gpt-5.4 · 2026-06-16

// install

Copy the install command and let the AI configure it · recommended for beginners

Please install the "control-ui-e2e" skill from askskill:
1. Download https://raw.githubusercontent.com/openclaw/openclaw/main/.agents/skills/control-ui-e2e/SKILL.md
2. Save it as ~/.claude/skills/control-ui-e2e/SKILL.md
3. Reload skills and tell me it's ready

// download

Download SKILL.mdInstall manifest ↗

// examples

Write UI end-to-end tests

Prompt

Please write Vitest + Playwright end-to-end tests for the OpenClaw Control UI login, dashboard load, and task start flow, including required mocks, wait conditions, and assertions.

Expected

Runnable end-to-end test code covering key interactions, state checks, and stability handling.

Mock WebSocket and dashboard flows

Prompt

Help me build mocked Gateway WebSocket flows for the OpenClaw Control UI, simulating connected, running, completed, and unexpected disconnect scenarios, and add the matching tests.

Expected

A test implementation with event simulation that verifies UI behavior across real-time state changes.

Generate screenshots and browser-verifiable proof

Prompt

Please extend the existing OpenClaw Control UI Playwright tests to automatically save screenshots and videos on failure, and produce browser-execution proof notes that an agent can verify.

Expected

An enhanced test setup and code including screenshot/video configuration and verifiable execution result notes.

// docs

Control UI E2E

Use this for Control UI changes that need a real browser flow with deterministic Gateway data.

Test Shape

Use ui/src/**/*.e2e.test.ts for full GUI flows.
Use ui/src/test-helpers/control-ui-e2e.ts to start the Vite Control UI and install a mocked Gateway WebSocket.
Keep scenarios deterministic. Do not use live provider keys, real channel credentials, or a real Gateway unless the user explicitly asks for live proof.
Prefer existing .browser.test.ts or unit tests for narrow rendering logic; use this E2E lane when the proof should cover routing, app boot, Gateway handshake, requests, and visible UI behavior together.

Commands

Target one E2E test in a Codex worktree:

node scripts/run-vitest.mjs run --config test/vitest/vitest.ui-e2e.config.ts --configLoader runner ui/src/ui/e2e/chat-flow.e2e.test.ts

Run the whole local lane in a normal checkout:

pnpm test:ui:e2e

If dependencies are missing in a Codex worktree, install once with pnpm install; for broad GUI proof or dependency-heavy checks, use Testbox/Crabbox instead of running a wide local pnpm lane.

Visual Proof Default

When running mocked Control UI/dashboard validation for a user-facing feature, produce visual proof by default unless the user explicitly opts out.

Keep the Vitest E2E assertions deterministic; do not commit generated screenshots or videos.
After or alongside the focused E2E test, run the mocked Control UI app when available, for example pnpm dev:ui:mock -- --port <port>.
Drive Chromium with Playwright against the local mock URL and capture a video plus screenshots for each meaningful state: initial view, interaction input, result state, and final/paginated/selected state.
Use browser.newContext({ recordVideo: { dir, size }, viewport }), page.screenshot({ path }), and close the context before reporting the video path.
Put artifacts under .artifacts/control-ui-e2e/<short-feature-name>/ or another clearly named local temp directory, and report the absolute paths in the final answer.
Treat recording as validation, not only demo capture. If the recorder fails or shows surprising behavior, stop, fix the behavior, add or update a regression test, then rerecord.
If visual proof is blocked, state the exact blocker and still report the textual E2E evidence.

Mock Pattern

Start the app server, install the mock before page.goto, then assert both Gateway traffic and visible UI:

const server = await startControlUiE2eServer();
const page = await context.newPage();
const gateway = await installMockGateway(page, {
  historyMessages: [{ role: "assistant", content: [{ type: "text", text: "Ready." }] }],
});

await page.goto(`${server.baseUrl}chat`);
await page.locator(".agent-chat__composer-combobox textarea").fill("hello");
await page.getByRole("button", { name: "Send message" }).click();

const request = await gateway.waitForRequest("chat.send");
await gateway.emitChatFinal({ runId: String(request.params.idempotencyKey), text: "Done." });
await page.getByText("Done.").waitFor();

Extend installMockGateway with typed scenario options or method responses when a new flow needs more Gateway surface.

Standalone Recording

When recording an already-running mocked Control UI URL, use a temporary Playwright script or playwright test spec and keep the recording flow focused:

Open the mock URL, interact through stable data-* selectors or user-facing role selectors, and wait on asserted states instead of relying on fixed sleeps.
Assert both visible UI state and mocked Gateway traffic for request-driven flows. For example, verify the expected count/row is visible and that sessions.list was called with the expected search, offset, and limit.
Use short sleeps only after assertions to make the captured video readable.
Store the generated video under .artifacts/control-ui-e2e/<feature>/; do not commit it.