Browser acceptance testing

The user decides when a browser opens. If they asked for this skill, go ahead. In an unattended run the agent decides in their place: open it when the change has a user interface that the acceptance criteria describe, and log the choice as a Q- entry. If a browser tool fails, do not switch to another browser tool without asking; in an unattended run, log the switch as a Q- entry instead.

Setup

1. Start the app in an isolated environment with its own port and data (.scratchpad/<slug>/manual-env.sh). If the app has sign-in, create test accounts there; keep credentials in the helper, not in chat messages.
2. Choose the browser tool. Prefer the Chrome DevTools MCP. Load the browser tools you need before you start (navigate, snapshot, screenshot, click, fill, fill form, evaluate script, console messages, network requests, emulate, resize). If the environment has no DevTools MCP but has Playwright and a browser (common in containers and cloud sessions), write one script in .scratchpad/<slug>/scripts/ that drives the same checks. Record console messages, network status codes and screenshots in .scratchpad/<slug>/shots/. This is the tool choice, not a switch after a failure.
3. Look at a few screenshots yourself (desktop, 375 px, one error page). Layout problems such as wrong plurals, missing headings or cut text show there and not in status codes.
4. Keep notes in .scratchpad/<slug>/browser-test-notes.md while you test.

Test the criteria as a user

Walk through the acceptance criteria in the order a user meets them (for example: first visit, sign-in, lists, create, edit, delete). For each check:

• Use the UI like a person: fill the form, click the button. Use scripts only to read state or to type very long input.
• Confirm status codes in the network panel, not only what the page shows.
• Confirm data through the public API when the criterion talks about it.