@codyswann/lisa 4.74.9 → 4.75.0

package/plugins/lisa-devin/skills/lisa-epic-triage/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: lisa-epic-triage
+description: "9-step epic triage and 5-step implementation workflow. Ensures epics are fully scoped, broken down, and ordered before execution begins."
+---
+
+# Epic Triage
+
+Follow this 9-step triage process before implementing any epic. Do not skip triage.
+
+## Triage Steps
+
+1. Verify you have all information needed to understand the full scope of this epic (goals, acceptance criteria, impacted systems, design specs, dependencies, etc.). Do not make assumptions. If anything is missing, stop and ask before proceeding.
+2. Verify the epic is broken down into concrete, well-scoped bugs, tasks, and/or stories that are each fully triaged. If ambiguities exist, stop and resolve them before breaking it down.
+3. Identify all cross-cutting concerns (auth, performance, security, data migrations, third-party integrations) that need to be addressed across the epic.
+4. Identify all dependencies between tasks within the epic, or on external epics, teams, or services. Determine the correct order of execution.
+5. Verify you have access to the tools, environments, and permissions needed to deploy and verify all tasks within this epic (e.g. CI/CD pipelines, deployment targets, logging/monitoring systems, API access, database access). If any are missing or inaccessible, stop and raise them before proceeding.
+6. Define the overall test strategy for the epic (unit, integration, end-to-end, load testing).
+7. Define the documentation that will need to be created or updated to cover the full scope of the epic so another developer understands the architecture, design decisions, and implementation.
+8. Define measurable acceptance criteria that confirm the epic is fully complete.
+9. Define how you will verify the epic is fully delivered beyond a shadow of a doubt (e.g. deploy to the target environment, walk through all acceptance criteria end-to-end, confirm all child tasks/stories are closed, confirm no regressions).
+
+## Implementation
+
+1. Use the output of the triage steps above as your guide. Do not skip triage.
+2. Work through each task and/or story in the order defined during triage, respecting dependencies.
+3. Apply the Bug Implementation and Task Implementation processes to each child bug or task, respectively, as you work through them.
+4. Continuously update the epic and its child issues in JIRA as progress is made.
+5. Do not consider the epic complete until all acceptance criteria are verified in the target environment and all child issues are resolved.

package/plugins/lisa-devin/skills/lisa-evaluation-suite/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: lisa-evaluation-suite
+description: "Build and maintain the entity's own task suite for qualifying agent, model, prompt and effort-level changes — drawn from real work, kept representative, protected from contamination, and checked for the discriminating power that makes a result mean something."
+allowed-tools: ["Read", "Grep", "Glob", "Bash"]
+---
+
+# Evaluation Suite
+
+Public leaderboards measure somebody else's work mix. The suite that decides what runs in your factory is assembled from your own.
+
+## Draw the tasks from real work
+
+A task earns a place by having happened. Pull candidates from closed work items, past incidents, escaped defects, and the reviews that caught something — anywhere the outcome is already known and was consequential.
+
+Include, deliberately, the work your current setup handles **badly**. A suite made only of tasks that already pass measures nothing: every candidate scores full marks and the result cannot separate them. Difficulty is what carries information, so keep the tasks that embarrass the fleet and record what "good" would have looked like.
+
+Each task records: what is asked, what counts as success and how that is judged, where the task came from, and the outcome class it exercises. Without the judging rule written down, two runs of the same task are not comparable.
+
+## Keep it resembling the work
+
+Representativeness expires. Review it on a declared cadence and re-establish it whenever the work mix moves — a new stack, a new surface, a shift from features to migrations. A suite that has drifted from the work stops being evidence about the work while continuing to produce confident numbers, which is the worst failure mode available to an instrument.
+
+State the review date alongside every result. A reader has to be able to see how old the instrument is.
+
+## Contamination is the failure that hides
+
+The tasks and their expected outcomes MUST be unreachable by the agents under evaluation. That means not in instruction files, not in skills, not in retrievable context, not in a wiki the agents read, and not in feedback or transcripts submitted to a model vendor.
+
+An agent optimising against a suite it can see produces a score rather than a measurement, and nothing in the number reveals which one you have. Treat any suspected exposure as fatal to the affected tasks: retire them, record why, and replace them from real work. Where exposure cannot be ruled out for the whole suite, say so — a compromised instrument reported honestly still tells you something; one reported as clean does not.
+
+## Check that it discriminates
+
+Before trusting a comparison, look at the spread of results across candidates:
+
+| What you see | What it means |
+| --- | --- |
+| Nearly every task passes for every candidate | Saturated. It cannot rank anything; add harder tasks |
+| Nearly every task fails for every candidate | Out of range. The suite is measuring something other than the difference you care about |
+| A handful of tasks decide the whole ordering | Fragile. Swapping any one of them would flip the result — say so with the result |
+| Spreads overlap between candidates | Not distinguished, whatever the means say |
+
+## Qualify a change against it
+
+A qualification states, before the runs: how many runs per condition, the statistic expressing spread, and the threshold that constitutes a pass. Report the distribution rather than a mean, and treat the pinned operating configuration — model, reasoning or effort level, tools, context — as part of the condition, since results are not monotonic in effort and a change to any of them is a different candidate.
+
+Third-party benchmark rankings and vendor claims are not admissible here. They measure a different task mix at a precision their own run-to-run variance does not support.
+
+## Output
+
+```text
+## Evaluation Suite
+
+**Tasks:** n | **Representativeness reviewed:** date | **Contamination:** controlled / suspected / unknown
+**Discrimination:** healthy | saturated | out-of-range | fragile (deciding tasks: …)
+
+### Result — per condition
+| Condition (model · effort · tools) | Runs | Outcome distribution | Spread |
+|---|---|---|---|
+
+**Protocol declared in advance:** runs per condition, spread statistic, pass threshold
+**Verdict:** qualified / not qualified / instrument unfit — with the reason
+**Uncollected:** any metric that could not be gathered, and why
+```

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

@@ -0,0 +1,185 @@
+---
+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 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`). 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.
+
+## Parameters
+
+- **`target-url | env`** (first positional) — what to explore (passed through to `use-the-product`).
+- **`ready=true|false`** — the build-ready state for the tickets this pass creates.
+  - `ready=true` → created build-ready, so `lisa-intake` / the build-intake scanner auto-picks them up.
+  - `ready=false` (**default**) → created in the backlog for a human to review and promote.
+
+## 1. Set up
+
+- **Invoke `use-the-product`** to detect the product type, resolve the environment + mutation policy, and discover personas/subagents. Everything about *how* to drive the product, *where*, and *how much you may mutate* comes from there — do not re-derive it.
+- For a DOM web app whose resolved non-production environment has mutation policy `full`, check the optional Kane provider with `lisa kane probe`. If ready, invoke `lisa-kane-browser` for self-contained journeys and use its screenshots, HAR/network, console, and normalized verdict as evidence. Keep the run on a directly controlled browser for `read-only`/`forbidden` environments. Treat `tool_failed`/`timed_out` as provider findings, never as product bugs.
+- **Confirm the tracker is configured.** Findings are filed as tickets, so read `tracker` from `.lisa.config.json` (local overrides global). If unset, stop and report that the tracker must be configured (`/lisa:setup:jira` / `:github` / `:linear`) before exploratory QA can file findings — do not silently fall back to a report file.
+- Read the `ready` flag (default `false`).
+
+## 2. Arrive cold and use it like a human
+
+- Start with **no prior knowledge** — do not pre-read the codebase to learn the intended flows; discover them the way a user would. Form a first impression: is it obvious what this product is, what to do first, and where to go next?
+- Then actually attempt real tasks through the interface (per `use-the-product`'s per-type playbook), exercising representative controls/endpoints/commands — a first-time user explores, makes mistakes, and tries the obvious thing.
+
+## 3. The QA lens — what to look for
+
+Cover at least these dimensions unless the user narrows scope. Most are universal; the web-specific ones are marked and have per-type equivalents in §4.
+
+- **Comprehension & labeling:** user-facing copy must read like something a normal first-time user understands. Flag machine-style/developer labels (raw IDs, enum keys, `snake_case`, `null`/`undefined`, untranslated i18n keys), admin/database terms ("metadata", "rows", "record", "entity"), unexplained jargon, unclear button/menu names, and meaningless icons. If a label would make a non-technical user ask "what does that mean?", file a clarity ticket.
+- **Data usefulness & context:** facts, metrics, and tables must help a person understand the surface, not just prove extraction happened. If a user can't tell what a number or field refers to without rereading the raw source, file a ticket to add context (excerpts, labels, grouping, provenance) or hide it.
+- **Data volume & trust:** compare visible data to what the surface promises. A rich view with only a few items can read as broken/filtered/still-loading. File a finding when sparse data isn't explained (result counts, active filters, reset affordances, coverage status, sample labeling).
+- **Controls & mental model:** controls must match what they do (sort ≠ filter; search ≠ facet; finite domains want selects/typeaheads, not blank text inputs). Flag controls that make users guess spelling/casing, hide the option universe, or use the wrong component.
+- **Flow completeness & expected counterparts:** a screen that gates access or shows one side of a standard paired flow must offer the other side, or a clear path to it. A new user must never hit a dead end with no next step. Flag: **sign-in with no sign-up** (or vice-versa), **no account recovery** ("Forgot password?", resend verification), **no exit from a state** (no sign-out; a modal/wizard with no back/close/cancel), **one-way actions** (create with no edit/delete where both are expected), **unreachable entry points** (a feature only reachable by guessing a URL; an empty state with no primary action). When the missing counterpart makes a core task impossible for a class of users, file a `Bug`; otherwise a usability `Improvement`.
+- **Action preconditions & incomplete end-states:** an action that needs multiple inputs or a prerequisite (compare, merge, bulk-edit) should guide the user to satisfy it — disable/explain until met, collect inputs first, or give the destination an in-place control. Actually trigger these and watch where they land; flag when a primary action fires under-satisfied and strands the user, lands on an empty/partial end-state with no next step, or is offered where it cannot succeed. Left unable to finish → `Bug`; works but confusing → `Improvement`.
+- **Navigation clarity:** is it obvious how to get somewhere and back? Flag dead ends, hidden entry points, surprising redirects, broken links, no clear "home", and duplicated nav that competes for space without page-specific value.
+- **Behavior correctness:** does the obvious action do what a user expects? Confusing errors, silent failures, disabled controls with no explanation, state that doesn't persist.
+- **Affordance clarity:** can the user tell what is clickable, required, in-progress, or complete?
+- **Load & responsiveness:** long/unclear loads, blank or skeleton-only shells, spinners with no progress. Flag surfaces that report "loaded" but where meaningful content arrives much later. Capture user-perceived timings (shell visible, first meaningful content, stable content); if the delay is noticeable, file it even when the eventual content is correct.
+- **Visual/layout quality (DOM web):** cut-off/truncated text, overlap, cramped density, offscreen controls, accidental horizontal scroll. **Do not judge by eyeballing a screenshot alone** — confirm with the layout-integrity sweep in §4.
+- **Consistency / standard UX:** components, spacing, terminology, and interaction patterns should be consistent and follow common conventions. Flag anything non-standard or screen-to-screen drift.
+
+## 4. Type-specific depth
+
+- **DOM web app — breakpoints & layout integrity.** Sweep a range of widths, including the *in-between* ones where clipping appears (e.g. 360, 390, 414, 600, 768, 834, 1024, 1280, 1440 plus ~900–1180 steps), and re-walk key paths at each. At every width, in addition to looking, take DOM measurements and treat as findings: **container overflow** (`documentElement.scrollWidth > clientWidth`); **clipped/offscreen controls** (a control's `getBoundingClientRect()` falling outside the viewport or an `overflow:hidden|clip|auto|scroll` ancestor — e.g. a submit button cut off by its filter card); **truncated meaningful text** (`scrollWidth > clientWidth` / ellipsis on text that carries meaning); **colliding controls** (label overlapping an adjacent control with no gap). A primary/interactive control that is clipped, offscreen, or unreachable is a **`Bug`**, not an Improvement.
+- **HTTP / API backend.** Judge the *contract as a consumer experiences it*: unclear/inconsistent status codes, error responses with no actionable message, payloads exposing internal shapes (raw enums, DB column names), missing pagination/among-counts, endpoints that 500 on obvious edge inputs. A broken/incorrect response is a `Bug`; a confusing-but-working contract is an `Improvement`.
+- **Canvas game.** Judge readability at gameplay scale, input responsiveness/latency, game-feel, unclear objectives, and silent state changes — not DOM breakpoints. A soft-lock or lost progress is a `Bug`; unclear-but-playable friction is an `Improvement`.
+- **CLI / library.** Judge help/output clarity, error messages, discoverability of commands, and surprising side effects. A wrong result / crash is a `Bug`; confusing UX is an `Improvement`.
+- **IaC / CDK (read-only).** From `cdk synth`/`diff`: over-broad IAM, missing/opaque stack outputs, resources that don't serve their stated purpose, drift. A security-relevant misconfiguration is a `Bug`; unclear-but-correct infra is an `Improvement`.
+
+## 5. Mutation
+
+Whether you may create/edit/delete — and as which account — is set by the `use-the-product` mutation policy (`read-only` vs `full`, `identity`, production rules). Follow its **Mutation Discipline** when the policy is `full` (prefixed test data, identify + verify cleanup, record residue). Never mutate an env the policy marks `read-only` or `forbidden`; if a finding can only be confirmed by a forbidden mutation, file it as observed-and-blocked rather than escalating.
+
+## 6. File findings as tracked work
+
+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.
+
+| Finding | `issue_type` | `build_ready` |
+|---|---|---|
+| User-visible **bug** (broken behavior) | `Bug` | the `ready` flag (default `false`) |
+| **Usability / UX / clarity issue** | `Improvement` | the `ready` flag (default `false`) |
+
+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`.** 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.)
+
+Each ticket MUST be a complete spec (the validator rejects thin tickets): a **three-audience description**; for a **bug**, exact reproduction steps, observed-vs-expected, the env / account / interface it occurred at, and evidence; for a **usability issue**, the observed friction, who it affects, **where**, and the proposed improvement; and **Gherkin acceptance criteria** for the fixed behavior.
+
+### 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 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 — 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:
+
+> To stop this from being raised again, close it as **Not planned**. Close it as **Completed** if it was fixed — a later recurrence may be re-filed as a regression.
+
+## Output
+
+No report file. Emit a concise in-session summary:
+
+- **Scope:** product type, target env + mutation level, persona(s) explored as, tool, build/version if visible, date.
+- **First impression:** could a new user tell what the product is and what to do first?
+- **Findings filed**, bucketed by type — each with its **created or referenced ticket ref** and **build-ready state**.
+- **Observed but not filed:** anything noticed but intentionally not ticketed (including forbidden-mutation blocks), with why.
+
+## Run outcome
+
+As the registered `exploratory-bugs` automation loop, this pass conforms to the
+`automation-runbook-contract` rule: every invocation ends in **exactly one** of the six run outcomes
+and records it, so a quiet run and a broken run are never mistaken for each other.
+
+| This cycle's exit path | Run outcome |
+|---|---|
+| Findings filed — one or more `Bug` / `Improvement` tickets created or referenced (§6) | `candidate-proposed` |
+| Clean pass — explored the personas and surfaces, nothing worth filing — **or** every candidate was suppressed by a prior decline (`rejection-detection` **Proposal rejection memory**): the summary MUST name the suppression count | `nothing-needed` |
+| Tracker unconfigured — the §1 stop path; findings cannot be filed — **or** the open-and-closed rejection-memory marker search could not run (tracker unreachable / credentials revoked): a memory check that could not run is a broken loop, never a silent `nothing-needed` | `recovery-required` |
+| The runbook's **Retirement condition** tripped — the trailing quiet window is empty AND this pass found nothing to file AND the project no longer ships an exploratory-qa surface — this row supersedes the `nothing-needed` row when it applies | `policy-obsolete` |
+| A degradation that still let the pass explore (e.g. Kane unavailable, one persona unreachable) | the outcome it actually reached above, with the summary **leading with the degradation** — degradation never mints a seventh token |
+
+Before invoking the run-record CLI, evaluate the **Retirement condition** first. If it applies,
+select `policy-obsolete` as the sole outcome and do not record a prior `nothing-needed` result;
+otherwise select the ordinary outcome from the table.
+
+Record **exactly one** outcome per invocation through the run-record CLI, naming this loop's runbook
+(the `--summary` is the operator-readable one-liner in the contract's exemplar voice — plain,
+specific, actionable, e.g. `Explored 4 personas; nothing confusing to file.` — or, when a decline suppressed the only candidates, `Explored 4 personas; 2 candidates suppressed by a prior decline — nothing new to propose.` — for `nothing-needed`; and for a `recovery-required` from an unreadable decline check, `Tracker unreachable during the decline check — restore credentials; nothing was filed this run.`):
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT:-node_modules/@codyswann/lisa/plugins/lisa}/scripts/automation-run-record.mjs" \
+  --loop-id exploratory-bugs --outcome candidate-proposed \
+  --summary "Explored 4 personas; filed 3 findings from the checkout flow — awaiting your flip to ready." \
+  --runbook .lisa/automations/exploratory-bugs.runbook.md [--ref <ticket-url>]...
+```
+
+The `:-` default in that command is load-bearing, not decoration. `CLAUDE_PLUGIN_ROOT` is **not
+exported into an agent's Bash tool environment**, so the bare `"${CLAUDE_PLUGIN_ROOT}/scripts/…"`
+form expands to an absolute `/scripts/…` and exits 1. The default names the installed package copy,
+which resolves from the **consumer repository root** — which is where the recorder is actually
+invoked. Never substitute a bare `plugins/lisa/scripts/…` or `plugins/src/base/scripts/…` path:
+those are relative to the **Lisa package root**, not the repository you are standing in, and exit 1
+from there. If recording still fails, **degrade, never abort** (per `automation-runbook-contract`):
+note the recording failure in the run output and finish the cycle — a recording failure is a
+degradation to report, never a reason to block the loop.
+
+**Retirement evaluation (every run).** Evaluate this loop's runbook **Retirement condition** on
+every run, exactly as the `automation-runbook-contract` rule's Retirement section defines it — this
+skill conforms to that text and never restates or diverges from it. On top of the contract's two
+conditions the runbook seeds a third **domain conjunct** — the project no longer ships an
+exploratory-qa command surface to explore — which only tightens the test and never replaces it: a
+quiet month on a product nobody broke is quality holding, not a reason to stop looking. Evaluate all
+three. When all three hold, record `policy-obsolete` and file **exactly ONE** marker-deduped
+teardown proposal through `lisa-tracker-write` (per `tracked-work` + `integration-access-layer`):
+
+- **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 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.
+- **Labels** `status:blocked` + `human-needed`, carrying the contract's decision-ready packet. The
+  `human-needed` label marks the proposal human-owned: `lisa-repair-intake` recognizes it and never
+  re-dispatches it as stalled work.
+- **Evidence** the date-filtered search result, this run's summary, **the loop's current cadence**
+  (the baseline an operator needs to choose a longer one), and a one-line summary of recent runs
+  read from `.lisa/automations/runs/exploratory-bugs.jsonl`. Fill the rest of the packet the same
+  way every time: *Work already attempted* is the searches this run ran, and *Risk of inaction* is
+  that the loop keeps consuming schedule slots and tokens for nothing.
+- **How to answer** names the three operator responses: **approve** — run
+  `/lisa:tear-down-automations exploratory-bugs` and only that loop registration goes away;
+  **decline** — close the proposal as
+  **Not planned** (closing it as **Completed** leaves a later re-file open) and the loop simply
+  continues; **re-cadence** — pick a longer cadence off that evidence and re-register with
+  `/lisa:setup-automations` instead of tearing down.
+- **Operator footer**, verbatim, as on every loop-filed proposal (`rejection-detection`):
+  > To stop this from being raised again, close it as **Not planned**. Close it as **Completed** if it was fixed — a later recurrence may be re-filed as a regression.
+
+The loop **keeps running at its normal cadence** until a human acts, and never deletes its own
+registration.
+
+## Quality bar
+
+- Explore as a true first-time user — judge clarity, not whether you (who can read the code) can figure it out.
+- Every ticket must stand alone for an implementer who was not in the session.
+- Do not claim cleanup succeeded unless verified.
+- File per the `ready` flag (default: backlog for human triage).
+- Route automated-coverage gaps to `e2e-coverage-gaps`; preserve unrelated repo changes.

package/plugins/lisa-devin/skills/lisa-fix-linter-error/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: lisa-fix-linter-error
+description: This skill should be used when fixing all violations of one or more ESLint rules across the codebase. It runs the linter, groups violations by rule and file, generates a brief with fix strategies, and creates a plan with tasks to implement the fixes.
+allowed-tools: ["Read", "Bash", "Glob", "Grep"]
+
+---
+
+# Fix Linter Errors
+
+Target rules: $ARGUMENTS
+
+If no arguments provided, prompt the user for at least one lint rule name.
+
+## Step 1: Gather Requirements
+
+1. **Parse rules** from $ARGUMENTS (space-separated)
+2. **Run linter** to collect all violations:
+   ```bash
+   bun run lint 2>&1
+   ```
+3. **Group violations** by rule, then by file, noting:
+   - File path and line numbers
+   - Violation count per file
+   - Sample error messages
+
+## Step 2: Compile Brief and Delegate
+
+Compile the gathered information into a structured brief:
+
+```
+Fix ESLint violations for rules: $ARGUMENTS
+
+Violations by rule:
+- [rule-name-1]: X total violations across Y files
+  - [file]: N violations (lines: ...)
+  - ...
+- [rule-name-2]: X total violations across Y files
+  - ...
+
+Fix strategies: extract functions, early returns, apply formatting, add types
+
+Verification: `bun run lint 2>&1 | grep -E "($ARGUMENTS)" | wc -l` → Expected: 0
+```
+
+Invoke `/lisa:implement` with this brief to create the implementation plan.

package/plugins/lisa-devin/skills/lisa-generate-claude-remote-build-script/SKILL.md

@@ -0,0 +1,235 @@
+---
+name: lisa-generate-claude-remote-build-script
+description: "Generate the setup/build script (and env-var template) to paste into a Claude Code remote routine environment so this repo runs in the cloud. Runs /lisa:analyze-claude-remote to inventory needs, then writes an idempotent, detect-before-install bash script that installs the required CLIs/binaries and package manager for both Lisa and the host project, plus a commented environment-variable template (names only, never real secrets) and a list of custom domains to allowlist. The script is fast (fits the ~5-minute environment-cache budget), re-runnable, and cloud-proxy aware."
+allowed-tools: ["Skill", "Bash", "Read", "Write", "Glob", "Grep"]
+---
+
+# Generate Claude Remote Build Script: $ARGUMENTS
+
+Produce the artifacts a user pastes into a **Claude Code remote routine environment** so this repo
+runs in the cloud: a setup/build script that installs everything the environment needs, an
+environment-variable template, a network-allowlist list, and the names-only
+`.lisa/remote-environment.json` contract consumed by `lisa ui`.
+
+## Purpose
+
+A routine's cloud environment lets you configure a **setup script** (runs once, cached) and
+**environment variables**. This skill turns the read-only inventory from
+`/lisa:analyze-claude-remote` into those concrete artifacts so the user doesn't hand-assemble them.
+
+This skill ships in the base Lisa plugin and is distributed to every host project, so the generated
+script must reflect **what this repo actually needs** — Lisa's startup hooks and configured
+tracker/source, plus the host project's own package manager and tooling — not a hardcoded list.
+
+## Inputs
+
+- Optional flags in `$ARGUMENTS`:
+  - `--out=<path>` — where to write the script. Default `scripts/claude-remote-setup.sh`.
+  - `--include-optional` — also install `OPTIONAL` (dormant-stack) tools. Default: required only.
+  - `--print` — print the script to stdout instead of writing a file.
+
+## Procedure
+
+1. **Inventory.** Invoke `/lisa:analyze-claude-remote --json` and parse its machine-readable
+   inventory block (`packageManager`, `tools`, `env`, `mcp`, `gaps`, `platform`,
+   `networkAccess`, `allowlistDomains`, `awsProfiles`). If the analysis cannot run, stop and report why — never
+   emit a script from guesses.
+
+2. **Compose the setup script** from the inventory. The script must be:
+   - **Idempotent & detect-before-install** — every install guarded by a `command -v <tool>` check
+     so re-runs are no-ops and already-present tools are skipped.
+   - **Fast** — fits the ~5-minute environment-cache budget; avoid heavyweight installs unless
+     `REQUIRED`. Long/optional installs (docker images, chromium, ruby) go in a clearly-marked
+     optional section gated by `--include-optional`.
+   - **PATH-correct** — export the package manager's bin dir (e.g. `$HOME/.bun/bin`) after install
+     so subsequent steps and the cached environment resolve it.
+   - **Cloud-proxy aware** — when the package manager is flagged `RISK` (bun), add a comment
+     documenting the known proxy package-fetch issue and, where safe, run the install with retries
+     so a transient proxy failure doesn't poison the cache. Do not silently swap package managers if
+     `engines` forbids it; surface the risk as a comment instead.
+   - **Non-fatal on optional tools** — `REQUIRED` tool failures should exit non-zero (so the env
+     build fails loudly); `OPTIONAL` tool failures should warn and continue.
+
+3. **Emit the environment-variable template.** Write a commented block listing every `env` entry
+   from the inventory grouped by integration, marked `REQUIRED`/`OPTIONAL` and `secret`/`plain`,
+   with the reason. **Never write real secret values** — only names and placeholders, because the
+   environment config is visible to anyone who can edit it. Entries flagged `providedBy: settings.json`
+   (the committed `.claude/settings.json` `env` flags, e.g. `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS`) are
+   **already applied from the committed file** — list them under an `# Already provided by committed
+   .claude/settings.json — no UI entry needed` heading, not as values to set. The "set in the
+   environment UI" template is for **secrets only**. For every secret entry that carries
+   `acquireUrl`/`accessScope`/`headlessSubstrate` (the
+   active tracker/source credentials from the analysis's group 4a), render those as comment lines
+   directly above the name — `# Acquire: <url>` and `# Access: <scope>` — so the user knows exactly
+   where to get the token and what permissions it needs. Emit only the **env-var form** of the name
+   that the analysis reported (including any per-account suffixed form like `LINEAR_API_KEY_<slug>`);
+   never emit a keychain instruction — keychain does not exist in a cloud routine.
+   When the entry is `GH_TOKEN`, add a comment from `platform.githubProxy` clarifying that the token
+   is for `gh` CLI commands against the project/Lisa repos, not for raw git clone/fetch/push or
+   sibling repos reachable through the routine's GitHub proxy.
+   For OPTIONAL non-tracker MCP recovery entries discovered by
+   `/lisa:analyze-claude-remote`, preserve the same names-only behavior:
+   include `JAM_PAT`, `SONARQUBE_CLI_TOKEN` (+ `SONARQUBE_CLI_ORG`/`SONARQUBE_CLI_SERVER`), or
+   similar documented substrate env vars only as optional secrets, with their
+   acquire/scope comments when the analysis supplied them. Never invent values or promote dormant substrates to required.
+   When AWS entries are present, list only `LISA_AWS_BOOTSTRAP_JSON` as the
+   required secret and `LISA_REMOTE_AGENT=claude` as plain configuration. Never
+   emit standard `AWS_ACCESS_KEY_ID` variables and never recommend `aws sso login`.
+
+3a. **Emit substrate setup snippets.** When the inventory marks an MCP
+   `headlessUsable: true` through a documented substrate, render the matching
+   wiring guidance as commented, opt-in setup:
+   - CLI substrates: emit the detected install/login commands gated on the
+     optional env var. For Jam, this means `curl -fsSL https://native.jam.dev/install | bash`,
+     `export PATH="$HOME/.local/bin:$PATH"`, `printf '%s' "$JAM_PAT" | jam auth login --token`,
+     and `jam skills install`, all inside `[ -n "${JAM_PAT:-}" ] && ...` guards so missing
+     optional secrets do not fail the environment build.
+   - Container-backed MCP substrates (e.g. the official SonarQube MCP): the MCP
+     runs headless as-is in a cloud routine — Docker is preinstalled — so wire the
+     real MCP rather than substituting REST. Emit, guarded on the optional env
+     token, the vendor CLI install (`curl -o- https://raw.githubusercontent.com/SonarSource/sonarqube-cli/refs/heads/master/user-scripts/install.sh | bash`),
+     `sonar integrate <agent>`, and a `sonar run mcp`-image pre-pull so the first
+     run fits the ~5-min cache budget. Provide `SONARQUBE_CLI_TOKEN`
+     (+ `SONARQUBE_CLI_ORG`/`SONARQUBE_CLI_SERVER`); never emit `sonar auth login` (keychain
+     does not exist headless).
+   - REST-only substitute substrates: for a vendor whose MCP genuinely cannot run
+     headless, do not install an MCP — emit comments naming the REST host and env
+     var, and rely on the access skill or generated consumer to call the API.
+   - PAT-bearer MCP substrates: print a commented `.mcp.json` `headers` snippet from the
+     inventory's `mcpHeaders`. Use this only when the analysis explicitly says the same MCP
+     transport supports static-token auth. Do not print a Jam `.mcp.json` header snippet because
+     Jam's preferred headless substrate is its PAT-authenticated CLI.
+
+3b. **Install the shared AWS bootstrap.** When AWS is present, invoke
+   `/lisa:setup-remote-aws --platform=claude`. Reuse the resulting
+   `scripts/remote-agent-aws-setup.sh`; do not generate a second credential or
+   profile implementation. Add `bash scripts/remote-agent-aws-setup.sh` to the
+   generated cloud setup after required package installation.
+
+3c. **Write the project-aware console contract.** Write
+   `.lisa/remote-environment.json` from the same fresh inventory. Its `variables`
+   array must contain only entries that are `required: true` for this project and
+   its active integrations; omit optional, conditional, and dormant integrations.
+   Each entry contains `name`, `reason`, `source`, `secret`, and `required`, but
+   never a value. Set `startupScripts.claude` to the generated `--out` path. Do
+   not add AWS merely because Lisa ships AWS support: add
+   `LISA_AWS_BOOTSTRAP_JSON` only when the inventory reports active AWS usage.
+   Preserve any valid startup-script entries for other agents that already exist
+   in the manifest.
+
+4. **Emit the allowlist + gaps notice.** List any custom domains the setup or runtime reaches
+   (from `networkAccess.allowlistDomains`, falling back to legacy `allowlistDomains`) that the user
+   must add when the environment needs Custom network access. Do not include default Trusted domains
+   such as GitHub, npm/PyPI registries, or Docker Hub. Echo the `gaps` from the analysis
+   (auto-memory not synced, interactive-auth/stdio-MCP unavailable, etc.) and the
+   `platform.secretsVisibility` warning as a header comment so the user knows what the script
+   **cannot** fix.
+
+5. **Write and report.** Write the script to `--out` (default `scripts/claude-remote-setup.sh`),
+   `chmod +x` it, and write `.lisa/remote-environment.json`. Print both paths, a
+   one-line summary of what the script installs and which env vars to set, and
+   the exact next step (paste its contents — or a
+   `bash scripts/claude-remote-setup.sh` invocation — into the routine
+   environment's setup script, and add the env vars in the environment config).
+   When `--print` is passed, print the script to stdout and do not write either
+   file.
+
+## Generated script shape
+
+The emitted script should follow this skeleton (populated from the live inventory — this is the
+shape, not a fixed payload):
+
+```bash
+#!/usr/bin/env bash
+# Claude Code remote-routine setup for <repo>. Generated by /lisa:generate-claude-remote-build-script.
+# Paste into your routine environment's setup script. Re-runnable and idempotent.
+#
+# GAPS this script cannot fix (configure separately):
+#   - <gaps from analysis, e.g. auto-memory is machine-local and not synced to cloud routines>
+# Already provided by committed .claude/settings.json (applied automatically — no UI entry needed):
+#   - CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS, ENABLE_LSP_TOOL, BASH_DEFAULT_TIMEOUT_MS, BASH_MAX_TIMEOUT_MS
+# SECRETS to set in the environment config (names only — set real values there, not here):
+#   # --- credentials for the active tracker/source (set in the environment UI) ---
+#   # Acquire: https://github.com/settings/personal-access-tokens
+#   # Access:  fine-grained PAT on target repo: Contents R/W, Issues R/W, Pull requests R/W, Metadata R
+#   # Note: GH_TOKEN is for gh CLI only. Raw git uses Claude's connected-GitHub proxy/identity;
+#   # sibling repos reached only by raw git do not need to be in this token scope.
+#   - GH_TOKEN=<token>                          # REQUIRED, github is the active tracker+source
+#   - LISA_AWS_BOOTSTRAP_JSON=<complete SecretString> # REQUIRED for AWS
+# PLAIN:
+#   - LISA_REMOTE_AGENT=claude
+# NETWORK: set the environment to Custom and allowlist these non-default domains if not on Full:
+#   - <networkAccess.allowlistDomains, if any>
+set -uo pipefail
+
+need() { command -v "$1" >/dev/null 2>&1; }
+require() { need "$1" || { echo "FATAL: required tool '$1' missing and install failed" >&2; exit 1; }; }
+
+# --- package manager (REQUIRED) ---
+# Resolve the PM from packageManager/engines/lockfiles — emit the manager the
+# `packageManager` inventory field reported, NEVER a hardcoded bun. An npm-only
+# project (engines.bun = "please-use-npm") must install with npm; emitting
+# `bun install` would create a stray bun.lock and break it (the package-manager selection
+# regression). Only install/PATH-export the manager actually selected below.
+detect_package_manager() {
+  _field="" _forced="" _forbidden=""
+  if [ -f package.json ] && command -v jq >/dev/null 2>&1; then
+    _field=$(jq -r '(.packageManager // "") | sub("@.*$";"")' package.json 2>/dev/null)
+    _forced=$(jq -r 'first((.engines // {})[] | strings | capture("please-use-(?<pm>bun|npm|yarn|pnpm)")?.pm) // ""' package.json 2>/dev/null)
+    _forbidden=$(jq -r '[(.engines // {}) | to_entries[] | select(((.value|strings) // "") | test("please-use|do-not-use";"i")) | .key] | join(" ")' package.json 2>/dev/null)
+  fi
+  case "$_field" in bun | npm | yarn | pnpm) printf '%s\n' "$_field"; return 0 ;; esac
+  case "$_forced" in bun | npm | yarn | pnpm) printf '%s\n' "$_forced"; return 0 ;; esac
+  _pm_allowed() { case " $_forbidden " in *" $1 "*) return 1 ;; *) return 0 ;; esac; }
+  { [ -f bun.lockb ] || [ -f bun.lock ]; } && _pm_allowed bun && { printf 'bun\n'; return 0; }
+  [ -f pnpm-lock.yaml ] && _pm_allowed pnpm && { printf 'pnpm\n'; return 0; }
+  [ -f yarn.lock ] && _pm_allowed yarn && { printf 'yarn\n'; return 0; }
+  [ -f package-lock.json ] && _pm_allowed npm && { printf 'npm\n'; return 0; }
+  printf 'npm\n'
+}
+PM="$(detect_package_manager)"
+if [ "$PM" = "bun" ] && ! need bun; then
+  curl -fsSL https://bun.sh/install | bash
+  export PATH="$HOME/.bun/bin:$PATH"
+fi
+# NOTE: bun has known proxy package-fetch issues in cloud sessions; retry to survive transient proxy errors.
+for i in 1 2 3; do "$PM" install && break || sleep 5; done
+
+# --- required CLIs ---
+need gh || (sudo apt-get update -y && sudo apt-get install -y gh)
+need jq || sudo apt-get install -y jq
+require gh; require jq
+
+# --- AWS assume-role profiles, when AWS inventory is active ---
+bash scripts/remote-agent-aws-setup.sh
+
+# --- optional, only with --include-optional ---
+# (docker / ruby / chromium / etc., guarded)
+```
+
+## Confirmation policy
+
+Writing the script file is the deliverable — do not ask whether to proceed. Default to writing
+`scripts/claude-remote-setup.sh`, then report the path and next steps. The only legitimate reasons
+to stop are: the analysis could not run, or the `--out` path is not writable.
+
+## Rules
+
+- Always derive the script and `.lisa/remote-environment.json` from a fresh
+  `/lisa:analyze-claude-remote` run — never from a stale or assumed inventory.
+- Never write real secret values into the script or template — names and placeholders only.
+- For active tracker/source credentials, carry the analysis's `Acquire:` URL and `Access:` scope into
+  the template as comments, and emit only the env-var form of the name — never a keychain command.
+- For `GH_TOKEN`, preserve the analysis's GitHub proxy split: it is for `gh` CLI commands only, and
+  raw git/cross-repo clone guidance must not expand the token scope to sibling repositories.
+- Never emit an install for a tool the analysis did not surface, and never install `OPTIONAL` tools
+  unless `--include-optional` is set.
+- When AWS is in the inventory, reuse `/lisa:setup-remote-aws` and its shared
+  setup script; never emit a second profile implementation or `aws sso login`.
+- Prefer `networkAccess.allowlistDomains` over legacy top-level `allowlistDomains`; never emit
+  domains already covered by the routine environment's default Trusted list.
+- Keep the script idempotent and detect-before-install so it is safe to re-run and cache.
+- Preserve the inventory's `REQUIRED` vs `OPTIONAL` distinction in both fail-behavior (fatal vs
+  warn) and section placement.
+- Surface, never hide, the `gaps` — a generated script must not imply it makes a repo fully
+  cloud-ready when known constraints remain.

package/plugins/lisa-devin/skills/lisa-git-commit/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: lisa-git-commit
+description: This skill should be used when creating conventional commits for current changes. It groups related changes into logical commits, ensures all files are committed, and verifies the working directory is clean afterward.
+allowed-tools: ["Bash"]
+---
+
+# Git Commit Workflow
+
+Create conventional commits for current changes. Optional hint: $ARGUMENTS
+
+## Workflow
+
+### See what has changed
+
+!git status
+!git diff --stat
+
+### Apply these requirements
+
+1. **Branch Check**: If on `dev`, `staging`, or `main`, create a feature branch named after the changes
+2. **Commit Strategy**: Group related changes into logical conventional commits (feat, fix, chore, docs, etc.). Every rule below that says "all" or "everything" excludes the local-only `.lisa/work-item-context.md` described in rule 3.
+3. **Commit ALL Files**: Every file must be assigned to a commit group - no file gets left out or unstaged. **Local-only exception:** never stage `.lisa/work-item-context.md`, or any other file the work-item context contract marks local-only, even when it is untracked and not ignored — it can quote credentials from tracker comments. Leave it untracked, and say in your report that it was left out and why.
+4. **Commit Creation**: Stage and commit each group with clear messages
+5. **Verification**: Run `git status` to confirm working directory is clean - must show "nothing to commit" (apart from a local-only file left untracked under rule 3)
+
+### Use conventional commit format
+
+- `feat:` for new features
+- `fix:` for bug fixes
+- `docs:` for documentation
+- `chore:` for maintenance
+- `style:` for formatting
+- `refactor:` for code restructuring
+- `test:` for test additions
+
+For hand-written messages, put prose and attribution text before one final,
+unbroken block of `Key: value` trailers, including `Work-Item:` and
+`Co-authored-by:`. Commit preparation repairs a misplaced work-item reference;
+the original authored line may remain in the message.
+
+### Never
+
+- use `--no-verify` flag
+- attempt to bypass tests or quality checks
+- skip tests or quality checks
+- stash changes - ALL changes must be committed, except the local-only `.lisa/work-item-context.md`
+- skip or exclude any files from the commit - even if they're unrelated (the local-only `.lisa/work-item-context.md` is the one exclusion, and it is mandatory)
+- leave uncommitted changes in the working directory, other than the local-only `.lisa/work-item-context.md`
+- ask the user which files to commit - commit everything except the local-only `.lisa/work-item-context.md`
+
+## Execute
+
+Execute the workflow now.