菜单
Built-in browser automation and E2E verification workflow. Use for Claude /wf-browser, Codex $wf-browser or /skills wf-browser, Browser Use, Playwright, Chrome DevTools/CDP, screenshots, forms, UI verification, and browser-visible acceptance.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Codex compatibility: use $wf-help or /skills wf-help in Codex to show the Harness WF command table. Claude Code and OpenCode use the direct /wf-help command.
Use for /wf-max in Claude Code, $wf-max or /skills wf-max in Codex. WF-MAX is explicit only — the user must type /wf-max, $wf-max, or /skills wf-max.
Use when work needs bounded subagent coordination, parallel read-only exploration, independent review gates, broad context partitioning, or controlled handoffs.
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
Source-backed CLI invocation guide for Claude Code, Codex, and OpenCode automation. Use when invoking peer CLIs, writing batch tests, collecting cache telemetry, debugging command-line flags, or documenting cross-runtime agent usage for Harness workflows.
Perpetual adaptive auto-optimization mode. Selects probes from project evidence instead of a fixed angle count. Inherits WF acceptance gates and subagent orchestration per cycle. Use for Claude /wf-auto, Codex $wf-auto. Explicit only — the user must type /wf-auto, $wf-auto, or /skills wf-auto.
| name | wf-browser |
| description | Built-in browser automation and E2E verification workflow. Use for Claude /wf-browser, Codex $wf-browser or /skills wf-browser, Browser Use, Playwright, Chrome DevTools/CDP, screenshots, forms, UI verification, and browser-visible acceptance. |
This skill is the single Browser E2E entry. Do not use or create a separate
browser E2E skill. The browser evidence contract lives here plus
Harness/specs/protocols/HARNESS_BRIDGE.md.
/wf-browser <task> or select the wf-browser skill.$wf-browser <task> or /skills then choose wf-browser./wf-browser <task>.CLAUDE.mdHarness/MEMORY.md index only per Memory PreflightHarness/README.mdHarness/specs/protocols/HARNESS_BRIDGE.mdbrowser-use skill when Browser Use is usedFollow Harness/specs/runtime/context-loading.md#Cache-First Context Contract: keep stable
workflow docs first, then append only the current URL, selectors, concise browser
state, screenshot paths, trace paths, and failing assertions. Do not paste full
accessibility trees, browser logs, screenshots, videos, or network dumps into
task state.
Every browser-visible claim needs real browser evidence:
data-testid and accessible labels/roles.No data-testid or stable accessible selector, no UI acceptance. No API
contract, no backend integration acceptance.
UI built for browser control must expose targetable, user-meaningful controls:
| Category | Required control surface |
|---|---|
| Inputs | <label> association or aria-label, data-testid, disabled/invalid states, deterministic placeholder only as fallback |
| Buttons | accessible name, data-testid, disabled/loading state, no icon-only button without aria-label |
| Filters | stable test id for input/menu/chip, selected state, clear/reset control |
| Rows/items | stable row/item test id plus durable item key such as data-row-id; avoid index-only targeting |
| Empty state | visible empty container with data-testid="empty-state" or feature-specific equivalent |
| Error state | inline error/toast/banner with stable test id and accessible role when appropriate |
| Loading state | stable spinner/skeleton/progress test id; verify duplicate submit prevention |
Required coverage targets: inputs, buttons, filters, rows, empty/error/loading states.
Selector priority:
data-testidDo not use generated class names, brittle CSS chains, XPath, DOM index selectors, or raw coordinates as the primary test contract. Coordinates are acceptable only after locating an element through the accessibility tree or when testing canvas or other non-DOM UI.
Use the current script-style Browser Use CLI; old browser-use open/state/click/screenshot/input/wait subcommands are removed from the current CLI and must not be used in new docs or tests.
Health check:
browser-use --doctor
browser-use skill
PowerShell smoke:
@'
new_tab("https://example.com")
wait_for_load()
print(page_info())
path = capture_screenshot("Harness/tasks/<task-id>/evidence/example.png")
print(path)
'@ | browser-use
Bash smoke:
browser-use <<'PY'
new_tab("https://example.com")
wait_for_load()
print(page_info())
path = capture_screenshot("Harness/tasks/<task-id>/evidence/example.png")
print(path)
PY
Useful helpers include new_tab(url), goto_url(url), page_info(),
capture_screenshot(path), click_at_xy(x, y), type_text(text),
fill_input(selector, text), press_key(key), scroll(x, y), js(code),
cdp(method, ...), wait_for_load(), wait_for_element(selector),
list_tabs(), switch_tab(target), and close_tab(target).
For local Chrome connection problems, run browser-use --doctor. If Chrome asks
to allow remote debugging, stop and ask the user to approve the browser prompt.
Prefer Playwright for repeatable E2E tests and Browser Use/CDP for exploratory or interactive checks.
import { test, expect } from "@playwright/test";
test("AC-001 user can submit the form", async ({ page }) => {
const requests: Array<{ url: string; method: string; postData: string | null }> = [];
page.on("request", request => {
requests.push({
url: request.url(),
method: request.method(),
postData: request.postData(),
});
});
await page.goto("/example");
await page.getByTestId("email-input").fill("test@example.com");
await page.getByRole("button", { name: "Submit" }).click();
await expect(page.getByTestId("loading-spinner")).toBeHidden();
await expect(page.getByTestId("result-row")).toBeVisible();
expect(requests.some(request => request.url.includes("/api/example"))).toBe(true);
});
data-testid on interactive elements.