qa · git:20260903.8420d55 · 2026-09-03 · sha256 cc8b5914357dcc0b
qa git:20260903.8420d55A
Immutable. This exact content is served forever at /api/v1/blob/cc8b5914357dcc0b.
--- name: qa description: Use when the user asks to run QA without fixing code, including mounted runtime behavior, visible user flows, browser-visible app execution, source-of-truth checks, action/state coverage, route/control inventories, Playwright control sweeps, or QA report generation in repositories. --- # (MUST) For Codex: When QA must use plugins - Browser - Control the in-app browser - Chrome - Control the user's real Chrome browser - Computer Use - Control Windows apps or installed artifacts when QA requires real app interaction outside a browser. - Playwright: use as an automation arm for browser actions, control sweeps, screenshots, videos, traces, and reports. - Backend/API tools: use HTTP clients (curl/fetch), database CLI tools, or test runners for non-UI scopes. # (MUST) For Claude or other agents: - Use the equivalent browser, Chrome/session, computer-control, or HTTP/database CLI capability exposed by that agent/runtime. # QA Runtime Review Use this skill to verify real runtime behavior from the user's point of view. QA is a no-fix role: inspect, execute, record, classify, and report. Do not repair product code, tests, specs, fixtures, or generated files during QA. ## Iron Laws - QA MUST NOT fix code. Report bugs, blockers, friction, test gaps, and suggested fix direction only. - Runtime behavior is the source of QA truth. Code presence, tests, screenshots, or graph output do not prove pass/fail by themselves. - Must have screenshot Evidence for UI scopes. For non-UI / Backend / Database scopes, follow `references/backend-qa-protocol.md` (structured payload, DB state diff, and execution logs). - Tests verify already-correct behavior. Tests do not define expected behavior and must not legitimize wrong UX. - Wrong tests are findings. A green test that encodes wrong behavior is not QA proof. - Do not skip steps. Every in-scope flow step matters equally. - Every in-scope surface, action, state, data path, and blocker needs an explicit verdict or out-of-scope mark. - An incomplete inventory or action ledger means QA is incomplete. - If a blocker prevents downstream verification, downstream scope is `Blocked`, not passed. - For final visible QA, open the real built website, runtime, or generated app artifact the same way a user would open it, in a visible browser or app window on the user's physical PC. Headless, hidden, source-only, test-only, or screenshot-only execution cannot approve final visible QA. - QA must run on the real, officially built application (actual Electron artifact or release binary). - For UI/visible scopes: Every action (clicking buttons, entering data, changing state) must capture clear PNG screenshots saved sequentially into the `screenshots/` directory. - For UI/visible scopes: Visually inspect each captured image / visual artifact to detect UI and behavioral defects; never rely solely on in-code assertions or generated `.json`/`.md` summary files. - Never accept a UI QA report lacking the actual screenshot evidence set for each interaction. For Backend / non-UI reports, require structured HTTP status, response payload, and DB state diff evidence per `references/backend-qa-protocol.md`. ## Source Of Expected Behavior Use the first available applicable authority, in this order: 1. User's explicit QA scope and no-fix instruction. 2. Repository rules such as `AGENTS.md`. 3. Active execution plan, QA plan, or SPEC family. 4. Visible-browser plan when final visible QA is requested or the plan is in scope. 5. This skill's QA protocol. 6. Coverage model, inventory requirements, and control/state protocols below. 7. Automated tests as verification evidence only. If authorities conflict, state the conflict and follow the higher authority. Never use a test expectation to override real required product behavior. Record evidence and report findings, including: - route/page candidates - mounted entry candidates - action/handler/API candidates - data source/store/API/DB candidates - permission/context gate candidates - likely source files for suggested fix direction Pass/fail requires runtime evidence. ## Core Workflow (Frontend / UI) 1. **Preflight** → build, runtime, browser (`references/frontend-runtime-and-build-rules.md`) 2. **Inventory** → surfaces, controls, states (`references/frontend-coverage-model.md`) 3. **Automation** → screenshots, control sweep (`references/frontend-automation-and-control-sweep.md`) 4. **Data flow** → field/button tracing, E2E roundtrip (`references/e2e-data-flow.md`) 5. **Source-of-truth** → verify against real DB state (`references/source-of-truth-rules.md`) 6. **Locale** → if i18n in scope (`references/frontend-i18n-and-locale.md`) 7. **Evidence & Report** → screenshots, visual blockers, report, handoff (`references/reporting.md`) ## Core Workflow (Backend / API & DB) 1. **Preflight & Protocol** → verify server runtime, DB connection, closed-loop API execution (`references/backend-qa-protocol.md`) 2. **Source-of-truth** → verify real DB state mutations, no mock data (`references/source-of-truth-rules.md`) 3. **Evidence & Blockers** → verify test bounds, blocker propagation (`references/evidence-and-blockers.md`) 4. **Report & Escalation** → HTTP status, DB diff, latency/RAM, handoff; escalate to `Edge-Case` if hostile chaos is required (`references/reporting.md`) ## Red Flags Stop, report, or re-scope if: - QA starts fixing code. - QA runs only headless/hidden browser for final visible QA. - QA skips inventory. - QA skips a step in an in-scope flow. - QA clicks only the happy path. - QA ignores disabled, no-op, rejected, empty, error, stale, or blocked states. - QA uses fake app/commercial data as if it were real production state. - QA ignores DB/source readback for DB-backed behavior. - QA ignores locale/session/permission changes when in scope. - QA reports downstream scope as passed after an upstream blocker.