qa-execution

What this skill does

# Real-User QA Execution

QA the way a real person would experience the product: assigned a persona, walking a journey, exercising charters bound to specific tours, probing the edges users actually hit, and validating CFRs that no single feature owns.

## Required Reading Router

Match your task to the row. Read the listed files **in full before** producing output. They are not appendices — they are load-bearing. Inline content in this SKILL.md is a pointer, not a substitute.

| Task                                                                 | MUST read                                                                                  |
| -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| Assigning personas to sessions (Step 2)                              | `references/user-personas.md`                                                              |
| Selecting high-value journeys (Step 2)                               | `references/journey-maps.md`                                                               |
| Writing exploratory charters and picking tours (Step 3)              | `references/exploratory-charters.md` + `references/test-tours.md`                          |
| Executing browser flows (Step 4)                                     | `references/web-ui-qa.md`                                                                  |
| Probing off-script user edge cases (Step 5)                          | `references/test-tours.md` + `references/user-edge-cases.md`                               |
| Running the Cross-Functional Requirement pass (Step 6)               | `references/cfr-checks.md`                                                                 |
| Classifying bug severity by user impact (Step 7)                     | `references/bug-severity-by-user-impact.md`                                                |
| Building the QA scope checklist                                      | `references/checklist.md`                                                                  |

## Reference Index

- `references/user-personas.md` — Canonical persona set (New User / Power User / Casual User / Mobile User / Accessibility-Reliant / Recovering User), attributes, and assignment rules.
- `references/journey-maps.md` — Journey anatomy (entry → actions → goal → exit + abandonment), high-value journey selection, mapping template.
- `references/exploratory-charters.md` — Charter format (mission + persona + surface + tour + time-box), charter modes (freestyle / strategy-based / scenario-based / collaborative / charter-with-tour), worked examples, debrief format.
- `references/test-tours.md` — Canonical tour catalog: Feature, Money, Garbage, Back-Button, Multi-Tab, Network, Locale, Paste, Autofill, Interrupt. One tour per charter.
- `references/user-edge-cases.md` — Catalog of non-technical edge cases real users hit (navigation, form, session, network, device, locale, accessibility, interrupt, trust/recovery).
- `references/cfr-checks.md` — 45-minute CFR pass: usability (Nielsen short list), accessibility (WCAG AA quick check), perceived performance, compatibility, error recoverability, production parity.
- `references/bug-severity-by-user-impact.md` — User-impact rubric (Blocks-Completion / Data-Loss / Trust-Damage / Friction / Cosmetic) with mapping to legacy severity/priority.
- `references/web-ui-qa.md` — `agent-browser` command set, snapshot/interact/verify loop, auth flows, viewport testing, anti-smoke guardrails.
- `references/checklist.md` — Real-user QA checklist by category: persona coverage, journey coverage, charter coverage, off-script & edge case coverage, CFR coverage, bug filing, browser evidence, final report.

## Required Inputs

- **qa-output-path** (optional): Directory where QA artifacts (issues, screenshots, verification reports) are stored. When provided, create the directory if it does not exist and use it for all QA outputs. When omitted, fall back to repository conventions or `/tmp/qa-execution-<slug>`.

## Procedures

**Step 1: Resolve Output Directory and Read qa-report Artifacts**

1. Resolve the QA artifact directory. If the user provided a `qa-output-path` argument, use it. Otherwise use repository conventions, falling back to `/tmp/qa-execution-<slug>`. Create the `qa/` subdirectory and `qa/screenshots/`, `qa/issues/` under it.
2. Check whether `<qa-output-path>/qa/test-plans/`, `<qa-output-path>/qa/test-cases/`, and any persona/journey/charter artifacts exist from a prior `qa-report` run. If they do, read them to seed Steps 2-3: persona assignments, journey maps, charter missions, and TC-* test cases prioritized by qa-report.
3. Confirm the dev server URL or the runtime entry point is reachable in a production-parity build before any test runs. **Do not run QA on a build that hasn't passed CI** — that's `agent-output-audit`'s job, not this skill's. If CI hasn't been confirmed green, surface the gap and stop.

**Step 2: Assign Personas and Select Journeys**

1. **STOP. Read `references/user-personas.md` in full before picking personas.** The six canonical personas (New User / Power User / Casual User / Mobile User / Accessibility-Reliant / Recovering User) and their attribute schema live there. The persona-of-convenience anti-pattern is the most common QA failure mode.
2. Pick **at least 3 personas** for this release-candidate QA pass, covering the product's actual audience. Include at least one Mobile User when a mobile surface exists; include at least one Accessibility-Reliant persona unless explicitly out of scope (record the skip reasoning).
3. **STOP. Read `references/journey-maps.md` in full before selecting journeys.** Journey anatomy (entry → actions → goal → exit + abandonment paths), high-value journey selection criteria, and the journey-map template live there.
4. Pick **3-7 high-value journeys** for this pass. Use these prompts: what generates revenue, what handles sensitive data, what's used most frequently, what's the first impression, what's the recovery path. Include at least one cross-feature journey when the product has them.
5. For each journey, document at least one **abandonment path** — the realistic way a real user gives up partway through. Abandonment paths surface the highest-impact bugs.
6. Record persona × journey assignments in working notes. Each journey gets at least one persona; each persona gets at least one journey.

**Step 3: Plan Exploratory Charters**

1. **STOP. Read `references/exploratory-charters.md` in full before writing any charter.** Charter anatomy (mission + persona + surface + tour + time-box), charter modes, time-box guidance, debrief format. Charters are the single biggest predictor of whether the session finds real bugs.
2. **STOP. Read `references/test-tours.md` in full before picking tours.** The 10-tour catalog (Feature / Money / Garbage / Back-Button / Multi-Tab / Network / Locale / Paste / Autofill / Interrupt) and the surface-to-tour matrix live there.
3. For each persona × journey × surface, write a charter with: a one-sentence mission, the persona, the entry URL, **exactly one tour**, and a time-box (30 / 60 / 90 minutes). Save charter drafts to `<qa-output-path>/qa/test-plans/charters/` when applicable.
4. Mix charter modes deliberately: at least one charter-with-tour for each P0 journey, at least one freestyle for new surfaces, at least one scenario-based for cross-feature journeys.
5. Order the session list by risk: highest-impact journey × highest-blast-radius tour first. Run the most fragile combinations while tester attention is fresh.

**Step 4: Execute Journey Sessions (Web UI primary)**

Skip this step's Web UI portion if the project has no Web UI surface — but still run CLI/HTTP journeys against the same persona × journey × charter plan.

1. **STOP. Read `references/web-ui-qa.md` in full before opening a browser.** That file owns the c