Use when: Tester needs UI state evidence for VBR, or Builder needs to verify an integration wire is observable end-to-end. Powered by agent-browser MCP — token-efficient browser automation (200–400 tokens/page).
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
Token-efficient browser automation via the agent-browser MCP server. Provides Tester with evidence-grade UI verification and gives Builder a lightweight end-to-end integration check.
Tester: Load when the acceptance criteria include a visible UI state, a rendered page, a form interaction, or a URL that must be reachable. VBR for Tester requires observable evidence — a screenshot or captured text, not just a passing test suite.
Builder: Load when the ticket's end-to-end step requires confirming that a new integration wire produces observable output in a running app. Tests passing is not sufficient when the integration surface is a rendered page or API response visible in a browser.
Do not load for: unit tests, static file checks, pure API responses verified via curl/fetch, or any task where the acceptance criteria make no reference to UI state or browser-visible output.
Tester must satisfy at least one of these before reporting state:qa-passed:
"Tests pass" alone does not satisfy VBR when browser verification is available and the ACs reference UI state.
Preflight: Before using any mcp__agent-browser__* tool, confirm two things, not just one: (1) the server is present in .mcp.json and reachable, and (2) the current subagent's own tool grant (claude.tools in agent.manifest.json, or the equivalent tools: frontmatter) actually lists the specific mcp__agent-browser__* tool names needed. .mcp.json configuration makes the server reachable session-wide, but it does not by itself grant any subagent access to it — Claude Code's subagent tools: allowlist does not support a wildcard for MCP tools (individual restricted-content gates aside), so every tool name must be explicitly enumerated in the subagent's own manifest. If either check fails, fall back immediately to the When Browser Is Unavailable section below and report evidence quality in your verdict.
Windows cold-start hang — warm the daemon first (mandatory on Windows). On Windows the MCP server can wedge forever on the first call that has to start the browser daemon (typically agent_browser_open): the browser launches and the page loads, but the tool never returns, the tool's own timeoutMs is not honored, and every later call from that MCP server queues behind it. Cause: the detached daemon inherits the pipes the MCP server is reading, so the server never sees end-of-output (upstream bug, unfixed as of agent-browser 0.38.1: https://github.com/vercel-labs/agent-browser/issues/1407). Once the daemon is already running, MCP calls return in about a second. So, before the first mcp__agent-browser__* call in a session:
$(...), a pipe, or other output capture, which hang the same way): timeout 60 npx agent-browser open about:blank. If the MCP calls use a named session or namespace, pass the same --session/--namespace here.npx agent-browser open <url>, npx agent-browser screenshot <path>, npx agent-browser close) and record the fallback in your evidence.npx agent-browser close (matching session/namespace) also releases a stuck caller.Once both preflight conditions and the warm-up are met, the agent-browser MCP server exposes tools directly in the session. No npx invocation is needed for the tool calls themselves — tools are available as mcp__agent-browser__agent_browser_open, mcp__agent-browser__agent_browser_snapshot, mcp__agent-browser__agent_browser_screenshot, mcp__agent-browser__agent_browser_click, mcp__agent-browser__agent_browser_fill, mcp__agent-browser__agent_browser_get_text, etc. — see the full enumerated core-profile tool list in Tester's or Builder's agent.manifest.json.
Common operations:
agent-browser represents each page in 200–400 tokens — roughly 10–20× cheaper than raw Playwright output. This makes it viable to run a browser check on every QA pass without a significant context cost.
Keep browser sessions short: navigate → capture evidence → close. Do not leave sessions open across multiple tool calls.
The agent-browser MCP server is the default path for routine per-ticket VBR evidence on every adapter — this does not change. It is adapter-independent (our own MCP server, configured identically via .mcp.json on Claude Code, Codex, Cursor, and Copilot) and its 200–400 token/page cost is the reason the skill was standardised around it.
Two adapters ship a heavier native browser/screen-automation capability:
claude-in-chrome (native browser automation, full interactive control)computer-use (screen automation via ~/.codex/computer-use/config.json)Both are supplementary options, not replacements. Use them only when agent-browser genuinely cannot do the job:
agent-browser's text/screenshot extraction is insufficient — e.g. verifying a CSS animation, drag-and-drop flow, or canvas rendering that requires real browser interactivity.Do not treat these as general-purpose alternatives to agent-browser for routine QA evidence. The token-efficiency rationale for agent-browser applies on every ticket; the native tools are the exception.
If the MCP server is not running or not configured, fall back to:
curl for HTTP reachability checksVBR fallback rule: If the acceptance criteria explicitly require browser evidence (UI state, visual confirmation, form submission feedback, etc.), and only curl or static file fallbacks were used, report the result as BLOCKED — evidence is insufficient to satisfy VBR without observable UI state capture. Note the fallback method in the QA report and escalate to the team lead for manual verification.
Note the fallback method in the QA report so the team lead can assess evidence quality.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Universal guardrails loaded by every agent. Defines Verify Before Reporting (VBR), Write-Ahead Log (WAL), and the security baseline. Always-on, role-independent.
The English summary is being prepared. Showing the original description.
Use when: architecture mode, architect this, ADR, C4, PlantUML, system boundary, design decision, PRD gap, high ambiguity, multiple technical approaches, security architecture, data architecture, integration risk, implementability gap, story ticket, or epic ticket.
The English summary is being prepared. Showing the original description.
Use when: assumptions audit, audit assumptions, check for hidden assumptions, plan/ticket has ambiguous scope edges, pre-flight before finalizing a ticket, unstated assumptions, or 'what am I assuming'. Surfaces unstated assumptions, ambiguous scope edges, and untested preconditions in a finished plan/ticket/ADR before it is handed to Builder. Optional pass — Architect judges when to apply it; not a mandatory gate on every ticket.
The English summary is being prepared. Showing the original description.
Use when drafting a bug or defect ticket, reviewing one someone else wrote, or deciding whether a reported problem is ready to file. Keeps what the reporter actually saw separate from what the agent later found out, so a reader can tell which lines are testimony and which are collected proof. Trigger phrases: 'file a bug', 'write up this defect', 'triage this report', 'is this ticket ready to file', 'what did the reporter actually see'.
The English summary is being prepared. Showing the original description.
Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.
The English summary is being prepared. Showing the original description.
Writing skill for freelancers and independent consultants. Covers project proposals, bids, client emails, and scope summaries. Leads with the client's problem, not the consultant's background.
The English summary is being prepared. Showing the original description.