ux-audit

# UX Audit Audit an **existing, rendered** page against a fixed rubric and return findings the caller can act on. The discipline that makes this useful: **audit what's actually on screen, cite the heuristic or success criterion, and propose a concrete fix.** A finding with no location and no fix is noise; a "problem" you assumed without observing the page is worse. This is distinct from neighbours: - **design-council** deliberates *one* high-stakes design decision (preserves dissent). Use it for "should we restructure this flow?", not "audit these 12 pages." - **webapp-testing** checks that features *work*. UX audit checks whether they're *usable and accessible* even when they work. ## Inputs you need - The page(s): a URL, a local file, or a running dev server. For a *series* of pages, the `ux-auditor` agent fans out — one auditor per page (see that agent). - The page's **goal** — what is the user there to do? You can't judge usability without it. If not given, infer it from the page and state your assumption in the finding set. - Viewports to check (at least one mobile ~375px and one desktop ~1280px). Responsive problems only show up if you actually resize. ## Render the page first — don't audit blind Audit the rendered DOM and the visual result, not the raw source. Use whatever browser driver is installed (prefer `agent-browser`, fall back to `playwright-cli`; the CLI binary is `playwright-cli`, **not** `playwright`): ```bash # preference order — use whiche...