browser-qa

I drive a real browser through the flow and I do not call it done until I watched it work. Every step gets a screenshot, the full run gets a recording, API-triggering actions get a network check, and I read the console for new errors. A change headed for a PR also runs the same flow on the base code, so the PR shows before next to after.

Driver priority

1. When t3-code_preview_snapshot is in the tool list, I use the T3 preview tools only. I open with t3-code_preview_open, go to the URL with t3-code_preview_navigate, then loop t3-code_preview_snapshot followed by t3-code_preview_click or t3-code_preview_type. I re-snapshot before every interaction because refs go stale. I keep open=true so the user sees the run.
2. Else, when Playwright MCP browser_navigate exists, I use the Playwright flow unchanged.
3. Else, I use the agent-browser CLI (open, snapshot -i, click @eN, fill @eN). I report any evidence the CLI cannot produce as missing, never assume it.

Playwright to T3 mapping: browser_navigate becomes t3-code_preview_navigate, browser_snapshot becomes t3-code_preview_snapshot, browser_click becomes t3-code_preview_click, browser_type becomes t3-code_preview_type, browser_press becomes t3-code_preview_press, browser_wait_for becomes t3-code_preview_wait_for. Screenshots come from t3-code_preview_snapshot with save=true, which returns a screenshotPath to move into .qa/.

Recording

I record every test flow run, not just the screenshots. On T3 I bracket the flow with t3-code_preview_recording_start before the first step and t3-code_preview_recording_stop after the last one, which saves a local evidence artifact. On the agent-browser CLI I bracket with record start <head repository root>/.qa/<flow-name>.webm, given as an absolute path, and record stop, because its daemon resolves a relative path against its own working directory and the recording fails to save. Playwright MCP has no video tool, so there the screenshot sequence is the record and I report video as unavailable, never faked.

Record at minimum 1920x1080, and hold 30 fps minimum on drivers that expose frame-rate control. On T3 I set the viewport with t3-code_preview_resize to at least that size before recording starts. On the CLI the recording keeps the size the page had at record start (observed on agent-browser 0.31.1), so I run set viewport 1920 1080 before it. After record stop I still check the artifact dimensions and report when the file misses the floor instead of claiming it. Neither driver exposes a frame-rate control, so I take the recorder default and report it when the file lands.

Before and after

When the run verifies a change headed for a PR, as done runs it before publishing, I load ${CLAUDE_SKILL_DIR}/references/before-after.md before Step 1. It picks where the before side runs, fixes what both sides share, and holds the .qa/pr-evidence.md template. A UI change runs the flow on both sides. An API change runs, on the before side, only the cases whose expected response the change alters, and reports them in the Changed behavior table below. The before side's server is its own origin, so those cases need their own origin approval under the endpoint rules below. A run with no PR ahead of it, such as a user asking to click through a flow, skips this section.