QA

QA is a browser session you direct. You file a ticket describing, in plain language, exactly what to check — a bug to reproduce, an area to pick apart for UX problems, or a flow to walk for friction — and QA drives your product in a real browser (Playwright/Chromium) doing that, recording one continuous video. The deliverable — the recording plus a short findings comment — lands on the same ticket. It's recommend-only: it reports what it found and never changes your product or opens a PR.

Prerequisites

• File a ticket on the QA skill. From chat, ask for it in plain language — "reproduce this bug", "QA the checkout flow", "find the friction in onboarding", "check the UX of settings" — and the dispatcher creates a QA ticket. Your description is the spine of the session.
• A target to browse. QA prefers your configured staging URL with a throwaway login (destructive flows are in scope there); with none configured it browses the live site read-only, staying non-destructive.
• Optional but helpful: a connected GitHub repo. QA reads the route and component for the area under test to go straight there with the right selectors, instead of hunting.

How it works

1. Reads your direction and classifies it into a mode:

   • reproduce — follow your steps and report whether the bug reproduces, with the moment on video.
   • ux — exercise the area and return a prioritized list of UX problems.
   • friction — walk the flow and surface and measure friction: extra steps, dead clicks, slow or missing states, confusing copy, errors.
   • general — anything else QA-shaped.

   It posts one short progress comment so you can see it's underway, then works.

2. Learns the flow from the source (when the repo is connected) — reads the page/component for the area to know the exact path, selectors, and states — then confirms against the live page and reports any mismatch.

3. Records one continuous session. It drives the browser through your ask on the right device — desktop by default, mobile when you asked for it in the ticket — judging a mobile run on mobile terms (tap targets, responsive layout). It logs in only when the flow under test needs an account.

4. Posts back on the ticket. A video artifact you play inline (the same player as Cast and Story QA) plus a report artifact shaped to the ask — a few tight lines, not a document.

Example

File a ticket like:

Reproduce this: on the pricing page, clicking Upgrade while logged out does nothing — no modal, no redirect. Expected: it should send me to sign-in.

QA opens the pricing page in a browser, clicks Upgrade logged out, records what actually happens, and comments back with the verdict — reproduced or not — the observed behavior, and the recording pinned to the moment.

What you get

• A screen recording of the session on the ticket, playable inline.
• A findings report matched to the mode — a repro verdict, a prioritized UX list, or measured friction points.
• No product changes. QA is recommend-only; to act on what it finds, comment on the ticket to hand it to a coding loop.

QA vs. the other browser loops

QA is one of three browser loops, and the difference is who aims it:

Reach for QA when you have a specific thing you want eyes on right now.

Notes & limits

• Recommend-only. No PRs, no commits, no product changes — QA reports.
• One session per run. It stays focused on your ask and keeps the check tight; iterate by commenting.
• Read-only on the live site. Without a staging target it browses production non-destructively. Configure a staging URL + throwaway login (shared with Story QA) to let it exercise destructive flows safely.
• Credentials stay hidden. The throwaway login is never printed, logged, or shown in the recording.