Verify UI Changes in a Real Browser (agent-browser)
Proves a UI change works by driving a real browser, checking console and network, and returning a PASS/FAIL report with evidence.
Before & after
Same prompt, same agent — the only difference is the skill.
I can test the checkout flow for you manually. I'd navigate through the steps, fill in the form fields, submit payment information, and check if the confirmation page appears and the order gets recorded. That would take me a bit of time to do step-by-step, and I'd need to see screenshots to show you the results. I could also write test automation for you if you wanted, though that would take longer. Do you have a staging link I can use to test?
CHECKOUT FLOW VERIFICATION — AUTOMATED BROWSER TEST TEST SETUP App: staging.example.com/checkout Browser: Chromium Viewport: 1280x800 (desktop) Timeout: 30s per step TEST SCRIPT EXECUTION 1. Navigate to checkout → PASS (loaded in 1.2s) 2. Enter email: testuser@example.com → PASS 3. Click "Confirm Email" button → PASS (redirected to shipping) 4. Enter address: 123 Oak St, Portland, OR 97214 → PASS (autocomplete worked) 5. Select shipping: Standard (5-7 days) → PASS (price updated to 12.00) 6. Click "Continue to Payment" → PASS (reached Stripe form) 7. Enter card: 4242424242424242, 12/26, CVC 123 → PASS (Stripe injected, no errors) 8. Enter name: Test User → PASS 9. Click "Pay Now" button → PASS (processing spinner appeared) 10. Wait for confirmation → PASS (redirected to /order-confirmation?id=ord_xyz123) 11. Verify confirmation page shows: Order number, total ($89.99), delivery date → PASS 12. Open DevTools, check Network tab → PASS (POST to /api/orders returned 201) 13. Check database: Order created with status=processing → PASS RESULT: PASS (all 13 steps completed, no errors) PERFORMANCE • Total flow time: 8.3s • Stripe form load: 2.1s • Payment processing: 1.8s • Post-payment redirect: 0.4s SCREENSHOTS CAPTURED • email-form: Form state after email entry • shipping-form: Address form with autocomplete expanded • payment-form: Stripe form mounted and ready • confirmation-page: Order confirmation page with order details • network-log: POST /api/orders response (201, order_id in payload) RECOMMENDATION: Flow is production-ready. One minor UX note: "Continue to Payment" button could be more visible (currently gray, blends into form). Consider brightening CTA for higher click-through.
About this skill
"It works on my end" is what your coding agent says right before you open the page and the button does nothing. Agents call features done from code review, click once, see no error, and report success while the dev server is serving a stale build or the save never reached the API. This skill makes Claude prove the change works in a real browser and show you the evidence.
What it does
- Turns "check that it works" into specific pass criteria taken from the diff or bug report before any clicking starts
- Drives the flow with the agent-browser CLI using accessibility snapshots and element refs, and re-snapshots after every page change so stale refs never cause false results
- Catches the common false passes: a stale dev server, optimistic UI that never persisted, a 200 response with an error body, and console errors hidden in existing noise
- Records a console baseline on the untouched page first, so new errors are separated from old ones
- Reproduces a bug before fixing it, then reruns the identical steps afterward to confirm the fix
- Refuses mutating actions (payments, emails, deletes) against production unless you explicitly approve
What you get
A verification report with the exact steps run, each assertion marked observed or not, console and network evidence, screenshot paths, and a PASS, FAIL, or INCONCLUSIVE verdict. If no browser is available, you get a ready-to-run command script instead of a guessed result.
Best for
Developers using Claude Code or other coding agents to build frontend features who want the agent to verify its own work in a rendered page before reporting it done.
SKILL.md preview
---
name: verify-ui-changes-agent-browser
description: Verifies that a UI change or bug fix actually works by driving a real browser (the agent-browser CLI when it is installed, otherwise Playwright or whatever browser tool the session really has), checking pass criteria taken from the request or diff, and returning a PASS/FAIL/INCONCLUSIVE/NOT RUN report with evidence. Use when the user says "check it actually works in the browser", "verify the checkout change", "reproduce this UI bug", "click through the signup flow", "you said it was fixed but the button still does nothing", "my agent keeps saying done when the page is broken", or "test this on mobile width".
---
… (sign up to view the full skill)More development skills
View all Development skills →React and Next.js Regression Test Coverage
Generate React and Next.js tests with Jest, Testing Library, MSW, and Playwright, prioritized by regression risk.
Playwright E2E Tests and Flake Repair
Build reliable Playwright tests, repair flakes from evidence, migrate suites, and configure faster, diagnosable CI.
Pre-Ship Verification for Code Changes
Before calling a code change done, Claude grades every claim by evidence, tries to break it, and reports what's verified vs assumed.
TestRail Case and CI Result Sync
Sync automated tests to TestRail cases and scoped runs with stable mappings, retry handling, and verified result counts.