user-behavior-qa
User Behavior QA
Review the product from the user's side. Treat the browser as the product boundary: use visible controls, navigation, forms, feedback, and persisted results. Do not inspect source code, internal APIs, database clients, server logs, or implementation details unless the user explicitly expands the scope. The browser console is fair evidence (see §4).
1. Intake
Before the first browser action, read what the repo says about running and opening the app (AGENTS.md / CLAUDE.md and the rule files they index, the README) and its domain or user docs for the area in scope. They give the dev URL, the product terms to use in the report, and which gaps are deliberate.
Defaults, unless the developer or the repo docs say otherwise:
- Target: the local dev URL — the worktree's own when testing a branch.
- Mutations: create, edit and delete test data on local dev. Any other environment, or an unclear one, is read-only.
- Browser: pages behind auth need the user's own signed-in browser (e.g. Claude in Chrome), since entering credentials is not an agent's to do. Public pages can use a standalone automation browser (agent-browser, Playwright). When the user is watching, say which one you intend to use and let them redirect you.
Only ask about what is still missing, in one message: the pages, workflows, entities, variants (platforms, engines, plans) and roles in scope, and the expected behavior or baseline. If the invocation already covers these, do not ask. State the test charter in one sentence and start.