QA Checklist: $ARGUMENTS
The manual regression sweep exists to catch what automation does not. Its checklist must
therefore be computed, not remembered: curated journeys minus automated coverage, at the
moment the tester asks.
Sources
- Curated journey list —
qa.checklistFile in .lisa.config.json, default
.lisa/qa-checklist.md. Format: one ## Journey: <name> section per user journey,
with plain-language steps and an optional automation: line naming the covering spec
file(s) once one exists. If the file does not exist, offer to bootstrap it: derive
candidate journeys from the app's route map and the existing E2E suites' describe
blocks, write the draft, and ask the operator to curate it once. Never invent
journeys silently.
- Automated coverage — scan the repo's E2E suites (Playwright specs, Maestro flows;
locate via the project's e2e/test directories). An
automation: line must name BOTH
the spec file and the specific test within it (the Playwright describe/test title
or Maestro flow name): automation: <spec-path> :: <test-or-flow-name>. A journey
counts as covered only when that spec file exists, the named test/flow is present in
it, and it is not skipped (test.skip, commented-out flow, or excluded from CI). A
file-only line, a named test that no longer matches, or any ambiguous mapping is
treated as uncovered — a live filename proves nothing about what the spec
exercises. A deleted, renamed, or skipped test silently un-covers its journey — the
very regression this check exists to catch; call it out loudly.
Serving the sweep
Present two lists, human-first:
## Manual sweep — <n> journeys need your eyes
1. <Journey name> — <plain-language steps>
Why manual: <no automation | automation skipped/stale: <spec>>
...
## Covered by automation — <n> journeys (skim, don't re-test)
- <Journey name> — <spec file> (<playwright|maestro>)
Rules for the served text: steps an intern can follow, no spec-file jargon in the manual
section beyond the "why manual" line, and stable journey ordering (file order) so testers
can resume mid-sweep.
Maintaining the list
- Tester or operator adds/edits journeys in plain language → edit the checklist file
(this skill may apply the edit on request; it is a repo file, so changes ride normal
review).
- When a journey gains automation (e.g.
lisa-codify-verification lands a spec), add its
automation: <spec-path> :: <test-or-flow-name> line — on request this skill locates
the covering spec and test, confirms the named test actually drives the journey's
steps, and writes the line itself.
- Never maintain per-tester copies; the file is the single source of truth and the
computed view is always derived fresh.
Rules
- Coverage claims must point at an existing, non-skipped spec — "there's a test somewhere"
does not count.
- Serving is read-only by default; file edits happen only on explicit request.
- If the automated-coverage scan finds specs exercising a journey that is missing from
the curated list entirely, surface it as a suggested addition — the human curates, the
skill proposes.
1---2name: lisa-qa-checklist3description: Serve the current manual regression checklist to a human QA tester. Reads the project's curated journey list, cross-references it against what the automated suites (Playwright web E2E, Maestro native E2E) actually cover by scanning the spec files, and serves only the journeys that still need human eyes — each as plain-language steps. Keeps a single source of truth so testers never work from a stale personal copy, and shrinks automatically as automated coverage grows.4---56# QA Checklist: $ARGUMENTS78The manual regression sweep exists to catch what automation does not. Its checklist must9therefore be computed, not remembered: curated journeys minus automated coverage, at the10moment the tester asks.1112## Sources13141. **Curated journey list** — `qa.checklistFile` in `.lisa.config.json`, default15 `.lisa/qa-checklist.md`. Format: one `## Journey: <name>` section per user journey,16 with plain-language steps and an optional `automation:` line naming the covering spec17 file(s) once one exists. If the file does not exist, offer to bootstrap it: derive18 candidate journeys from the app's route map and the existing E2E suites' describe19 blocks, write the draft, and ask the operator to curate it once. Never invent20 journeys silently.212. **Automated coverage** — scan the repo's E2E suites (Playwright specs, Maestro flows;22 locate via the project's e2e/test directories). An `automation:` line must name BOTH23 the spec file and the specific test within it (the Playwright `describe`/`test` title24 or Maestro flow name): `automation: <spec-path> :: <test-or-flow-name>`. A journey25 counts as covered only when that spec file exists, the named test/flow is present in26 it, and it is not skipped (`test.skip`, commented-out flow, or excluded from CI). A27 file-only line, a named test that no longer matches, or any ambiguous mapping is28 treated as **uncovered** — a live filename proves nothing about what the spec29 exercises. A deleted, renamed, or skipped test silently un-covers its journey — the30 very regression this check exists to catch; call it out loudly.3132## Serving the sweep3334Present two lists, human-first:3536```text37## Manual sweep — <n> journeys need your eyes381. <Journey name> — <plain-language steps>39 Why manual: <no automation | automation skipped/stale: <spec>>40...4142## Covered by automation — <n> journeys (skim, don't re-test)43- <Journey name> — <spec file> (<playwright|maestro>)44```4546Rules for the served text: steps an intern can follow, no spec-file jargon in the manual47section beyond the "why manual" line, and stable journey ordering (file order) so testers48can resume mid-sweep.4950## Maintaining the list5152- Tester or operator adds/edits journeys in plain language → edit the checklist file53 (this skill may apply the edit on request; it is a repo file, so changes ride normal54 review).55- When a journey gains automation (e.g. `lisa-codify-verification` lands a spec), add its56 `automation: <spec-path> :: <test-or-flow-name>` line — on request this skill locates57 the covering spec and test, confirms the named test actually drives the journey's58 steps, and writes the line itself.59- Never maintain per-tester copies; the file is the single source of truth and the60 computed view is always derived fresh.6162## Rules6364- Coverage claims must point at an existing, non-skipped spec — "there's a test somewhere"65 does not count.66- Serving is read-only by default; file edits happen only on explicit request.67- If the automated-coverage scan finds specs exercising a journey that is missing from68 the curated list entirely, surface it as a suggested addition — the human curates, the69 skill proposes.
codyswanngt