codyswanngt/lisa-qa-checklist
plugins/lisa-agy/skills/lisa-qa-checklist/SKILL.md
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.
$ install --global
skillsauthnpx skillsauth add codyswanngt/lisa lisa-qa-checklistInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jul 19, 2026, 3:56 AM113.4s1 file scanned
SKILL.md
- name:
- lisa-qa-checklist
- description:
- 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.
- allowed-tools:
- ["Bash", "Read", "Glob", "Grep", "Write", "Edit"]
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.checklistFilein.lisa.config.json, default.lisa/qa-checklist.md. Format: one## Journey: <name>section per user journey, with plain-language steps and an optionalautomation: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 Playwrightdescribe/testtitle 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-verificationlands a spec), add itsautomation: <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.
Related Skills
codyswanngt/lisa-setup-workstation
development
VerifiedTrustedCommunity
Prepare a machine — a fresh laptop or a throwaway container — to run coding agents, before any repository exists. Detects which of Lisa's supported agents (Claude Code, Codex, Cursor, OpenCode, Antigravity, Copilot) are already installed, asks which credential manager the machine uses (Bitwarden, 1Password, Doppler, Vault, AWS, or none), and installs only what is missing, each by its vendor's own preferred method. Idempotent, headless by default, and emits a Dockerfile for a spin-up/spin-down environment. Run it on a new machine, in a container, or before cloning anything.
3SKILL.mdUpdated Aug 30, 2026
codyswanngt/lisa-setup-remote-env
tools
VerifiedTrustedCommunity
Provision and verify a remote execution environment for a host project — Codex Cloud today, other remote surfaces as they are added. Generates a repository-owned setup script that installs the declared toolchain, materializes secrets through lisa-secrets-access, and runs the project's own hook. Provisions by API where one exists, by driving the vendor console where one does not, and by emitting exact config otherwise — then proves the result with the same read-back regardless of which tier did the work. Use before dispatching any work with executionEnv.
3SKILL.mdUpdated Aug 30, 2026
codyswanngt/lisa-setup-local-env
tools
VerifiedTrustedCommunity
Bring a developer's machine in line with the toolchain the project declares. Reports every tool in remoteEnv.tools that is missing, outdated, or unpinned for this platform, and installs the missing ones into ~/.local/bin from the same pinned, checksummed entries the remote surfaces use — but only when asked. Same manifest, same pins, same installers as lisa-setup-remote-env; what differs is consent and that the pin is a floor rather than an equality. Run it on a fresh checkout, after a manifest change, or when a tool fails at the moment of use.
3SKILL.mdUpdated Aug 30, 2026
codyswanngt/lisa-remote-dispatch
tools
VerifiedTrustedCommunity
Route one unit of work to a remote execution surface. Reads the executionEnv parameter (local by default, codex-cloud or claude-web today), verifies the environment is provisioned and bound to this repository, submits a thin skill invocation, records the task identifier to .lisa/remote-dispatch.json, and exits without polling. Routing only — the remote runs the identical skill from the identical repository. Composable and inline: other skills invoke it via the Skill tool rather than users calling it directly.
3SKILL.mdUpdated Aug 30, 2026