@codyswann/lisa 4.55.1 → 4.55.3

package/plugins/lisa-copilot/commands/lisa/qa-fail.md

@@ -1,6 +0,0 @@
----
-description: "File a QA failure: find the right ticket (never a duplicate), write the structured failure report, diagnose the expectation gap, label qa-fail, and return the ticket to build-ready."
-argument-hint: "[ticket-key] <what you saw, in your own words>"
----
-
-Use the /lisa-qa-fail skill to file this QA failure. $ARGUMENTS

package/plugins/lisa-copilot/commands/lisa/qa-queue.md

@@ -1,6 +0,0 @@
----
-description: "Serve the next ticket awaiting QA verdict as a plain-language acceptance brief; record pass (→ certified) or fail (→ structured report via lisa-qa-fail)."
-argument-hint: "[pass | fail <description> | next]"
----
-
-Use the /lisa-qa-queue skill to serve the QA acceptance queue. $ARGUMENTS

package/plugins/lisa-copilot/skills/lisa-qa-checklist/SKILL.md

@@ -1,70 +0,0 @@
----
-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
-
-1. **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.
-2. **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:
-
-```text
-## 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.

package/plugins/lisa-copilot/skills/lisa-qa-clear/SKILL.md

@@ -1,86 +0,0 @@
----
-name: lisa-qa-clear
-description: "Bulk-clear tickets a human QA tester cannot verify. Finds tickets in the configured QA queue status that are scoped entirely to non-user-facing repos (API/backend services, infrastructure) — where QA has only end-user access and nothing observable to test — and transitions them to the configured certified status, reporting the moved list for the record. Runnable from any coding agent as a single instruction like 'move all backend- and infrastructure-only tickets from the QA queue to certified'."
-allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
----
-
-# QA Clear: $ARGUMENTS
-
-Human QA can only judge what a user can see. Tickets whose entire scope is a
-non-user-facing repo were already verified by the automated lifecycle before reaching the
-QA queue; holding them for a human who cannot observe them is pure queue noise. Clear
-them in one auditable batch.
-
-## Config resolution
-
-Read `.lisa.config.json`:
-
-- **QA queue status** — `jira.workflow.qa.queue`, falling back to
-  `jira.workflow.done.staging`.
-- **Certified status** — `jira.workflow.qa.certified`. Required; if missing, stop and
-  instruct the operator — never guess a terminal status.
-- **Tracker dispatch** — `tracker` decides the surface as everywhere; on GitHub or
-  Linear the status names above map to the equivalent labels/states.
-- **Non-user-facing repos** — `qa.nonUserFacingRepos` (array of repo names, e.g.
-  `["api", "infrastructure"]`). If the key is missing, derive a proposal from
-  the project registry (repos with no UI framework signals — no expo/react/native/web
-  app surface) and **present it for operator confirmation before moving anything**; never
-  bulk-transition on an unconfirmed inference. Recommend persisting the confirmed list to
-  the config.
-
-## Procedure
-
-1. Query all tickets in the QA queue status.
-2. Classify each by repo scope, in order:
-   - `repo:<name>` label or matching component → that repo.
-   - Unlabeled → determine the repo from the ticket content (description, AC, technical
-     approach) exactly as build-intake's repo-scope gate does, and stamp the
-     `repo:<name>` label while you're there so the next sweep is cheap.
-   - Undeterminable → leave in place; flag for the operator.
-3. Partition:
-   - **Every** touched repo is non-user-facing → eligible to clear.
-   - Any user-facing repo in scope (including mixed-scope) → stays in the queue for the
-     human pass via `lisa-qa-queue`.
-4. For each eligible ticket, in this order — the pairing must be failure-safe:
-   1. Post the audit comment first:
-      `[lisa-qa-clear] Certified without human QA: scope is <repo(s)>, not observable
-      with end-user access. Verified by the automated lifecycle pre-promotion.`
-   2. Then transition to the certified status.
-   3. Then clear the QA-failure **signal**, because certifying is one of its two void
-      conditions and this is the second path that reaches it:
-
-      ```bash
-      RESOLVER="${CLAUDE_PLUGIN_ROOT:-${PLUGIN_ROOT:-plugins/lisa}}/scripts/qa-signal-lifecycle.mjs"
-      SIGNAL=$(node "$RESOLVER" --vendor "<jira|linear|github>" --print-label)
-      ```
-
-      Remove `$SIGNAL` through the same tracker surface that applied it. Removing a label
-      the ticket does not carry is a no-op, so this runs unconditionally. The
-      `[lisa-qa-fail]` comments are never touched — the history stays, the signal goes.
-   4. Verify all three landed before counting the ticket as moved. A comment without
-      the transition, a transition without the comment, or a certified ticket still
-      wearing the signal is a **partial** — report it as such, never as completed.
-5. Report the batch:
-
-```text
-## QA Clear — <date>
-Moved to <certified>: <n> (<KEY-1>, <KEY-2>, …) — repo per ticket
-Left in queue (user-facing): <n>
-Left in queue (undeterminable repo — needs operator): <keys or none>
-```
-
-The operator (or tester) reviews the moved list; anything that "sounds user-facing" can
-be pulled back with a single instruction — the transition is reversible and the comment
-marks exactly what was auto-cleared.
-
-## Rules
-
-- Never clear a mixed-scope ticket — partial human-verifiability means human QA.
-- Never bulk-move on an inferred repo list without explicit operator confirmation.
-- Every cleared ticket carries the audit comment; a transition without the comment is a
-  bug in this procedure.
-- Idempotent by repair, not by skip: a ticket is complete only when it has the
-  `[lisa-qa-clear]` comment, the certified status, AND no QA-failure signal. Re-runs
-  finish partials — comment present but not certified → transition it; certified but no
-  comment → post the comment; certified but still signalled → clear the signal. Only
-  fully-complete tickets are skipped silently.

package/plugins/lisa-copilot/skills/lisa-qa-fail/SKILL.md

@@ -1,119 +0,0 @@
----
-name: lisa-qa-fail
-description: "QA failure front door. Takes a human tester's plain-language failure description, finds the right ticket (the served ticket, or the original via duplicate-discovery when the report arrives untied), writes the structured failure report (repro / expected vs. actual / which acceptance criterion failed), diagnoses the EXPECTATION GAP — why the implementing agent's done-evidence said done when QA says it isn't — applies the qa-fail label that makes lisa-rework-triage detection deterministic, and transitions the ticket back to the build-ready status. QA never words a ticket again; agents never guess what QA meant."
-allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
----
-
-# QA Fail: $ARGUMENTS
-
-Convert a human failure observation into the exact artifact the fixing agent needs. Two
-inputs arrive together or the report cannot be filed: a **target ticket** and the
-**tester's verbatim description** (what they did, what they expected, what happened,
-plus any screenshots).
-
-## Phase 1 — Resolve the target ticket
-
-- **Tied report** (invoked from `lisa-qa-queue` with a key): use it.
-- **Untied report** ("I found something broken: …"): run duplicate-discovery BEFORE any
-  write, reusing the mandatory relationship-discovery searches defined by the configured
-  tracker's write skill (dispatched through `lisa-tracker-write`): search open and
-  recently-closed tickets in the affected area, and the current QA-queue set. If an existing ticket
-  covers it, that ticket is the target — update it, never file a twin. Only when the
-  search documents no match, create a new Bug via `lisa-tracker-write` (which enforces
-  the full quality gates) with explicit `build_ready: true` per the `ready-role-filing`
-  rule — omitted is NOT build-ready on any tracker, and a rework Bug nothing claims is
-  an incomplete handoff — and treat it as the target. Report which path was taken.
-
-## Phase 2 — Structured failure report
-
-Fetch the bundle via `lisa-tracker-read`. Post one comment:
-
-```text
-[lisa-qa-fail] QA failure — <one-line summary>
-Reported by: <tester> on <date>, against <environment>
-Steps to reproduce: <numbered, from the tester's words>
-Expected: <what the ticket/AC promised, quoted or paraphrased faithfully>
-Actual: <what the tester observed, verbatim where possible>
-Failed acceptance criterion: <AC number/text from the ticket — or "not covered by any AC" (see gap)>
-Attachments: <screenshots if provided>
-```
-
-Preserve the tester's language in `Actual` — their words are the evidence; your job is
-structure, not rewording.
-
-## Phase 3 — Expectation-gap diagnosis
-
-Answer explicitly: **why did the implementing agent believe this was done?** Locate the
-prior cycle's done-evidence — the build-evidence comment (`lisa-tracker-evidence` output),
-the merged PR's verification section, and any codified regression test — and compare it
-against the failure. Classify the gap (exactly one):
-
-| Gap | Meaning |
-|-----|---------|
-| `ac-mismatch` | The evidence verified a different reading of the AC than QA's — the criterion is ambiguous or the ticket distorted it. |
-| `verification-weakness` | The evidence never actually exercised the failing path (asserted adjacent behavior, mocked the surface, or skipped the step). |
-| `environment-difference` | Verified where it works (e.g. dev) but fails on the QA environment — config, data, or deployment drift. |
-| `data-difference` | Behavior depends on data present in one environment and absent in the other. |
-| `regression-since-merge` | The evidence was genuinely valid when produced; later merges broke it. |
-| `not-covered-by-ac` | QA's expectation is real but no AC promises it — a spec gap, not an implementation failure. |
-
-Append to the same comment:
-
-```text
-Expectation gap: <classification>
-Why the agent thought it was done: <2-3 lines citing the specific evidence artifact>
-```
-
-If no done-evidence exists at all, say so — `Expectation gap: no-evidence-found` is
-itself a serious finding (the verification lifecycle was skipped) and must be surfaced,
-not smoothed over.
-
-For `not-covered-by-ac`, do NOT transition the ticket — the spec question goes to the
-human product gate. Flag it in the response and stop after posting.
-
-## Phase 4 — Signal and transition
-
-1. Apply the QA-failure **signal** label. Resolve its name — never hardcode one:
-
-   ```bash
-   SIGNAL=$(node "${CLAUDE_PLUGIN_ROOT:-${PLUGIN_ROOT:-plugins/lisa}}/scripts/qa-signal-lifecycle.mjs" \
-     --vendor "<jira|linear|github>" --print-label)   # `qa.labels.fail`, default `qa-fail`
-   ```
-
-   This is the deterministic rework signal `lisa-rework-triage` keys on at next claim, and
-   the gap classification above becomes its primary evidence.
-
-   The signal is **transient, and it says so.** Two void conditions lift it, both with an
-   executable predicate in `scripts/qa-signal-lifecycle.mjs`: a later QA pass verdict
-   (`qa-pass-recorded`), or the item reaching the certified or a terminal role
-   (`certified-role-reached`). `lisa-qa-queue` clears it on the pass path and `lisa-qa-clear`
-   clears it when it certifies without a human, so the clear path is as reachable as this
-   one. Record that in the comment so nobody has to infer it:
-
-   ```text
-   Signal: <label> — voided by a later QA pass, or by reaching the certified/terminal role.
-   ```
-
-   What is durable is the **history**: this `[lisa-qa-fail]` comment is never rewritten or
-   removed, so "failed QA twice before shipping" stays readable after the label is gone.
-   The label is the machine-read signal; the comment is the record.
-2. Transition the ticket to the build-ready status (`jira.workflow.ready`, or the
-   configured tracker's equivalent ready label/state when `tracker` is GitHub or
-   Linear). The rework loop takes it from here: intake claims it, `lisa-ticket-triage` Phase 2.5 runs
-   `lisa-rework-triage`, and the fix proceeds with full context.
-3. Confirm to the tester in one plain sentence: what was recorded, and that the fix is
-   queued — no further action needed from them.
-
-## Rules
-
-- Never file a new ticket without the documented duplicate search (Phase 1).
-- Never paraphrase away the tester's observation; structure around it.
-- One `[lisa-qa-fail]` comment per failure event — if the same tester reports the same
-  failure again before a fix ships, add a short "seen again <date>" line to the existing
-  comment instead of a new block.
-- The expectation gap must cite a specific evidence artifact or say `no-evidence-found` —
-  a gap classification without a citation is a guess, and guesses are worse than
-  `no-evidence-found`.
-- Never apply a signal whose clear path you cannot name. A durable mark with no inverse is
-  a defect class of its own (`state-changes-without-inverses`): it stays correct at the
-  moment it fires and becomes wrong by outliving what it described.

package/plugins/lisa-copilot/skills/lisa-qa-queue/SKILL.md

@@ -1,94 +0,0 @@
----
-name: lisa-qa-queue
-description: "QA acceptance queue for human testers. Serves the next ticket awaiting QA verdict from the configured QA queue status as a plain-language acceptance brief — what the ticket promises, how to exercise it on the QA environment, in words a non-technical tester can follow. On 'pass', transitions the ticket to the configured certified status. On 'fail', delegates to lisa-qa-fail for the structured failure report, expectation-gap diagnosis, and return to the build-ready status. The conversational front door for human QA acceptance on any coding agent: testers say 'what's the next item?' / 'pass' / 'fail — here's what I saw'."
-allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
----
-
-# QA Queue: $ARGUMENTS
-
-Serve one ticket at a time to a human QA tester and record their verdict. The tester is
-assumed **non-technical**: everything you present must be readable by an intern on their
-first day — no stack traces, no jargon, no internal identifiers without explanation.
-
-## Config resolution
-
-Read `.lisa.config.json`:
-
-- **QA queue status** — `jira.workflow.qa.queue`, falling back to `jira.workflow.done.staging`
-  (whatever status the project uses for "deployed to the environment QA tests against").
-  If neither exists, stop and report the missing config.
-- **Certified status** — `jira.workflow.qa.certified` (the project's "passed QA, ships
-  with the next release" status). Required for the pass path; if missing, stop and
-  instruct the operator to add it — never guess a terminal status.
-- **Build-ready status** — `jira.workflow.ready` (fail path, via `lisa-qa-fail`).
-- **Tracker dispatch** — as everywhere: `tracker` decides JIRA / GitHub / Linear surfaces;
-  status names above map to labels/states on non-JIRA trackers.
-
-## Serving the next item
-
-1. Query the QA queue: tickets in the queue status, oldest first, excluding tickets
-   already carrying an unresolved `[lisa-qa-fail]` verdict from this sweep. Skip tickets
-   whose repo is listed in `qa.nonUserFacingRepos` — those belong to `lisa-qa-clear`,
-   not a human tester; note any encountered so the operator knows to run the clear.
-2. Fetch the full context bundle via `lisa-tracker-read` (never serve from a bare summary).
-3. Present ONE ticket as an **acceptance brief**:
-   - **What changed, in user terms** — one or two sentences, translated from the ticket's
-     stakeholder section.
-   - **How to try it** — concrete steps on the QA environment (the `exploration` /
-     Validation Journey config supplies the URL and test credentials): where to go, what
-     to click or type, which account to use.
-   - **What success looks like** — each acceptance criterion rewritten as an observable
-     check ("you should see …"), numbered so the tester can cite one on failure.
-   - **Worth poking at** — up to three edge probes drawn from the ticket's edge-case
-     triage findings, phrased as actions ("try it with an empty search box").
-4. End with: "Say **pass**, or describe what you saw if it failed."
-
-## Recording the verdict
-
-- **Pass** — three writes, in this order, and the pairing must be failure-safe exactly as
-  `lisa-qa-clear`'s is:
-  1. Post a brief `[lisa-qa-queue] QA pass` comment naming who verified and when. The
-     literal marker matters: it is the `qa-pass-recorded` void condition's evidence.
-  2. Transition the ticket to the certified status via the tracker access layer.
-  3. **Clear the QA-failure signal.** A pass is the inverse of a fail, and until this runs
-     an item that failed once reads as failing forever to `lisa-rework-triage`:
-
-     ```bash
-     RESOLVER="${CLAUDE_PLUGIN_ROOT:-${PLUGIN_ROOT:-plugins/lisa}}/scripts/qa-signal-lifecycle.mjs"
-     SIGNAL=$(node "$RESOLVER" --vendor "<jira|linear|github>" --print-label)
-     ```
-
-     Remove `$SIGNAL` from the item through the same tracker surface that applied it —
-     `gh issue edit <n> --remove-label "$SIGNAL"` on GitHub, the label-update mutation on
-     Linear, the `update.labels[].remove` field on JIRA. Removing a label the item does not
-     carry is a no-op on every tracker, so this is safe to run unconditionally.
-
-  Verify all three landed before reporting the pass. A transition without the signal
-  cleared is a **partial** — report it as such and finish it, never count it as complete.
-
-  The failure **history** is untouched: the `[lisa-qa-fail]` comments stay exactly as
-  written. Only the machine-read signal is voided, so "this failed QA twice before
-  shipping" remains readable while "this is failing QA" stops being asserted.
-
-  Then offer the next item.
-- **Fail** — invoke `lisa-qa-fail` with the ticket key and the tester's own words
-  (verbatim — do not paraphrase away detail; attach any screenshots they provided). That
-  skill owns the failure report, the expectation-gap diagnosis, the `qa-fail` label, and
-  the transition back to build-ready. When it completes, confirm to the tester in one
-  plain sentence what was recorded and offer the next item.
-- **Unclear / can't test** — if the tester cannot exercise the ticket (missing access,
-  feature flag off, no test data), do NOT guess a verdict. Post a
-  `[lisa-qa-queue] QA blocked: <reason>` comment, leave the status untouched, flag it in
-  the session summary for the operator, and serve the next item.
-
-## Rules
-
-- One ticket at a time — never dump the queue on the tester.
-- The tester's verbatim description is evidence; preserve it exactly in whatever is posted.
-- Never transition to certified without an explicit "pass" from the tester.
-- Never certify without clearing the QA-failure signal. The clear path must stay as
-  reachable as the path that applied it (`state-changes-without-inverses`).
-- All tracker writes go through the access layer / `lisa-qa-fail` — this skill never
-  hand-crafts tracker mutations beyond the pass transition and its comment.
-- Session summary on request ("how did we do?"): counts of passed / failed / blocked /
-  remaining in queue.

package/plugins/lisa-cursor/commands/lisa/qa-checklist.md

@@ -1,6 +0,0 @@
----
-description: "Serve the current manual regression checklist: curated journeys minus live automated E2E coverage, in plain language."
-argument-hint: ""
----
-
-Use the /lisa-qa-checklist skill to serve the manual regression checklist. $ARGUMENTS

package/plugins/lisa-cursor/commands/lisa/qa-clear.md

@@ -1,6 +0,0 @@
----
-description: "Bulk-move QA-queue tickets scoped entirely to non-user-facing repos to the configured certified status, with an auditable moved-list report."
-argument-hint: ""
----
-
-Use the /lisa-qa-clear skill to clear non-human-verifiable tickets from the QA queue. $ARGUMENTS

package/plugins/lisa-cursor/commands/lisa/qa-fail.md

@@ -1,6 +0,0 @@
----
-description: "File a QA failure: find the right ticket (never a duplicate), write the structured failure report, diagnose the expectation gap, label qa-fail, and return the ticket to build-ready."
-argument-hint: "[ticket-key] <what you saw, in your own words>"
----
-
-Use the /lisa-qa-fail skill to file this QA failure. $ARGUMENTS

package/plugins/lisa-cursor/commands/lisa/qa-queue.md

@@ -1,6 +0,0 @@
----
-description: "Serve the next ticket awaiting QA verdict as a plain-language acceptance brief; record pass (→ certified) or fail (→ structured report via lisa-qa-fail)."
-argument-hint: "[pass | fail <description> | next]"
----
-
-Use the /lisa-qa-queue skill to serve the QA acceptance queue. $ARGUMENTS

package/plugins/lisa-cursor/skills/lisa-qa-checklist/SKILL.md

@@ -1,70 +0,0 @@
----
-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
-
-1. **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.
-2. **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:
-
-```text
-## 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.

package/plugins/lisa-cursor/skills/lisa-qa-clear/SKILL.md

@@ -1,86 +0,0 @@
----
-name: lisa-qa-clear
-description: "Bulk-clear tickets a human QA tester cannot verify. Finds tickets in the configured QA queue status that are scoped entirely to non-user-facing repos (API/backend services, infrastructure) — where QA has only end-user access and nothing observable to test — and transitions them to the configured certified status, reporting the moved list for the record. Runnable from any coding agent as a single instruction like 'move all backend- and infrastructure-only tickets from the QA queue to certified'."
-allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
----
-
-# QA Clear: $ARGUMENTS
-
-Human QA can only judge what a user can see. Tickets whose entire scope is a
-non-user-facing repo were already verified by the automated lifecycle before reaching the
-QA queue; holding them for a human who cannot observe them is pure queue noise. Clear
-them in one auditable batch.
-
-## Config resolution
-
-Read `.lisa.config.json`:
-
-- **QA queue status** — `jira.workflow.qa.queue`, falling back to
-  `jira.workflow.done.staging`.
-- **Certified status** — `jira.workflow.qa.certified`. Required; if missing, stop and
-  instruct the operator — never guess a terminal status.
-- **Tracker dispatch** — `tracker` decides the surface as everywhere; on GitHub or
-  Linear the status names above map to the equivalent labels/states.
-- **Non-user-facing repos** — `qa.nonUserFacingRepos` (array of repo names, e.g.
-  `["api", "infrastructure"]`). If the key is missing, derive a proposal from
-  the project registry (repos with no UI framework signals — no expo/react/native/web
-  app surface) and **present it for operator confirmation before moving anything**; never
-  bulk-transition on an unconfirmed inference. Recommend persisting the confirmed list to
-  the config.
-
-## Procedure
-
-1. Query all tickets in the QA queue status.
-2. Classify each by repo scope, in order:
-   - `repo:<name>` label or matching component → that repo.
-   - Unlabeled → determine the repo from the ticket content (description, AC, technical
-     approach) exactly as build-intake's repo-scope gate does, and stamp the
-     `repo:<name>` label while you're there so the next sweep is cheap.
-   - Undeterminable → leave in place; flag for the operator.
-3. Partition:
-   - **Every** touched repo is non-user-facing → eligible to clear.
-   - Any user-facing repo in scope (including mixed-scope) → stays in the queue for the
-     human pass via `lisa-qa-queue`.
-4. For each eligible ticket, in this order — the pairing must be failure-safe:
-   1. Post the audit comment first:
-      `[lisa-qa-clear] Certified without human QA: scope is <repo(s)>, not observable
-      with end-user access. Verified by the automated lifecycle pre-promotion.`
-   2. Then transition to the certified status.
-   3. Then clear the QA-failure **signal**, because certifying is one of its two void
-      conditions and this is the second path that reaches it:
-
-      ```bash
-      RESOLVER="${CLAUDE_PLUGIN_ROOT:-${PLUGIN_ROOT:-plugins/lisa}}/scripts/qa-signal-lifecycle.mjs"
-      SIGNAL=$(node "$RESOLVER" --vendor "<jira|linear|github>" --print-label)
-      ```
-
-      Remove `$SIGNAL` through the same tracker surface that applied it. Removing a label
-      the ticket does not carry is a no-op, so this runs unconditionally. The
-      `[lisa-qa-fail]` comments are never touched — the history stays, the signal goes.
-   4. Verify all three landed before counting the ticket as moved. A comment without
-      the transition, a transition without the comment, or a certified ticket still
-      wearing the signal is a **partial** — report it as such, never as completed.
-5. Report the batch:
-
-```text
-## QA Clear — <date>
-Moved to <certified>: <n> (<KEY-1>, <KEY-2>, …) — repo per ticket
-Left in queue (user-facing): <n>
-Left in queue (undeterminable repo — needs operator): <keys or none>
-```
-
-The operator (or tester) reviews the moved list; anything that "sounds user-facing" can
-be pulled back with a single instruction — the transition is reversible and the comment
-marks exactly what was auto-cleared.
-
-## Rules
-
-- Never clear a mixed-scope ticket — partial human-verifiability means human QA.
-- Never bulk-move on an inferred repo list without explicit operator confirmation.
-- Every cleared ticket carries the audit comment; a transition without the comment is a
-  bug in this procedure.
-- Idempotent by repair, not by skip: a ticket is complete only when it has the
-  `[lisa-qa-clear]` comment, the certified status, AND no QA-failure signal. Re-runs
-  finish partials — comment present but not certified → transition it; certified but no
-  comment → post the comment; certified but still signalled → clear the signal. Only
-  fully-complete tickets are skipped silently.