qa

# Visual QA Validation Use the Chrome DevTools MCP in standalone Codex only when the user configured it. Otherwise use native/manual browser screenshots and accessibility checks; if no visual capture path exists, report visual QA unavailable rather than claiming it ran. cc-settings does not auto-run unpinned registry MCP packages in Codex. Claude frontmatter does not enforce read-only behavior in Codex, so keep this workflow read-only through native tools or a read-only agent prompt. ## Core Philosophy - **Screenshot first, then critique.** Always look at the actual rendered output, not just the code. - **Be specific.** "The spacing looks off" is useless. "The gap between the heading and paragraph is 32px but should be 16px based on the surrounding spacing rhythm" is useful. - **Prioritize impact.** Not every pixel matters. Focus on what users will actually notice. - **Reference the intent.** Compare against design tokens, mockups, or stated design goals. ## Quick Start The Chrome DevTools MCP exposes browser automation as tool calls. Typical sequence: 1. `mcp__chrome-devtools__navigate_page` (type: "url", url: "http://localhost:3000") — load the page 2. `mcp__chrome-devtools__take_snapshot` — text-based a11y tree with element `uid`s (cheap, preferred first step) 3. `mcp__chrome-devtools__take_screenshot` — visual capture for review 4. Interact via `click` / `fill` / `hover` / `press_key` using the `uid`s from the snapshot --- ## Review Categories (Priority Order) ##...