browser-capabilitylisted

# Wiring a browser so "done" is proven against the running UI Some done-criteria can't be asserted from code. "The dashboard renders," "the sign-in flow reaches the account page," "the layout doesn't break on mobile" - a passing unit test doesn't show any of these. Proving them means driving a real browser against the running app and observing what a user would see. When a work item's contract carries a criterion like that and the agent has no browser to drive, the gap is a missing *tool*, not a missing line of code. This skill is one concrete instance of a general practice: on a capability gap, source the tool rather than hand-roll it. Needing a browser for web QA is the same shape as needing an on-device iOS harness for a mobile app (`/ios-capability` is that instance) or a load generator for a perf check - name the gap, source a tool that fills it, vet it, and wire a small how-to so the loop can run the check. The practice ships; the specific tool stays swappable. Read `.better-dev/overrides.md` first. A repo often already settles this - it may pin Playwright, a `test:e2e` script, or a particular browser skill for the job. Honor that and skip straight to wiring the check; don't source a second tool alongside one the project already runs. ## 1. Name the browser gap as an observable check Write the missing capability as the check it has to pass, in the running app's terms: "loads `/dashboard` on the dev server and the account name is visible," "screenshots the checkout