Browser Inspect

Purpose

An agent editing UI code cannot confirm that the result is correct by reading source files alone. CSS can be purged or overridden, client-side JS only runs in the browser, and server-rendered markup may differ from what the template suggests. Without looking at the live page, an agent is guessing. This skill codifies how to inspect, interact with, and verify rendered web UI using two complementary tools that serve different purposes.

Procedure

1. Tool selection

Two tools exist for browser work. They are not interchangeable — the distinction is which browser instance you connect to.

• agent-browser: Spins up its own fresh session. Use for autonomous tasks: testing, form automation, screenshots, clean-state QA.
• Chrome DevTools MCP: Attaches to the user's live browser. Use for collaborative debugging: inspecting existing state, auth sessions, HMR.

agent-browser is a free CLI tool — harness-agnostic, works everywhere, no API key:

npm install -g agent-browser
agent-browser install   # downloads Chrome for Testing (first time only)

Verify it before use: run command -v agent-browser. If it is missing, show the user the two install commands above and stop. Installing a global npm package and downloading a browser are system changes — the user runs them or explicitly approves them first. Once installed, continue.

Always use --engine chrome. Lightpanda has no rendering engine and cannot display visual output.

Chrome DevTools MCP is an MCP server — requires registration in the harness's MCP config. If the MCP server is not available, ask the user to add it to opencode.json (project) or ~/.config/opencode/opencode.json (global):

{
  "mcp": {
    "chrome-devtools": {
      "type": "local",
      "command": ["npx", "-y", "chrome-devtools-mcp@latest"]
    }
  }
}

The harness must be restarted after adding the config. The MCP server starts Chrome automatically on first tool use.

When to use which:

• agent-browser for clean-state verification: "does this component render correctly from scratch?" Fresh context, no cookies, no auth, no prior state. Good for automated testing loops and screenshots.
• Chrome DevTools MCP for live-state debugging: "why does this look wrong in my browser right now?" Inherits the user's session — auth, localStorage, cookies, in-flight HMR state. The user and agent see the same tab simultaneously. Returns structured CDP responses directly, fewer round-trips for tight debugging loops.

Default to agent-browser for autonomous work. Switch to Chrome DevTools MCP when the user asks you to inspect something they're already looking at, or when reproducing the bug requires state that's hard to reconstruct.

2. The verification loop

After every UI change, run this cycle:

1. Edit the source file(s).
2. Rebuild / let the watcher handle it.
3. Server reloads and serves at localhost:<port>.
4. Inspect the rendered result (CSS, console, DOM state).
5. Interact with the component (click, fill, navigate).
6. Read the screenshot to visually confirm. Fix issues, repeat.

Never assume a component is correct without looking at it in the browser.

3. Inspection with agent-browser

CSS. Check whether classes are actually applied to rendered elements:

agent-browser get styles "h1"
agent-browser get styles "@e3"          # use refs from a prior snapshot

Diagnose: missing classes (purged or misspelled), specificity conflicts, responsive breakpoint issues, or dynamic classes that weren't generated.

Console errors. After any UI change, always check for runtime errors:

agent-browser console                   # view console logs
agent-browser errors                    # view page errors only

Network traffic. When the UI makes server requests, inspect them:

agent-browser network requests          # list captured requests

DOM state. Evaluate client-side state via JS when the framework exposes it:

agent-browser eval "document.title"
agent-browser eval "document.querySelectorAll('.my-class').length"