@codyswann/lisa 4.55.5 → 4.55.7

package/plugins/lisa-cursor/rules/upstream-to-lisa.mdc

@@ -5,26 +5,15 @@ alwaysApply: true
 
 # Upstream To Lisa (load-bearing)
 
-When working in a project that has Lisa installed, you will sometimes find that the **real fix belongs upstream in Lisa**, not in this project — a bug or gap in a Lisa-distributed template, rule, skill, agent, hook, or CI workflow, or a governance pattern worth generalizing back to the templates. The defining test: **does the root cause live in a Lisa-distributed artifact?** If yes, file upstream, regardless of whether your local fix survives the next `lisa apply`.
+When a worthwhile fix belongs to a Lisa-distributed template, rule, skill, agent, hook, or CI workflow, fix its source upstream so other projects benefit. Apply `do-it-now`'s **Worth doing** guidance first: Lisa ownership determines where accepted work belongs, not whether every imperfection deserves a ticket.
 
-Tell-tale signs include:
+For an accepted defect:
 
-- The file is Lisa-managed (carries Lisa governance markers, or lives in a path Lisa owns) and any edit you make here would be **overwritten on the next `lisa apply`**.
-- The file was created from a Lisa `create-only` template and carries language such as `Lisa will not overwrite it`. That header is a positive upstream signal: existing repos will keep their local copy, but every newly scaffolded repo still inherits the broken template until Lisa is fixed.
+1. Apply the smallest safe local stopgap if needed to unblock the current task.
+2. Search open and closed Lisa issues. Reuse a matching open issue. Honor **Not planned** decisions under `rejection-detection` before filing the concrete consequence and smallest durable fix; do not refile an accepted limitation.
 
-When that happens, you have **two obligations — do both**:
+For **copy-overwrite** files, a local fix may be overwritten on the next `lisa apply`. For **create-only** templates, the local fix survives, but new projects still inherit the source defect. Both can justify an upstream fix; neither bypasses the value decision.
 
-1. **Fix it locally so you are not blocked.** Apply the stopgap in this project so you can keep working. For copy-overwrite files, treat the local fix as temporary because it will be clobbered when the upstream fix ships and Lisa re-applies. For create-only files, keep the local fix because Lisa will not overwrite it, but still file upstream so new repos stop inheriting the bug.
-2. **File an upstream issue in the Lisa repository.** Use the `github-write-issue` skill (`lisa-github-write-issue`) to create an issue **in Lisa's source repo `CodySwannGT/lisa`** (pass it as the target repo, e.g. `gh ... --repo CodySwannGT/lisa`) — **not** in this project's own repo. Capture: the root cause, the symptom you hit here, and the proposed durable fix in Lisa's templates/rules/skills.
+Decline low-value observations without filing or escalating them. Group related small worthwhile repairs when appropriate. Do not add permanent machinery merely because an enforcement gap can be described.
 
-## Do not
-
-- Do **not** only fix it locally and move on — even when a create-only local fix survives, the broken template keeps shipping to every new repo until it is fixed upstream.
-- Do **not** try to edit Lisa's templates from inside this project — you are not in the Lisa repo; those edits don't exist upstream and get overwritten.
-- Do **not** file the issue in this project's repo — it must land in `CodySwannGT/lisa`.
-
-If you lack access to file an issue in `CodySwannGT/lisa`, surface that to the user with the proposed issue contents rather than silently dropping it.
-
-> Not applicable when you are already working **inside the Lisa repo itself** — there the fix is local, so just make it directly.
-
-Full procedure: [reference/upstream-to-lisa.md](upstream-to-lisa-reference.mdc).
+Inside Lisa, repair the shared source and regenerate the equivalent agent surfaces. Full procedure: [reference/upstream-to-lisa.md](upstream-to-lisa-reference.mdc).

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

@@ -1,13 +1,15 @@
 ---
 name: lisa-exploratory-qa
-description: First-time-user exploratory QA pass for ANY product type (DOM web app, HTTP/API backend, canvas game, CLI/library, IaC/CDK) that FEEDS THE LIFECYCLE. Use when asked to experience a product the way a brand-new end user would — driving its real consumer-facing interface via the `use-the-product` core (which detects the product type, resolves the per-environment mutation policy from .lisa.config.json so production data is never mutated by accident, and explores through the project's personas when it defines them) to find anything confusing, broken, or hard to use. Static route scans, HTTP fetches, screenshots alone, or console/network checks alone are not sufficient evidence. Instead of writing a report file, it files every finding as a tracked work item via lisa-tracker-write. A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa-intake) or left in the backlog for human triage (default). For gaps in the automated test suite, use e2e-coverage-gaps instead.
+description: First-time-user exploratory QA pass for ANY product type (DOM web app, HTTP/API backend, canvas game, CLI/library, IaC/CDK) that FEEDS THE LIFECYCLE. Use when asked to experience a product the way a brand-new end user would — driving its real consumer-facing interface via the `use-the-product` core (which detects the product type, resolves the per-environment mutation policy from .lisa.config.json so production data is never mutated by accident, and explores through the project's personas when it defines them) to find anything confusing, broken, or hard to use. Static route scans, HTTP fetches, screenshots alone, or console/network checks alone are not sufficient evidence. Instead of writing a report file, it files worthwhile findings as tracked work items via lisa-tracker-write. A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa-intake) or left in the backlog for human triage (default). For gaps in the automated test suite, use e2e-coverage-gaps instead.
 ---
 
 # Exploratory QA
 
+On runtimes without the rule tree (Antigravity), read **Worth doing** in `lisa-track` for the same value and decline policy.
+
 ## Overview
 
-Experience the product the way a **brand-new end user** would: drive its real consumer-facing interface and actually try to use it, then surface anything **confusing, broken, or hard to understand**. This is a usability/experience pass, **not** a test-coverage audit (for that, use `e2e-coverage-gaps`). Every finding is filed as a tracked work item so it enters the Lisa lifecycle — no static report file.
+Experience the product the way a **brand-new end user** would: drive its real consumer-facing interface and actually try to use it, then surface anything **confusing, broken, or hard to understand**. This is a usability/experience pass, **not** a test-coverage audit (for that, use `e2e-coverage-gaps`). Accepted worthwhile findings enter the Lisa lifecycle as bounded tracked work — no static report file.
 
 **How you drive the product is owned by the `use-the-product` core skill.** Invoke it first: it detects the product type (web / API / game / CLI / IaC), resolves the target environment and its **mutation policy** (so you never mutate production without an explicit, justified opt-in), and discovers the project's **personas** so you can explore as each one. This skill supplies the **QA lens** — what to look for and how to file it.
 
@@ -61,7 +63,7 @@ Whether you may create/edit/delete — and as which account — is set by the `u
 
 ## 6. File findings as tracked work
 
-No report file. Every finding becomes a **leaf work item** via `lisa-tracker-write` (the vendor-neutral writer — it dispatches to the configured tracker and runs the validation gate; never call a vendor `*-write-*` skill directly):
+Apply `do-it-now`'s **Worth doing** guidance first. Decline low-value observations in the run summary without a ticket or human gate; bundle related worthwhile minor findings when appropriate. No report file. Every accepted finding becomes a **leaf work item** via `lisa-tracker-write` (the vendor-neutral writer — it dispatches to the configured tracker and runs the validation gate; never call a vendor `*-write-*` skill directly):
 
 Kane never files the work item itself. Even when it marks a failure as a confirmed product bug, run Lisa's marker-based duplicate search, apply the QA lens, and route the finding through `lisa-tracker-write` exactly as for every other controller.
 
@@ -72,7 +74,7 @@ Kane never files the work item itself. Even when it marks a failure as a confirm
 
 Each finding is a flat leaf, so `build_ready` applies directly — pass it explicitly on every create.
 
-**This skill is the named human-gate exception under `ready-role-filing`.** Everywhere else in Lisa, a complete defect found during other work is filed with explicit `build_ready: true` so build-intake claims it next cycle. Exploratory QA is deliberately different, and that difference is ratified rather than drift: its findings are *candidate* defects and usability observations whose **product significance is a human call**, so auto-readying them would push judgment work into the build queue — precisely the failure the gate model exists to prevent. Its default `ready=false` is therefore an **explicit human-gate marker, never a bare omission**: every not-ready create passes `human_gate: "exploratory finding — product significance is a human product call"` alongside `build_ready: false`, and the writer stamps the auditable `[lisa-human-gate]` marker. An operator who wants a pass to feed the queue directly opts in with `ready=true`.
+**This skill is the named human-gate exception under `ready-role-filing`.** For accepted worthwhile work elsewhere in Lisa, a complete defect found during other work is filed with explicit `build_ready: true` so build-intake claims it next cycle. Exploratory QA is deliberately different, and that difference is ratified rather than drift: its findings are *candidate* defects and usability observations whose **product significance is a human call**, so auto-readying them would push judgment work into the build queue — precisely the failure the gate model exists to prevent. Its default `ready=false` is therefore an **explicit human-gate marker, never a bare omission**: every not-ready create passes `human_gate: "exploratory finding — product significance is a human product call"` alongside `build_ready: false`, and the writer stamps the auditable `[lisa-human-gate]` marker. An operator who wants a pass to feed the queue directly opts in with `ready=true`.
 
 (The sibling `e2e-coverage-gaps` skills are the contrast: a missing automated test is not a product question, so they file `build_ready: true` by default.)
 
@@ -80,11 +82,11 @@ Each ticket MUST be a complete spec (the validator rejects thin tickets): a **th
 
 ### Idempotency — don't spam duplicates
 
-Re-running a pass must not refile the same finding. Before creating a ticket, search the tracker for a ticket carrying a stable marker `[lisa-exploratory-qa] <finding-key>` in its body (the `<finding-key>` is a stable slug of surface + symptom, e.g. `settings-modal/horizontal-overflow@tablet`). Per the `rejection-detection` rule's **Proposal rejection memory** section, that marker search MUST cover **open AND closed** tickets (with a body-enumeration fallback on search-index lag), and **match by the marker, never by title.** Then split on how any prior ticket closed:
+Re-running a pass must not refile the same finding. Before creating a ticket, search the tracker for a ticket carrying a stable marker `[lisa-exploratory-qa] <finding-key>` in its body (the `<finding-key>` is a stable slug of surface + symptom, e.g. `settings-modal/horizontal-overflow@tablet`). Per the `rejection-detection` rule's **Proposal rejection memory** section, that marker search MUST cover **open AND closed** tickets (with a body-enumeration fallback on search-index lag), and **match by the marker, never by title alone; for legacy unmarked issues, read the body and closing discussion to establish the semantic match.** Then split on how any prior ticket closed:
 
 - **Open** ticket carrying the marker → reference/update it instead; do not create a second.
 - **Closed as _completed_** → does **not** suppress. A recurrence after a fix is a genuine **regression**, so file the finding.
-- **Closed as _not planned_** (GitHub `stateReason == "not_planned"`; the config-resolved won't-do/canceled equivalent on JIRA/Linear, including a Linear `duplicate` state) → a human **declined** this finding, so **suppress it**. Re-file only with evidence that **postdates the decline**, carrying BOTH the machine token (`declined <date>; recurred <date> in <ref>`) and a human acknowledgment sentence (`You declined this on <date>. It has recurred (<date>, <ref>), so we're raising it once more for your review.`).
+- **Closed as _not planned_** (GitHub `stateReason == "not_planned"`; the config-resolved won't-do/canceled equivalent on JIRA/Linear — never infer decline from a hardcoded state name) → a human **declined** this finding, so **suppress it**. Re-file only with evidence that **postdates the decline** and establishes a materially changed consequence, requirement, or risk addressing the recorded reason, carrying BOTH the machine token (`declined <date>; recurred <date> in <ref>`) and a human acknowledgment sentence (`You declined this on <date>. New evidence (<date>, <ref>) changes the consequence, requirement, or risk: <what changed and why the decline no longer applies>.`).
 
 Every filed finding ticket MUST end with the `rejection-detection` **operator footer** as a visible prose line so the operator knows which close-reason silences it:
 
@@ -150,7 +152,7 @@ teardown proposal through `lisa-tracker-write` (per `tracked-work` + `integratio
 - **Marker** `<!-- [lisa-automation-retire] key=exploratory-bugs -->` plus a visible prose line;
   matched on the marker, never the title; searched **open AND closed** per `rejection-detection`'s
   **Proposal rejection memory**. Treat matches by close state: **open** suppresses another proposal;
-  **Not planned** suppresses another proposal unless new evidence postdates the rejection;
+  **Not planned** suppresses another proposal unless new evidence postdates the rejection and materially changes the consequence, requirement, or risk that justified the decline;
   **Completed** means the prior approved action happened, so a later recurrence may be re-filed.
   When an existing proposal suppresses filing, **the run still records `policy-obsolete` and files
   nothing** — the outcome describes this run, while the ticket is filed exactly once.

package/plugins/lisa-cursor/skills/lisa-github-build-intake/SKILL.md

@@ -467,6 +467,9 @@ A blocker is active if it is open and has no cleared status label. Treat `status
 
 #### 3b. Claim
 
+Before the claim mutation, apply `claim-time-guards` — **Value before claim**, or **Worth doing** in `lisa-track` on runtimes without the rule tree (Antigravity). A ready label establishes neither value nor permission to expand scope. Respect the preceding human-hold gate; a declined incidental item consumes this cycle's one processed disposition.
+
+
 **Rejection detection runs first — before the relabel below.** Per the vendor-neutral `rejection-detection` rule (cite the slug; do not restate its classification table), classify this item at the **top of 3b, BEFORE** the `$READY → $CLAIMED` relabel — after the relabel the current-lane signal is gone. Read the item's Label-Event History from `lisa-github-read-issue` (chronological `LabeledEvent` / `UnlabeledEvent` on the configured `$READY` label) and classify it `rejection-reclaim | forward-only | never-left-ready | unknown`. Lane names come from `.lisa.config.json` (`github.labels.build.*`), never hardcoded. A failing/absent history yields `unknown` and the claim proceeds — detection never blocks the build. Items carrying a learning marker (`[lisa-learning-drop]` / `[lisa-learning-pr]` / `[lisa-learning-upstream-handoff]`) or the `learning:needs-triage` label are never rejection triggers (no learning-about-learning). Carry the classification into the relabel and lifecycle below.
 
 **On `rejection-reclaim`, reflect before re-implementing** (per `rejection-detection`): read the rejection evidence through the access layer — the issue comments posted after the backward transition (the QA rejection comment) and the review threads on the rejected PR via `lisa-github-read-issue` — assemble ONE candidate learning (rule, why, provenance linking the rejection comment + rejected PR, evidence links, scope hint, triggering issue, fingerprint `sll4-sha1(rule\ntriggering_issue)[:12]`), and route it to the `lisa-persist-learning` skill. If that skill is absent, record the candidate as a comment carrying a **visible prose line plus** the marker (a bare marker renders as an empty bubble) — `Recorded a candidate learning from this rejection (queued for the judgment gate): <one-line candidate rule>.` then `<!-- [lisa-rejection-candidate] key=<issue>-<transition-ts> -->` — and proceed. Dedupe on `<issue>-<backward-transition-timestamp>` — a second re-claim produces no duplicate. Unreadable/absent evidence → no candidate, still implement.

package/plugins/lisa-cursor/skills/lisa-github-write-issue/SKILL.md

@@ -6,6 +6,12 @@ allowed-tools: ["Bash", "Skill", "Read"]
 
 # Write GitHub Issue: $ARGUMENTS
 
+On runtimes without the rule tree (Antigravity), read **Worth doing** in `lisa-track` for the same value and decline policy.
+
+## Before creating incidental work
+
+Apply `do-it-now`'s **Worth doing** guidance before drafting a new incidental item. Decline low-value observations without writing a ticket or requesting a human gate; report the reason briefly to the caller. A complete spec is not evidence of value. This does not cancel explicit user requests or accepted requirements. Honor prior Not planned decisions through `rejection-detection`, including legacy issues without markers. Accepted work continues through the existing validation and readiness contract below.
+
 ## Human-gate release authorization
 
 A release requires a trusted human author, not just matching comment text. Follow

package/plugins/lisa-cursor/skills/lisa-jira-build-intake/SKILL.md

@@ -349,6 +349,9 @@ This gate never blocks a legitimate flat Task/Bug: those have no open children a
 
 #### 3b. Claim
 
+Before the claim mutation, apply `claim-time-guards` — **Value before claim**, or **Worth doing** in `lisa-track` on runtimes without the rule tree (Antigravity). A ready label establishes neither value nor permission to expand scope. Respect the preceding human-hold gate; a declined incidental item consumes this cycle's one processed disposition.
+
+
 **Rejection detection runs first — before the transition below.** Per the vendor-neutral `rejection-detection` rule (cite the slug; do not restate its classification table), classify this ticket at the **top of 3b, BEFORE** the `$READY → $CLAIMED` transition — after the transition the current-status signal is gone. Read the ticket's status changelog via `lisa-atlassian-access operation: changelog key: <TICKET>` and classify it `rejection-reclaim | forward-only | never-left-ready | unknown` (a `rejection-reclaim` is a changelog entry whose `to` is the configured `$READY` status following an earlier `review`/`done`-ward status). Status names come from `.lisa.config.json`, never hardcoded. A failing/absent changelog yields `unknown` and the claim proceeds — detection never blocks the build. Tickets carrying a learning marker (`[lisa-learning-drop]` / `[lisa-learning-pr]` / `[lisa-learning-upstream-handoff]`) or the `learning:needs-triage` label are never rejection triggers (no learning-about-learning). Carry the classification into the transition and lifecycle below.
 
 **On `rejection-reclaim`, reflect before re-implementing** (per `rejection-detection`): read the rejection evidence through the access layer — the ticket comments posted after the backward transition (the QA rejection comment) via `lisa-atlassian-access operation: read-ticket` / `comment` reads and the review threads on the rejected PR — assemble ONE candidate learning (rule, why, provenance linking the rejection comment + rejected PR, evidence links, scope hint, triggering issue, fingerprint `sll4-sha1(rule\ntriggering_issue)[:12]`), and route it to the `lisa-persist-learning` skill. If that skill is absent, record the candidate via `lisa-atlassian-access operation: comment` as a comment carrying a **visible prose line plus** the marker (a bare marker renders as an empty bubble) — `Recorded a candidate learning from this rejection (queued for the judgment gate): <one-line candidate rule>.` then `<!-- [lisa-rejection-candidate] key=<issue>-<transition-ts> -->` — and proceed. Dedupe on `<issue>-<backward-transition-timestamp>` — a second re-claim produces no duplicate. Unreadable/absent evidence → no candidate, still implement.

package/plugins/lisa-cursor/skills/lisa-jira-write-ticket/SKILL.md

@@ -6,6 +6,12 @@ allowed-tools: ["Bash", "Skill"]
 
 # Write JIRA Ticket: $ARGUMENTS
 
+On runtimes without the rule tree (Antigravity), read **Worth doing** in `lisa-track` for the same value and decline policy.
+
+## Before creating incidental work
+
+Apply `do-it-now`'s **Worth doing** guidance before drafting a new incidental item. Decline low-value observations without writing a ticket or requesting a human gate; report the reason briefly to the caller. A complete spec is not evidence of value. This does not cancel explicit user requests or accepted requirements. Honor prior Not planned decisions through `rejection-detection`, including legacy issues without markers. Accepted work continues through the existing validation and readiness contract below.
+
 ## Human-gate release authorization
 
 A release requires a trusted human author, not just matching comment text. Follow

package/plugins/lisa-cursor/skills/lisa-learnings-audit/SKILL.md

@@ -285,7 +285,7 @@ resolved by reading the ticket, never by filing a sibling blind. Then:
 - **Closed via merged work** → done; a genuine regression later is new
   evidence and a new ticket.
 - **Closed unmerged / rejected** → the human declined. **Do NOT re-file**
-  unless new evidence **postdates the rejection** — and when re-filing, state
+  unless new evidence **postdates the rejection** and materially changes the consequence, requirement, or risk that justified the decline — and when re-filing, state
   the postdating evidence explicitly in the ticket ("rejected <date>; recurred
   <date> in <ref>"). Closed-as-rejected tickets ARE the gardener's memory of
   declined recommendations.
@@ -413,7 +413,7 @@ automation, through `lisa-tracker-write` (per `tracked-work` +
   visible prose line; matched on the marker, never the title; searched **open
   AND closed** per `rejection-detection`'s **Proposal rejection memory**. Treat
   matches by close state: **open** suppresses another proposal; **Not planned**
-  suppresses another proposal unless new evidence postdates the rejection;
+  suppresses another proposal unless new evidence postdates the rejection and materially changes the consequence, requirement, or risk that justified the decline;
   **Completed** means the prior approved action happened, so a later recurrence
   may be re-filed. The `[lisa-gardener]` search above stays what it is — the
   candidate evidence, not the dedupe key. When an existing proposal suppresses

package/plugins/lisa-cursor/skills/lisa-linear-build-intake/SKILL.md

@@ -344,6 +344,9 @@ This gate never blocks a legitimate flat Task/Bug: those have no open children a
 
 #### 3b. Claim
 
+Before the claim mutation, apply `claim-time-guards` — **Value before claim**, or **Worth doing** in `lisa-track` on runtimes without the rule tree (Antigravity). A ready label establishes neither value nor permission to expand scope. Respect the preceding human-hold gate; a declined incidental item consumes this cycle's one processed disposition.
+
+
 **Rejection detection runs first — before the transition below.** Per the vendor-neutral `rejection-detection` rule (cite the slug; do not restate its classification table), classify this Issue at the **top of 3b, BEFORE** the `$READY → $CLAIMED` transition — afterwards the current-lane signal is gone. Read the Issue's history via `lisa-linear-access operation: history id: <ISSUE-ID>`, keyed on **workflow-state** history, and classify it `rejection-reclaim | forward-only | never-left-ready | unknown` (a `rejection-reclaim` is a move back into `$READY` from a later lane). State names come from `.lisa.config.json`, never hardcoded.
 
 > Reading state history is strictly simpler than the label history this used to key on: `IssueHistory` inlines `fromState.name` / `toState.name` on each node, so the transition is read directly with no label-ID resolution against `list-issue-labels` and no reconstruction from `addedLabelIds`/`removedLabelIds` deltas. That reconstruction was lossy — the deltas carry no prior/next full set — which is one more reason the build lane moved to states. A failing/absent history yields `unknown` and the claim proceeds — detection never blocks the build. Issues carrying a learning marker (`[lisa-learning-drop]` / `[lisa-learning-pr]` / `[lisa-learning-upstream-handoff]`) or the `learning:needs-triage` label are never rejection triggers (no learning-about-learning). Carry the classification into the transition and lifecycle below.

package/plugins/lisa-cursor/skills/lisa-linear-write-issue/SKILL.md

@@ -6,6 +6,12 @@ allowed-tools: ["Bash", "Skill"]
 
 # Write Linear Work Item: $ARGUMENTS
 
+On runtimes without the rule tree (Antigravity), read **Worth doing** in `lisa-track` for the same value and decline policy.
+
+## Before creating incidental work
+
+Apply `do-it-now`'s **Worth doing** guidance before drafting a new incidental item. Decline low-value observations without writing a ticket or requesting a human gate; report the reason briefly to the caller. A complete spec is not evidence of value. This does not cancel explicit user requests or accepted requirements. Honor prior Not planned decisions through `rejection-detection`, including legacy issues without markers. Accepted work continues through the existing validation and readiness contract below.
+
 ## Human-gate release authorization
 
 A release requires a trusted human author, not just matching comment text. Follow

package/plugins/lisa-cursor/skills/lisa-monitor/SKILL.md

@@ -200,7 +200,7 @@ watching it. Evaluate all three. When all three hold, record `policy-obsolete` a
 - **Marker** `<!-- [lisa-automation-retire] key=monitor -->` plus a visible prose line; matched on
   the marker, never the title; searched **open AND closed** per `rejection-detection`'s **Proposal
   rejection memory**. Treat matches by close state: **open** suppresses another proposal;
-  **Not planned** suppresses another proposal unless new evidence postdates the rejection;
+  **Not planned** suppresses another proposal unless new evidence postdates the rejection and materially changes the consequence, requirement, or risk that justified the decline;
   **Completed** means the prior approved action happened, so a later recurrence may be re-filed.
   When an existing proposal suppresses filing, **the run still records `policy-obsolete` and files
   nothing** — the outcome describes this run, while the ticket is filed exactly once.

package/plugins/lisa-cursor/skills/lisa-persist-learning/SKILL.md

@@ -9,6 +9,8 @@ Route ONE candidate learning through the judgment gate and act on the verdict. C
 
 Most candidates are dropped — that is the gate working, not a failure. Nothing is ever silent (every drop leaves a visible note), and no learning content ever reaches the learnings surface outside a pull request.
 
+On runtimes without the rule tree (Antigravity), read **Worth doing** in `lisa-track` for the same value and decline policy.
+
 ## Candidate Input
 
 Accept the candidate as JSON or `key=value` fields:
@@ -68,7 +70,9 @@ The note is one line naming the classification (with its fixed plain-language gl
 
 ### `handoff-upstream` (classification `lisa-upstream`)
 
-This disposition completes the SLL-5 loop (#1583): on a Lisa-attributed failure the upstream Lisa ticket is filed **automatically**. Filing lives here — not in `lisa-attribute-failure` — because that skill is deliberately read-only (doctor delegates to it inside its own read-only contract), while this skill already owns exactly the verdict's side effects and the marker-dedupe discipline. Never persist a local rule for a Lisa-attributed failure; the host project's only durable trace is the brief linking note in step 6.
+This disposition completes the SLL-5 loop (#1583): on an accepted worthwhile Lisa-attributed failure the upstream Lisa ticket is filed **automatically**. Filing lives here — not in `lisa-attribute-failure` — because that skill is deliberately read-only (doctor delegates to it inside its own read-only contract), while this skill already owns exactly the verdict's side effects and the marker-dedupe discipline. Never persist a local rule for a Lisa-attributed failure; the host project's only durable trace is the brief linking note in step 6.
+
+First apply `do-it-now`'s **Worth doing** guidance. Attribution establishes ownership, not value. Decline low-value additional hardening in the current summary without filing, persisting a rule, or asking a human; otherwise continue below. Before creating an upstream issue, consult `rejection-detection` for open and closed matches, including legacy unmarked declines.
 
 1. **Post the handoff marker** on the triggering issue (same one-comment marker dedupe; the marker key is unchanged). The visible line must not claim a filing that has not happened yet — attribution and filing come after this step:
 

package/plugins/lisa-cursor/skills/lisa-prd-source-write/SKILL.md

@@ -38,6 +38,7 @@ ideation_ledger_payload:              # optional; forwarded unchanged to the ven
   selected_idea: "<selected idea title/key>"
   rejected_overlap_candidates: ["<issue refs/titles considered and rejected>"]
   expected_empirical_verification_artifact: "<artifact ref or unavailable>"
+  reproposal_context: "<optional dated decline, new evidence, changed consequence, token and acknowledgment already included in the PRD body by research>"
 ```
 
 `initial_role` semantics are uniform across vendors (the role STRINGS resolve per vendor from

package/plugins/lisa-cursor/skills/lisa-project-ideation/SKILL.md

@@ -207,7 +207,10 @@ For each idea in the creation set, invoke `/lisa:research` with:
 - a structured `ideation_ledger_payload` handoff containing the selected marker, automation id and
   memory path when available, persona names, persona evidence references, rejected overlap
   candidates, repo identity, `prd_ready`, selected idea title/key, and the expected empirical
-  verification artifact. This payload is the only ideation-run metadata channel between
+  verification artifact. For a justified re-proposal, include `reproposal_context`: the dated
+  decline, dated new evidence reference, materially changed consequence, and the exact machine
+  token and human acknowledgment paragraph specified below. Research must include that paragraph
+  and token in the PRD body. This payload is the only ideation-run metadata channel between
   `project-ideation`, `research`, `prd-source-write`, and the vendor writer; keep GitHub-specific
   rendering out of this skill.
 
@@ -249,10 +252,9 @@ Per the `rejection-detection` rule's **Proposal rejection memory** section, that
 cover **open AND closed** PRDs (with a body-enumeration fallback on search-index lag), and a PRD
 **closed as _not planned_** (GitHub `stateReason == "not_planned"`; the config-resolved won't-do/
 canceled equivalent on JIRA/Linear — never a hardcoded lane string) is a **durable human decline**
-that **suppresses** re-proposing that idea. Re-propose only with evidence that **postdates the
+that **suppresses** re-proposing that idea. Re-propose only for a materially changed consequence, requirement, or risk addressing the decline, supported by evidence that **postdates the
 decline**, and state it in the new PRD as BOTH the machine token (`declined <date>; recurred <date>
-in <ref>`) and a human acknowledgment sentence (`You declined this on <date>. It has recurred
-(<date>, <ref>), so we're raising it once more for your review.`). A PRD closed as _completed_ is
+in <ref>`) and a human acknowledgment sentence (`You declined this on <date>. New evidence (<date>, <ref>) changes the consequence, requirement, or risk: <what changed and why the decline no longer applies>.`). A PRD closed as _completed_ is
 not a decline. This is tracker-side memory; the advisory ideation memory ledger stays advisory and
 never overrides it.
 
@@ -350,7 +352,7 @@ marker-deduped teardown proposal through `lisa-tracker-write` (per `tracked-work
 - **Marker** `<!-- [lisa-automation-retire] key=exploratory-prds -->` plus a visible prose line;
   matched on the marker, never the title; searched **open AND closed** per `rejection-detection`'s
   **Proposal rejection memory**. Treat matches by close state: **open** suppresses another proposal;
-  **Not planned** suppresses another proposal unless new evidence postdates the rejection;
+  **Not planned** suppresses another proposal unless new evidence postdates the rejection and materially changes the consequence, requirement, or risk that justified the decline;
   **Completed** means the prior approved action happened, so a later recurrence may be re-filed.
   When an existing proposal suppresses filing, **the run still records `policy-obsolete` and files
   nothing** — the outcome describes this run, while the ticket is filed exactly once.

package/plugins/lisa-cursor/skills/lisa-repair-intake/SKILL.md

@@ -586,10 +586,9 @@ rule's **Proposal rejection memory** section, that marker search MUST cover **op
 tickets (body-enumeration fallback on search-index lag): an **open** match → reference it and ensure
 the `is blocked by` link is present rather than creating a duplicate; a match **closed as _not
 planned_** (GitHub `stateReason == "not_planned"`; the config-resolved equivalent on JIRA/Linear) is
-a **human decline** of that fix ticket — do **not** re-file it unless evidence **postdates the
+a **human decline** of that fix ticket — do **not** re-file it without a materially changed consequence, requirement, or risk addressing the decline, supported by evidence that **postdates the
 decline**, and the re-filed ticket MUST carry BOTH the machine token (`declined <date>; recurred
-<date> in <ref>`) and the human acknowledgment sentence (`You declined this on <date>. It has
-recurred (<date>, <ref>), so we're raising it once more for your review.`); a match closed as
+<date> in <ref>`) and the human acknowledgment sentence (`You declined this on <date>. New evidence (<date>, <ref>) changes the consequence, requirement, or risk: <what changed and why the decline no longer applies>.`); a match closed as
 _completed_ is a regression path, not a decline. Honor the backoff window and state fingerprint
 (Loop prevention) so re-runs over the same unchanged blocker are no-ops.
 

package/plugins/lisa-cursor/skills/lisa-research/SKILL.md

@@ -20,8 +20,12 @@ Produce a PRD for the problem in `$ARGUMENTS`, then create it in the configured
   structured metadata object to forward unchanged to `lisa-prd-source-write`. It carries the
   selected marker, automation id/path when available, persona names, persona evidence references,
   rejected overlap candidates, repo identity, `prd_ready`, selected idea title/key, and expected
-  empirical verification artifact. `research` may use these fields to inform the PRD body, but must
-  not discard, rename, or vendor-render them.
+  empirical verification artifact. When supplied, `reproposal_context` contains the dated decline,
+  new evidence, changed consequence, and the required machine token and human acknowledgment.
+  Include that token and acknowledgment verbatim in the synthesized PRD body before source routing,
+  so the justification survives even when the vendor's metadata renderer does not display this field.
+  Other metadata may inform the PRD body; forward the complete payload unchanged without renaming
+  or vendor-rendering its fields.
 
 ## Orchestration: agent team
 

package/plugins/lisa-cursor/skills/lisa-rework-triage/SKILL.md

@@ -6,16 +6,14 @@ allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
 
 # Rework Triage: $ARGUMENTS
 
-Classify why a previous agent attempt at this ticket failed, and convert that cause into a
-structural improvement. This is the self-hardening arm of the lifecycle: every classified
-failure either hardens the harness (an upstream Lisa issue), the project (a provisioning or
-environment ticket), or the spec (a PRD defect flag). A rework cycle that fixes the bug but
-never asks *why the agent got it wrong* guarantees the mistake recurs.
+Classify why the previous attempt failed and repair the actual cause. Apply `do-it-now`'s **Worth doing** guidance before proposing additional hardening. Fixing the defect and its relevant regression test can be sufficient; a failure does not automatically justify another rule, hook, or upstream ticket.
 
 The caller MUST have run `lisa-tracker-read` first and provided the context bundle (all
 comments chronological, linked PRs with review state, issue links, parent epic). Do not
 classify from a bare summary — evidence-free classification is worse than none.
 
+On runtimes without the rule tree (Antigravity), read **Worth doing** in `lisa-track` for the same value and decline policy.
+
 ## Phase 1 — Rework detection
 
 A ticket is **rework** when it was previously implemented by this lifecycle and has returned
@@ -115,7 +113,12 @@ never one per cycle re-entry.
 
 ## Phase 4 — Route the cause to its hardening destination
 
-Each cause has exactly one destination. File through the proper write path — never raw
+For each primary or secondary cause, first decide whether additional work clears
+`do-it-now`'s **Worth doing** bar. If not, report `Hardening action: none required`
+with a brief reason in the existing triage comment. Do not create a replacement
+learning or a human gate merely to retain the declined observation.
+
+The table gives destinations for accepted additional work. File through the proper write path — never raw
 ticket creation — so every hardening artifact passes the same quality gates as any other
 Lisa work item.
 
@@ -128,7 +131,7 @@ Lisa work item.
 | `prd-defect` | Source PRD | Comment on the PRD (via the `lisa-prd-backlink` lineage) quoting the defective requirement and the QA failure; flag for product review. Do NOT silently edit the PRD — spec changes are a human gate. |
 | `implementation-defect` (no secondary) | None | Normal fix path; the classification comment is the record. Pass the pattern to the `learner` phase — repeated implementation defects of the same shape escalate to `verification-gap`. |
 
-**Secondary causes route too.** A recorded secondary cause triggers its own row's
+**Secondary causes route too — when worthwhile.** A worthwhile secondary cause uses its row's
 destination in addition to the primary's: `implementation-defect` with a
 `verification-gap` secondary files the upstream Lisa issue per the `verification-gap`
 row — the code being wrong does not excuse the verification lifecycle for passing it.
@@ -151,16 +154,16 @@ section differ:
 | Defect | `self-hardening` | A Lisa gate/skill/template did something wrong — a harness bug the kernel must fix. | none |
 | Contribution | `template-candidate` | A generalizable pattern discovered downstream that would benefit every host project — not a defect, a proposed improvement to Lisa's templates/rules/skills. | `## Proposed template change` |
 
-1. **Dedupe first.** `gh issue list -R <upstream> --state open --search "<fingerprint terms>"`
+1. **Dedupe first.** Search open AND closed items and consult `rejection-detection`'s **Proposal rejection memory**, including legacy issues without markers. `gh issue list -R <upstream> --state all --search "<fingerprint terms>"`
    — if an open issue already covers this failure class or pattern, comment the new
    occurrence on it (evidence compounds; duplicates dilute) and link it instead of filing.
 2. **File with the same bar as any ticket:** a three-audience description (what failed or
    improved for the operator, what the harness did or could do, what to change), the
-   verbatim evidence chain (PRD text → ticket AC → QA failure → gate that passed it; for
-   patterns, the downstream occurrences proving generality), and the lane's label:
-   `gh issue create -R <upstream> --title "<gate/skill>: <failure class>" --label self-hardening`
-   for defects, or
-   `gh issue create -R <upstream> --title "<template surface>: <pattern>" --label template-candidate`
+   public-safe evidence chain (PRD text → ticket AC → QA failure → gate that passed it; for
+   patterns, the occurrences proving generality). Invoke `lisa-github-write-issue` against
+   `<upstream>` using the existing public-safe attribution/projection procedure from
+   `upstream-to-lisa`. Pass `build_ready: true` unless an explicit `human_gate` was declared,
+   then pass that reason instead. Use label `self-hardening` for defects or `template-candidate`
    for contributions. A `template-candidate` filing MUST include a
    `## Proposed template change` section naming the Lisa template/rule/skill surface to
    change (e.g. `typescript/package-lisa/package.lisa.json`, a `plugins/src/base` rule)

package/plugins/lisa-cursor/skills/lisa-track/SKILL.md

@@ -22,7 +22,23 @@ continue through the existing path and never override an independently declared
 
 Establish the tracked-work invariant before any durable project mutation. Discussion and read-only orientation may proceed without this skill; code, configuration, documentation, research artifacts, plans, investigation findings, tests, commits, and pull requests may not.
 
-This flow must return exactly one canonical `(tracker_provider, work_item_ref)` pair or fail closed. It never returns an unvalidated textual guess.
+For accepted work this flow must return exactly one canonical `(tracker_provider, work_item_ref)` pair or fail closed. A declined incidental finding returns only its reason and authorizes no durable implementation. It never returns an unvalidated textual guess.
+
+## Worth doing
+
+Before filing, promoting, or claiming an incidental finding, ask whether the expected benefit justifies implementation, verification, maintenance, CI, and operator attention. Use the evidence already available; no numeric score, new tracking system, or speculative audit is required.
+
+- **Act** on concrete delivery failures, incorrect results, credible material security or data-loss risks, and recurring friction whose repair is worth its cost. A small fix can have a large consequence; security need not wait for an incident.
+- **Bundle** related small repairs when one bounded maintenance task is worth doing. Reuse an existing relevant item where possible. Do not expand unrelated work or create one ticket per wording fix.
+- **Decline** cosmetic preferences, speculative edge cases, duplicate controls, or changes whose likely benefit is smaller than their ongoing cost. Acceptable as-is is a valid engineering decision. Say why briefly in the current report, review, or issue; do not create a ticket, ledger entry, new rule, or human gate merely to record a declined observation.
+
+A reproducible imperfection proves that something happens, not that it deserves factory capacity. A complete specification establishes buildability, not value. Missing enforcement or test coverage alone does not justify new machinery; name the required behavior or credible consequence at risk. Honor explicit user requests, accepted product requirements, and material safety obligations. This rule cannot silently cancel those commitments or excuse failing required checks.
+
+## Prefer less machinery
+
+Start with the smallest sufficient correction at the owning component. Consider removing or consolidating redundant machinery before adding a hook, workflow, abstraction, registry, or test framework. Preserve required behavior and protection, and verify the consequence of the change. An isolated failure does not automatically justify a permanent control for every future session.
+
+For an existing incidental item, read its discussion, linked PRs and dependencies before declining. Close as **Not planned** (configured Jira/Linear equivalent), give the reason, and remove active lifecycle labels. Preserve human holds and committed scope unless cancellation is authorized; resolve effects on active PRs and dependent delivery first. Before re-filing, search open AND closed issues, read legacy unmarked matches, and require materially changed consequences that address the earlier reason. A later observation of the same accepted limitation is insufficient.
 
 ## Phase 1 — Resolve tracker and classify input
 
@@ -42,14 +58,16 @@ Invoke `lisa-tracker-read <ref>` and require a live result from the configured p
 
 ### File or plain text
 
+For incidental findings, apply `do-it-now` before resolving a new leaf. If the finding is declined, return the reason without creating or claiming anything; durable implementation does not start. Explicit user requests and accepted requirements remain in scope.
+
 Search conservatively before creating:
 
 1. Normalize the requested outcome and derive a short keyword set; never search with the whole prompt or secrets.
-2. Search only open/non-terminal items in the configured project and current repository through the configured provider's documented read surface:
-   - GitHub: `gh issue list --repo <org>/<repo> --state open --search "<keywords> in:title,body"`.
-   - Jira: `lisa-atlassian-access operation: search-issues` with project-scoped JQL.
-   - Linear: `lisa-linear-access operation: list-issues` scoped to the configured team/workspace.
-3. Treat search results as candidates, never proof. Live-read each plausible candidate through `lisa-tracker-read`, and discard terminal, container, blocked, held-by-gate, cross-repo, and materially different outcomes. A held candidate is never reused: attaching new work to an item a human is holding is how the hold gets spent.
+2. Search open AND closed items in the configured project and current repository through the configured provider's documented read surface. Closed items supply decision history, never an active binding:
+   - GitHub: `gh issue list --repo <org>/<repo> --state all --search "<keywords> in:title,body"`.
+   - Jira: `lisa-atlassian-access operation: search-issues` with project-scoped JQL and no status filter.
+   - Linear: `lisa-linear-access operation: list-issues` scoped to the configured team/workspace and including all states.
+3. Treat search results as candidates, never proof. Live-read each plausible candidate and its discussion through `lisa-tracker-read`. Apply `rejection-detection` to prior **Not planned** decisions, including legacy unmarked matches, before creating: suppress the same accepted limitation unless materially changed post-decline evidence addresses its reason, with the required token and acknowledgment in any new item. A completed fix may have a verified regression. For active binding, discard terminal, container, blocked, held-by-gate, cross-repo, and materially different outcomes. A held candidate is never reused: attaching new work to an item a human is holding is how the hold gets spent.
 4. Reuse only when **exactly one** live leaf is a high-confidence semantic match for the same requested outcome and repository. A shared keyword or similar title is not enough. Record the search queries, candidates, and rejection reasons in the returned resolution evidence.
 5. If there is no unique high-confidence match (zero or ambiguous candidates), create **exactly one** item by invoking `lisa-tracker-write` once. Synthesize one complete single-repository leaf (`Bug`, `Task`, `Sub-task`, or `Improvement`, never Epic/container) with the writer's required three-audience body, Gherkin acceptance criteria, repository, target environment, relationship search, and executable Validation Journey. Pass `build_ready: true` unless the caller declared a `human_gate`, in which case pass that `human_gate: "<why>"` reason instead of `build_ready: true` and never alongside it, so the writer leaves the leaf in the tracker's default backlog role — out of the lane build-intake claims from — and stamps the hold on the body as a `[lisa-human-gate]` marker. Discarding a declared gate and filing build-ready anyway is the one outcome this step must never produce. Do not create placeholder/thin tickets, do not create a hierarchy, and do not retry creation by making another item if validation fails; repair the proposed spec and retry the same writer operation only if the vendor contract supports idempotent reuse.
 6. Live-read the writer's canonical returned reference with `lisa-tracker-read`. A create response without a verified live leaf is failure.

package/plugins/lisa-expo/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.55.5",
+  "version": "4.55.7",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.55.5",
+  "version": "4.55.7",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo/.codex-plugin/skills/e2e-coverage-gaps/SKILL.md

@@ -5,12 +5,14 @@ description: "Playwright/e2e coverage-gap…"
 
 # E2E Coverage Gaps
 
+On runtimes without the rule tree (Antigravity), read **Worth doing** in `lisa-track` for the same value and decline policy.
+
 ## Overview
 
 Find where the automated end-to-end (Playwright) suite is **blind**: routes with no test at all, and
 flows that only assert the **happy path** while ignoring error, permission, empty, loading, and edge
 cases. Inventory the app's routes and the existing tests, explore the running app to confirm each gap
-is real and reachable, then file each gap as a **build-ready missing-test work item** so it enters the
+is real and reachable, then group worthwhile gaps into **bounded build-ready missing-test work items** so it enters the
 Lisa lifecycle.
 
 This skill is purely about **automated-coverage gaps**. It does not judge whether the UI is confusing
@@ -62,15 +64,18 @@ Map routes/flows against existing coverage and classify each gap:
 
 ### 5. Explore to Confirm
 
+- Apply `do-it-now`'s **Worth doing** guidance: missing coverage alone is not a defect. Identify a required behavior or credible material risk; decline low-value gaps without filing and group related accepted gaps.
 - Navigate each candidate gap in the running app to confirm it is real, reachable, and worth a test.
   Discard gaps that aren't actually reachable or are intentionally out of scope.
 
-### 6. File One Ticket Per Gap
+### 6. File Bounded Work for Accepted Gaps
 
-Each confirmed gap becomes a leaf **missing-test** work item created via `lisa-tracker-write` (the
+Each accepted gap or coherent group becomes a leaf **missing-test** work item created via `lisa-tracker-write` (the
 vendor-neutral writer — it dispatches to the configured tracker and runs the validation gate; never
 call a vendor `*-write-*` skill directly), `issue_type: Task`, **build-ready per the `ready` flag
-(default `true`)**. Pass `build_ready` explicitly on every create. Each ticket MUST specify:
+(default `true`)**. For `ready=true`, pass `build_ready: true`. For `ready=false`,
+pass `human_gate: "Coverage work explicitly held for operator prioritization"` instead.
+Each ticket MUST specify:
 
 - The **route/flow** and the exact **user behavior the test must assert**.
 - **Which scenario is missing** (uncovered vs which non-happy path: error / validation / permission /
@@ -80,11 +85,18 @@ call a vendor `*-write-*` skill directly), `issue_type: Task`, **build-ready per
 
 ### Idempotency — don't spam duplicates
 
-Before creating a ticket, search the tracker for an **open** ticket carrying a stable marker
-`[lisa-e2e-coverage-gaps] <gap-key>` in its body (the `<gap-key>` is a stable slug of route + missing
-scenario, e.g. `checkout/payment-declined` or `dashboard/empty-state@mobile`). If one exists, reference
-it instead of duplicating. **Match by the marker, never by title.** A *closed* prior ticket does not
-suppress a genuine new gap.
+Before creating a ticket, follow `rejection-detection` — **Proposal rejection memory**:
+use `<!-- [lisa-e2e-coverage-gaps] key=<candidate-key> -->` with the normalized route +
+missing scenario hashed deterministically by that rule's existing formula. Search open AND
+closed tickets, including its body-enumeration fallback for search-index lag. Match by the
+marker for any constituent gap, never by title alone. Reuse open matches. For legacy issues
+without a marker or with the older `[lisa-e2e-coverage-gaps] <gap-key>` slug marker, read
+bodies and closing discussions to establish a semantic match; title similarity
+alone is insufficient. A **Not planned** decision suppresses the same accepted
+limitation, even when seen again later. Re-propose only for a materially changed
+consequence, requirement, or risk that addresses the decline. A completed fix may
+have a real regression, which must be verified before filing. Grouped work retains
+the constituent gap markers so a later pass can find it.
 
 ## Output
 

package/plugins/lisa-expo/.codex-plugin/skills/lisa-e2e-coverage-gaps/SKILL.md

@@ -10,4 +10,4 @@ description: "Explore gaps in the automated…"
 - Claude argument hint: `[target-url | env] [ready=true|false]`
 - Claude allowed tools: `Skill`. Codex tool access is governed by the active Codex runtime and project policy.
 
-Use the /lisa-expo:e2e-coverage-gaps skill to inventory the app's routes and the existing Playwright suite, find uncovered and happy-path-only paths, confirm each gap in the running app, and file one build-ready missing-test ticket per gap via lisa:tracker-write (build-ready per the ready flag, default true). For human usability/experience findings, use /lisa:exploratory-qa. Use the user's surrounding request as this command's arguments.
+Use the /lisa-expo:e2e-coverage-gaps skill to inventory the app's routes and the existing Playwright suite, find uncovered and happy-path-only paths, confirm each gap in the running app, and file bounded build-ready work for worthwhile test gaps via lisa:tracker-write (build-ready per the ready flag, default true). For human usability/experience findings, use /lisa:exploratory-qa. Use the user's surrounding request as this command's arguments.

package/plugins/lisa-expo/commands/e2e-coverage-gaps.md

@@ -1,7 +1,7 @@
 ---
-description: "Explore gaps in the automated Playwright/e2e suite: inventory the app's routes and existing tests, find routes with no coverage or flows tested only on the happy path (missing error, permission, empty, loading, and edge cases), confirm each in the running app, and file one build-ready missing-test ticket per gap via lisa:tracker-write. The optional ready flag (default true) controls build-ready vs backlog. For human usability issues, use exploratory-qa instead."
+description: "Explore gaps in the automated Playwright/e2e suite: inventory the app's routes and existing tests, find routes with no coverage or flows tested only on the happy path (missing error, permission, empty, loading, and edge cases), confirm each in the running app, and file bounded build-ready work for worthwhile test gaps via lisa:tracker-write. The optional ready flag (default true) controls build-ready vs backlog. For human usability issues, use exploratory-qa instead."
 allowed-tools: ["Skill"]
 argument-hint: "[target-url | env] [ready=true|false]"
 ---
 
-Use the /lisa-expo:e2e-coverage-gaps skill to inventory the app's routes and the existing Playwright suite, find uncovered and happy-path-only paths, confirm each gap in the running app, and file one build-ready missing-test ticket per gap via lisa:tracker-write (build-ready per the ready flag, default true). For human usability/experience findings, use /lisa:exploratory-qa. $ARGUMENTS
+Use the /lisa-expo:e2e-coverage-gaps skill to inventory the app's routes and the existing Playwright suite, find uncovered and happy-path-only paths, confirm each gap in the running app, and file bounded build-ready work for worthwhile test gaps via lisa:tracker-write (build-ready per the ready flag, default true). For human usability/experience findings, use /lisa:exploratory-qa. $ARGUMENTS