@codyswann/lisa 2.110.1 → 2.111.0

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

@@ -1,138 +1,145 @@
 ---
 name: exploratory-qa
-description: Playwright-backed exploratory QA workflow for web apps that FEEDS THE LIFECYCLE. Use when asked to audit an app with Playwright/e2e tests, find human-noticeable bugs and usability issues, identify gaps in automated test coverage, test responsive breakpoints, observe slow or unclear load states, or exercise mutable workflows with cleanup. Instead of writing a report file, it files every finding as a tracked work item via lisa:tracker-write (bugs, usability suggestions, and missing Playwright tests). A `ready` parameter controls whether bug and suggestion tickets are created build-ready (auto-picked-up by lisa:intake) or in the backlog for human triage (default); missing-test tickets are always created build-ready.
+description: First-time-user exploratory QA walkthrough for web apps that FEEDS THE LIFECYCLE. Use when asked to experience an app the way a brand-new human user would — landing cold on the home page and clicking through to find anything confusing, broken, or hard to understand (machine-style labels, slow or unclear loads, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances) across all breakpoints. Instead of writing a report file, it files every finding as a tracked work item via lisa:tracker-write (bugs and usability/UX issues). 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 Playwright test suite, use the e2e-coverage-gaps skill instead.
 ---
 
 # Exploratory QA
 
 ## Overview
 
-Run a human-style exploratory QA pass informed by the existing Playwright suite, then **file every finding as a tracked work item** in the project's configured tracker so it enters the Lisa lifecycle. The goal is to find issues users notice and machines often miss — bugs, usability friction, and coverage gaps — and turn each into actionable, automatable work, not a static report.
+Experience the app the way a **brand-new human user** would: land cold on the home page with no prior
+knowledge, then click through and actually try to use it — just like a real person. The goal is to
+surface anything **confusing, broken, or hard to understand**, and to do so at **every breakpoint**.
+
+This is a usability/experience pass, **not** a test-coverage audit. It does not look at the Playwright
+suite or hunt for coverage gaps — for that, use the `e2e-coverage-gaps` skill. Here, every finding is
+filed as a tracked work item so it enters the Lisa lifecycle — no static report file.
 
 ## Parameters
 
-- **`target-url | env`** (first positional) — what to audit.
-- **`ready=true|false`** — the build-ready state for the **bug** and **usability/suggestion** tickets this pass creates.
+- **`target-url | env`** (first positional) — what to explore.
+- **`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 (not build-ready) for a human to review and promote into the queue.
-  - **Missing Playwright test tickets are ALWAYS created build-ready, regardless of this flag** — adding missing coverage is always safe to queue.
-
-`ready` maps directly to the `build_ready` write-control input on `lisa:tracker-write`.
+  - `ready=false` (**default**) → created in the backlog (not build-ready) for a human to review and
+    promote into the queue.
 
 ## Core Workflow
 
 ### 1. Establish Scope
 
-- Identify the target environment, account type, browser requirement, and the `ready` flag value (default `false`).
-- **Confirm the tracker is configured.** Findings are filed as tickets, so read `tracker` from `.lisa.config.json` (local overrides global). If it is unset, stop and report that the tracker must be configured (via `/lisa:setup:jira` / `:github` / `:linear`) before exploratory QA can file findings — do not silently fall back to a report file.
-- If credentials, tenant, seed data, or mutation boundaries are missing and cannot be discovered safely, ask a concise clarifying question.
-- Treat production-like environments conservatively. Do not mutate production data unless the user explicitly approves it.
-- Prefer a test user, dev/staging environment, or isolated seeded account for mutation testing.
-
-### 2. Research Existing Playwright Coverage
-
-- Inspect Playwright config, auth/setup projects, fixtures, constants, selectors, test directories, skipped tests, retries, and viewport/device projects.
-- Summarize:
-  - Number and shape of specs/tests.
-  - Major workflows covered well.
-  - Skipped/flaky/TODO coverage.
-  - Viewports and browser projects used.
-  - Mutating tests and their cleanup strategy.
-  - Areas where tests assert presence instead of behavior.
-- Use existing test helpers/selectors when exploring the app. They reveal intended flows and stable hooks.
-
-### 3. Choose Browser Tools
-
-- Use the user's requested browser/tool when specified.
-- Use a real profile browser when the task depends on existing cookies, SSO, extensions, or a logged-in session.
-- Use Playwright automation when exact viewport sizing, repeatable navigation, screenshots, console logs, traces, or route timing are needed.
-- Do not let automation hide human observations. Screenshots, visible text, layout, latency, scrollability, and affordance clarity matter.
-
-### 4. Explore Like A Human
-
-Cover at least these dimensions unless the user narrows scope:
-
-- **Navigation:** direct URLs and visible click paths.
-- **Responsive behavior:** supported breakpoints, plus boundary widths where layout changes.
-- **Visual/layout quality:** cutoff text, overlap, offscreen controls, accidental horizontal scroll, empty space, awkward density, hidden stale content.
-- **Load states:** blanks, skeletons, spinners, `Loading...`, `Connecting...`, delayed hydration, and whether delays exceed a human-acceptable threshold.
-- **Behavior correctness:** sorting, filtering, saving, deleting, disabled states, permissions, tab persistence, URL canonicalization.
-- **Accessibility/testability:** hidden or off-canvas content exposed to accessibility/text locators, duplicate inactive route content, zero-sized interactive elements.
-- **Console/network health:** errors, missing assets, failed requests, noisy expected errors that could bury real failures.
-- **Data hygiene:** repeated test artifacts, stale seeded content, polluted shared accounts.
+- Identify the target environment, account type, and browser requirement, and read the `ready` flag
+  (default `false`).
+- **Confirm the tracker is configured.** Findings are filed as tickets, so read `tracker` from
+  `.lisa.config.json` (local overrides global). If it is unset, stop and report that the tracker must
+  be configured (via `/lisa:setup:jira` / `:github` / `:linear`) before exploratory QA can file
+  findings — do not silently fall back to a report file.
+- If credentials, tenant, or seed data are missing and cannot be discovered safely, ask one concise
+  clarifying question.
+- Treat production-like environments conservatively. Do not mutate production data unless the user
+  explicitly approves it. Prefer a test user, dev/staging environment, or isolated seeded account.
+
+### 2. Arrive Cold
+
+- Start at the home/landing page with **no prior knowledge of the app**. Do **not** pre-read the
+  codebase to learn the intended flows — discover them the way a user would, by looking and clicking.
+- Form a first impression: is it obvious what this app is, what to do first, and where to go next?
+
+### 3. Use It Like a Human
+
+Click through the visible paths and actually attempt real tasks — a first-time user explores, makes
+mistakes, and tries the obvious thing. Cover at least these dimensions unless the user narrows scope:
+
+- **Comprehension & labeling:** machine-style or developer labels shown to users (raw IDs, enum keys,
+  `snake_case`, `null`/`undefined`, untranslated i18n keys), jargon, unclear button/menu names, icons
+  with no discernible meaning.
+- **Navigation clarity:** is it obvious how to get somewhere and back? Dead ends, hidden entry points,
+  surprising redirects, broken links, no clear "home".
+- **Visual/layout quality:** cut-off or truncated text, overlap, cramped/crowded density, offscreen or
+  unreachable controls, accidental horizontal scroll, awkward empty space.
+- **Consistency / standard UX:** components, spacing, button styles, terminology, and interaction
+  patterns should be consistent across the app and follow common conventions. Flag anything
+  non-standard or that differs screen-to-screen.
+- **Load & responsiveness:** long or unclear load times, blank screens, spinners / `Loading...` /
+  `Connecting...` with no progress, anything that feels slow or janky.
+- **Scroll behavior:** unexpected scroll position, scroll jumps, nested or locked scroll, sticky
+  elements that cover content, content that cannot be reached.
+- **Behavior correctness:** does the obvious action do what a user expects? Confusing errors, silent
+  failures, disabled controls with no explanation, state that does not persist.
+- **Affordance clarity:** can the user tell what is clickable, required, in-progress, or complete?
+
+### 4. Cover All Breakpoints
+
+- Discover breakpoints from the app (design tokens, CSS, responsive layout changes) when possible; if
+  unknown, use a practical baseline: phone, tablet/narrow, desktop, plus any app-specific cutoff.
+- At each breakpoint, walk the key paths again and confirm the experience holds: expected
+  shell/navigation variant, critical controls visible and reachable, no unintended horizontal
+  overflow, intentional scroll containers still usable, nothing cut off or crowded.
+
+### 5. Watch Load & Latency
+
+- Notice time to first meaningful content and time spent in blank/loading/spinner/connecting states.
+- A page can be technically interactive but still visually incomplete — note that.
+- Treat long waits without clear progress, error, retry, or cancellation as findings. Use practical
+  labels (noticeable, slow, unacceptable) and include observed durations when available.
 
 ## Mutation Discipline
 
-Exploratory QA should exercise mutable workflows when the environment is safe.
-
-- Prefer high-value user workflows: create/edit/delete records, lists, boards, tags, notes, comments, scenarios, uploads, messages, settings, invitations, or assignments.
-- Use unique names with a clear prefix such as `qa-`, `pw-`, or `codex-`.
-- Before mutating, identify the cleanup path. After mutating, make a best effort to clean up through the UI, then verify cleanup.
-- If UI cleanup is unavailable, file that as a product/test gap (a finding — see below). Use documented API cleanup only if appropriate for the project and account.
-- Record all mutations performed, cleanup attempts, and residue left behind.
-- Avoid destructive bulk actions unless the user explicitly asks or the test account is clearly disposable.
-
-## Breakpoint Strategy
-
-- Discover breakpoints from the codebase, design tokens, CSS, docs, or Playwright constants when possible.
-- Test each named breakpoint and the boundary on both sides of important cutoffs.
-- If breakpoints are unknown, use a practical baseline: phone, tablet/narrow, desktop, and any app-specific cutoff discovered during research.
-- For each breakpoint, assert both user-visible behavior and automation-relevant state:
-  - Expected shell/navigation variant.
-  - Route-specific loaded content.
-  - Critical controls visible and reachable.
-  - No unintended document-level horizontal overflow.
-  - Intentional scroll containers remain usable.
-  - Hidden/off-canvas UI is not exposed as active content.
+A real first-time user creates, edits, and deletes things — exercise those flows when the environment
+is safe.
 
-## Load-State Strategy
-
-Measure perceived latency, not just eventual success.
-
-- Track time to shell, time to meaningful route content, and time spent in blank/loading/spinner/connecting states.
-- Note when a page is technically interactive but still visually incomplete.
-- Treat long waits without clear progress, error, retry, or cancellation as bugs or test gaps.
-- Do not overfit exact milliseconds unless the project has defined budgets. Use practical labels such as noticeable, slow, or unacceptable and include observed durations when available.
+- Use unique names with a clear prefix such as `qa-` or `codex-`.
+- Before mutating, identify the cleanup path. After mutating, make a best effort to clean up through
+  the UI, then verify cleanup. If UI cleanup is unavailable, that itself is a usability finding.
+- Avoid destructive bulk actions unless the user explicitly asks or the account is clearly disposable.
+- Record all mutations performed, cleanup attempts, and any residue left behind.
 
 ## Filing findings as tracked work
 
-This skill does **not** write a report file. Every finding becomes a **leaf 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). Map each finding to a type and a build-ready state:
+This skill does **not** write a report file. Every finding becomes a **leaf 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). Map each finding to a type:
 
 | Finding | `issue_type` | `build_ready` |
 |---------|--------------|---------------|
-| User-visible **bug** | `Bug` | the `ready` flag (default `false`) |
-| **Usability / UX issue** (suggestion) | `Improvement` | the `ready` flag (default `false`) |
-| **Missing Playwright test** (coverage gap) | `Task` | **`true` (always)** |
-
-Each finding is a flat leaf (no children), so `build_ready` applies directly. Pass it explicitly on every create — `build_ready: <ready flag>` for bugs and suggestions, `build_ready: true` for missing tests.
+| User-visible **bug** (broken behavior) | `Bug` | the `ready` flag (default `false`) |
+| **Usability / UX / clarity issue** | `Improvement` | the `ready` flag (default `false`) |
 
-Each ticket MUST be a complete spec (`lisa:tracker-write` runs the validator and rejects thin tickets):
+Each finding is a flat leaf (no children), so `build_ready` applies directly — pass it explicitly on
+every create. Each ticket MUST be a complete spec (the validator rejects thin tickets):
 
 - **Three-audience description** (context / business value, technical approach, stakeholder impact).
-- **For a bug:** exact reproduction steps, observed-vs-expected, the env / account / breakpoint it occurred at, and console/network evidence.
-- **For a usability issue:** the observed friction, who it affects, and the proposed improvement.
-- **For a missing test:** the user behavior the test must assert and the stable selector/flow to use — concrete and automatable.
-- **Gherkin acceptance criteria** describing the fixed (bug / usability) or added (test) behavior.
+- **For a bug:** exact reproduction steps, observed-vs-expected, the env / account / breakpoint it
+  occurred at, and console/network evidence.
+- **For a usability issue:** the observed friction (what was confusing, cramped, inconsistent, or hard
+  to understand), who it affects, **where** (route + breakpoint), and the proposed improvement.
+- **Gherkin acceptance criteria** describing the fixed behavior.
 
 ### Idempotency — don't spam duplicates
 
-Re-running a QA pass must not refile the same finding. Before creating a ticket, search the tracker for an **open** 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`). If one exists, reference/update it instead of creating a duplicate; only create when none exists. **Match by the marker, never by title** (titles get edited). A *closed* prior ticket does not suppress a new one — a recurrence after a fix is a genuine regression.
+Re-running a pass must not refile the same finding. Before creating a ticket, search the tracker for an
+**open** 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`).
+If one exists, reference/update it instead of creating a duplicate; only create when none exists.
+**Match by the marker, never by title** (titles get edited). A *closed* prior ticket does not suppress a
+new one — a recurrence after a fix is a genuine regression.
 
 ## Output
 
 No report file. Emit a concise in-session summary:
 
 - **Scope:** target URL/env, browser/tool, account type, build/version if visible, date.
-- **Existing Playwright coverage:** strengths and thin areas observed during research.
-- **Findings filed**, bucketed by type — bugs, usability suggestions, missing tests — each with its **created or referenced ticket ref** and its **build-ready state** (`ready` vs `triage/backlog`).
+- **First impression:** could a new user tell what the app is and what to do first?
+- **Findings filed**, bucketed by type — bugs, usability/clarity issues — each with its **created or
+  referenced ticket ref** and its **build-ready state** (`ready` vs `triage/backlog`).
 - **Observed but not filed:** anything noticed but intentionally not ticketed, with why.
 
 ## Quality Bar
 
-- Be honest about what was and was not tested.
-- Distinguish user-visible bugs from missing automated coverage — they map to different issue types (`Bug` vs `Task`).
-- Prefer concrete, reproducible findings. Every ticket must stand alone for an implementer who was not in the session.
+- Explore as a true first-time user — judge clarity, not whether you (who can read the code) can figure
+  it out.
+- Prefer concrete, reproducible findings. Every ticket must stand alone for an implementer who was not
+  in the session.
 - Do not claim cleanup succeeded unless verified.
-- Do not let broad locators pass against hidden/inactive content.
-- File missing-test tickets build-ready; file bug and usability tickets per the `ready` flag (default: backlog for human triage).
+- File tickets per the `ready` flag (default: backlog for human triage).
+- This skill is about the human experience only — route automated-coverage gaps to `e2e-coverage-gaps`.
 - Preserve unrelated repo changes.

package/plugins/lisa-rails/skills/exploratory-qa/agents/openai.yaml

@@ -1,4 +1,4 @@
 display_name: "Exploratory QA"
-short_description: "Playwright-backed exploratory QA workflow for web apps that FEEDS THE LIFECYCLE"
+short_description: "First-time-user exploratory QA walkthrough for web apps that FEEDS THE LIFECYCLE"
 default_prompt:
-  - "Use $exploratory-qa: Playwright-backed exploratory QA workflow for web apps that FEEDS THE LIFECYCLE."
+  - "Use $exploratory-qa: First-time-user exploratory QA walkthrough for web apps that FEEDS THE LIFECYCLE."

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.110.1",
+  "version": "2.111.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.110.1",
+  "version": "2.111.0",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.110.1",
+  "version": "2.111.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.110.1",
+  "version": "2.111.0",
   "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki/templates/llm-wiki-contract.md

@@ -23,6 +23,18 @@ Repository mode: **{{mode}}**.
 - `{{wikiRoot}}/staff/` — digital-staff role pages (optional).
 - Synthesis categories: {{categories}}.
 
+## Answering questions (query-first)
+When you need to answer a question about this project — its code, architecture, decisions, domain
+concepts, conventions, or documentation — reach for the wiki **first**: run `/query "<question>"`
+(Codex: `$lisa-wiki-query`) before ad-hoc code search, grep, or a web lookup. The wiki is the
+curated, cited source of truth for this project, so a query is usually faster and more accurate than
+re-deriving the answer from raw files.
+
+This is the **primary** method, not the only one. If `/query` returns nothing relevant, the answer
+is not in the wiki yet, or the question is about live/uncommitted state, fall back to reading the
+code, browsing `{{wikiRoot}}/index.md`, or other tools — and consider `/ingest` to capture any
+durable knowledge you had to reconstruct so the next query succeeds.
+
 ## Ordered ingestion pipeline (never reorder)
 `source note → synthesis → index → log → verify → state → commit/PR`.
 State advances **only** after source notes + synthesis + index + log + verification all pass.

package/plugins/src/base/commands/repair-intake.md

@@ -1,6 +1,6 @@
 ---
-description: "Repair counterpart to /lisa:intake. Vendor-agnostic batch scanner that finds stuck or half-closed work — items left in `blocked`, stalled in an in-progress role (build `claimed`, PRD `in_review`), terminal-labeled items still natively open, and rollups whose children are all terminal — across the same queues /lisa:intake serves (Notion / Confluence / Linear / GitHub PRDs; JIRA / GitHub / Linear build issues). Repairs every materially actionable candidate inside the `max_candidates` cap: resumes stalled in-progress work in place, re-validates blocked PRDs, re-dispatches blocked build items whose blockers have cleared, performs terminal native closure, and closes out completed rollups. Cron-safe and bounded; default GitHub intake_mode is both and default max_candidates is 100."
-argument-hint: "<Notion-PRD-database-URL | Confluence-space-URL | Confluence-parent-page-URL | Linear-workspace-URL | Linear-team-URL | GitHub-repo-URL | org/repo | JIRA-project-key | JQL-filter> [intake_mode=prd|build|both] [stale_after=24h] [max_candidates=100] [force=true]"
+description: "Repair counterpart to /lisa:intake. Vendor-agnostic batch scanner that finds stuck or half-closed work — items left in `blocked`, stalled in an in-progress role (build `claimed`, PRD `in_review`), terminal-labeled items still natively open, and rollups whose children are all terminal — across the same queues /lisa:intake serves (Notion / Confluence / Linear / GitHub PRDs; JIRA / GitHub / Linear build issues). Repairs every materially actionable candidate inside the `max_candidates` cap: resumes stalled in-progress work in place — but for a stalled build it first diagnoses the PR/deploy state and, if the PR cannot merge (conflict, rebase, failing checks, unaddressed CodeRabbit/changes-requested) or a deploy failed, files a build-ready fix ticket and moves the item to `blocked` (blocked by it) instead of re-dispatching — re-validates blocked PRDs, re-dispatches blocked build items whose blockers have cleared, performs terminal native closure, and closes out completed rollups. Cron-safe and bounded; default GitHub intake_mode is both and default max_candidates is 100."
+argument-hint: "<Notion-PRD-database-URL | Confluence-space-URL | Confluence-parent-page-URL | Linear-workspace-URL | Linear-team-URL | GitHub-repo-URL | org/repo | JIRA-project-key | JQL-filter> [intake_mode=prd|build|both] [stale_after=2h] [max_candidates=100] [force=true]"
 ---
 
 Use the /lisa:repair-intake skill to scan the queue for stuck or half-closed items and repair every materially actionable candidate inside `max_candidates` (default 100). For GitHub queues, default `intake_mode` to `both` when the caller omits it. $ARGUMENTS

package/plugins/src/base/rules/config-resolution.md

@@ -147,7 +147,7 @@ fi
   "intake": {
     "assignee": "<vendor-user-id-or-login>",
     "repair": {
-      "staleAfterHours": 24,
+      "staleAfterHours": 2,
       "maxCandidates": 100
     }
   }
@@ -299,7 +299,7 @@ documented defaults, so existing projects need no config change.
 
 | Key | Required | Default | Notes |
 |-----|----------|---------|-------|
-| `intake.repair.staleAfterHours` | no | `24` | How long an in-progress item (build `claimed`, PRD `in_review`) may show no observable activity before repair-intake treats it as stalled and resumes it. `blocked` items are judged on blocker/answer state, not this threshold. Overridable per-run via `stale_after=<dur>` in `$ARGUMENTS` (which always wins). The same value is the default backoff window for loop-prevention notes. |
+| `intake.repair.staleAfterHours` | no | `2` | How long an in-progress item (build `claimed`, PRD `in_review`) may show no observable activity before repair-intake treats it as stalled and resumes it. `blocked` items are judged on blocker/answer state, not this threshold. Overridable per-run via `stale_after=<dur>` in `$ARGUMENTS` (which always wins). The same value is the default backoff window for loop-prevention notes. |
 | `intake.repair.maxCandidates` | no | `100` | Upper bound on how many stuck items repair-intake enumerates while searching for the first actionable one. Bounds scan cost. Overridable per-run via `max_candidates=<n>`. |
 
 ### Intake assignee filter (`intake.assignee`)

package/plugins/src/base/skills/repair-intake/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: repair-intake
-description: "Vendor-agnostic repair scanner — the recovery counterpart to lisa:intake. Where intake claims `ready` work, repair-intake finds work that got stuck or was left half-closed: items left in `blocked`, stalled in an in-progress role (build `claimed`, PRD `in_review`), terminal-labeled items that are still natively open, and rollup/container items whose children are all terminal but whose parent is not closed out. Scans the same queues lisa:intake serves (Notion / Confluence / Linear / GitHub PRD databases; JIRA / GitHub / Linear build queues), enumerates candidates up to `max_candidates`, and repairs every materially actionable one in that bounded set: resumes stalled in-progress work IN PLACE (build → the vendor agent + the scanner's post-agent transition; PRD → the source `*-to-tracker` dry-run validate→route pipeline), re-validates blocked PRDs when new clarifying answers exist, re-dispatches blocked build items whose `is blocked by` dependencies have since closed, performs terminal native closure for terminal-labeled items, and closes rollups whose associated child work is fully terminal. Idempotent, loop-protected via a [lisa-repair-intake] marker + state fingerprint + backoff. Never mutates product-owned states (`draft`, `verified`) and never touches `ready` items. Designed as a /schedule cron target running alongside lisa:intake."
+description: "Vendor-agnostic repair scanner — the recovery counterpart to lisa:intake. Where intake claims `ready` work, repair-intake finds work that got stuck or was left half-closed: items left in `blocked`, stalled in an in-progress role (build `claimed`, PRD `in_review`), terminal-labeled items that are still natively open, and rollup/container items whose children are all terminal but whose parent is not closed out. Scans the same queues lisa:intake serves (Notion / Confluence / Linear / GitHub PRD databases; JIRA / GitHub / Linear build queues), enumerates candidates up to `max_candidates`, and repairs every materially actionable one in that bounded set: resumes stalled in-progress work IN PLACE (build → the vendor agent + the scanner's post-agent transition; PRD → the source `*-to-tracker` dry-run validate→route pipeline) — but for a stalled build it first diagnoses the PR/deploy state and, if the PR cannot merge (conflict, rebase-required, failing checks, unaddressed CodeRabbit/changes-requested) or a deploy failed, files a build-ready leaf fix ticket and moves the item to `blocked` (blocked by that ticket) rather than re-dispatching, re-validates blocked PRDs when new clarifying answers exist, re-dispatches blocked build items whose `is blocked by` dependencies have since closed, performs terminal native closure for terminal-labeled items, and closes rollups whose associated child work is fully terminal. Idempotent, loop-protected via a [lisa-repair-intake] marker + state fingerprint + backoff. Never mutates product-owned states (`draft`, `verified`) and never touches `ready` items. Designed as a /schedule cron target running alongside lisa:intake."
 allowed-tools: ["Skill", "Bash", "Read", "Write", "Edit", "mcp__linear-server__list_teams", "mcp__linear-server__list_projects", "mcp__linear-server__get_project", "mcp__linear-server__save_project", "mcp__linear-server__list_project_labels", "mcp__linear-server__list_issues", "mcp__linear-server__get_issue", "mcp__linear-server__save_issue", "mcp__linear-server__list_comments", "mcp__linear-server__save_comment", "mcp__linear-server__list_issue_labels", "mcp__linear-server__create_issue_label"]
 ---
 
@@ -14,7 +14,11 @@ close-out** roles and moves work *unstuck* or *fully closed*:
   `in_review`) whose processing cycle died. It is technically "being worked" but nothing is
   happening, so it sits ignored forever. (The vendor PRD intakes explicitly leave an errored PRD
   in `in_review` "for the human to investigate from there" — that orphan is exactly what this
-  skill recovers.)
+  skill recovers.) For a stalled **build**, repair-intake first diagnoses *why* it stalled by
+  inspecting its PRs and deploys: if the PR cannot merge (conflict / rebase-required / failing
+  checks / unaddressed CodeRabbit or `CHANGES_REQUESTED` review) or a deploy failed, it files a
+  build-ready leaf fix ticket and moves the item to `blocked` (blocked by that ticket) instead of
+  blindly re-dispatching the agent — which would just churn against an unmergeable PR.
 - **Recoverable blocked** — an item in `blocked` whose blocker may now be gone: an
   `is blocked by` dependency has since closed, clarifying questions have been answered, or
   research/waiting resolves the ambiguity that stopped it.
@@ -35,14 +39,14 @@ lifecycle state with provider-native closure and rollup state.
 ## Public contract
 
 ```text
-/lisa:repair-intake <queue> [intake_mode=prd|build|both] [stale_after=24h] [max_candidates=100] [force=true]
+/lisa:repair-intake <queue> [intake_mode=prd|build|both] [stale_after=2h] [max_candidates=100] [force=true]
 ```
 
 | Token | Meaning | Default |
 |-------|---------|---------|
 | `<queue>` | Same queue identifier `lisa:intake` accepts (see Source dispatch). Required. | — |
 | `intake_mode` | `prd` \| `build` \| `both`. Only meaningful for a GitHub `org/repo` (or bare `github`) that hosts both PRD and build label namespaces. `both` is unique to repair — a repair sweep usefully covers both lifecycles in one schedule. Absent → `both` when both namespaces exist, else whichever lifecycle exists. | `both` for dual GitHub queues; otherwise infer |
-| `stale_after` | How long with no observable activity before an in-progress item counts as stalled. Accepts `24h`, `90m`, `2d`, or `0` (treat any in-progress item as stalled — manual recovery, also the only way to resume work on a provider that exposes no reliable timestamp). Overrides config. | `24h` |
+| `stale_after` | How long with no observable activity before an in-progress item counts as stalled. Accepts `24h`, `90m`, `2d`, or `0` (treat any in-progress item as stalled — manual recovery, also the only way to resume work on a provider that exposes no reliable timestamp). Overrides config. | `2h` |
 | `max_candidates` | Cap on how many stuck/close-out candidates to enumerate and evaluate. Repair every materially actionable candidate within this bounded set, then stop. Overrides config. | `100` |
 | `force` | `true` bypasses the loop-prevention backoff window (so a manual re-run re-attempts items even if their fingerprint is unchanged). It does **not** change the staleness rule — use `stale_after=0` for that. | `false` |
 
@@ -193,7 +197,7 @@ staleness — their repairability is judged on current blocker/answer state, not
 1. `$ARGUMENTS` `stale_after=<dur>` (one-off override) — always wins. Parse `Nh` / `Nm` / `Nd` /
    `0` into hours.
 2. `.lisa.config.json` `intake.repair.staleAfterHours` (durable project default).
-3. Built-in default: **24 hours**.
+3. Built-in default: **2 hours**.
 
 `stale_after=0` means "treat any in-progress item as stalled" — a manual full-recovery lever,
 and the only way to resume work on a provider that exposes no reliable activity timestamp.
@@ -214,6 +218,14 @@ If ANY of these is newer than the threshold, the item is **active** → record i
 skip it (read-only). For build `claimed`, an open PR with recent commits/checks is active. For
 PRD `in_review`, a recent comment or page edit is active.
 
+Count only **forward-progress** signals as keep-alive: new commits, a review that was just
+requested or posted, an in-progress/queued check run, a fresh progress comment. A **settled
+blocker state** — a failing/errored check run, `CONFLICTING` mergeability, a `CHANGES_REQUESTED`
+review, an unaddressed CodeRabbit/reviewer change request, or a failed deployment — is NOT
+keep-alive activity: it does not reset the staleness clock. The clock runs from the last genuine
+progress event, so a PR that has been sitting failed/conflicted/awaiting-changes for longer than
+`stale_after` counts as stalled and is diagnosed below.
+
 If a provider cannot expose any reliable timestamp, do **not** auto-resume its in-progress
 items unless the caller passed `stale_after=0`. (Dependency-cleared `blocked` repair still
 proceeds — it is judged on blocker state, not time.)
@@ -225,10 +237,22 @@ Apply per candidate. Continue through the ordered list until every candidate ins
 native close/archive/complete, re-dispatch, or refreshed note), be recorded read-only, or be
 recorded under Errors. Do not stop after the first write; the cap is the batch boundary.
 
-### Build `claimed` (stalled in-progress) → resume in place
+### Build `claimed` (stalled in-progress) → diagnose blocker, else resume in place
+
+After the staleness gate passes, **first diagnose why it stalled** by inspecting the item's PRs and
+deploys (see "Stuck-cause diagnosis" below). A stalled build usually stalled for a concrete external
+reason, and re-dispatching the agent at it will not fix a PR that cannot merge or a deploy that
+failed — it just churns.
 
-After the staleness gate passes, run the **same per-item sequence the vendor build-intake runs**,
-skipping the claim transition (the item is already `claimed`):
+0. **Diagnose PR & deploy blockers.** If a real external blocker is found (PR cannot merge — merge
+   conflict / rebase-required / failing checks / `CHANGES_REQUESTED` / unaddressed CodeRabbit; or a
+   failed deploy), **do not dispatch the agent**. Instead file a build-ready leaf fix ticket for the
+   blocker, move this item `claimed → blocked` with an `is blocked by` link to that ticket, and
+   record it. The existing "Build `blocked` → unblock if cleared" path resumes this item on a later
+   cycle once the fix ticket is terminal — a self-healing loop. Skip the resume steps below.
+
+If no external blocker is found, the work simply died mid-flight — run the **same per-item sequence
+the vendor build-intake runs**, skipping the claim transition (the item is already `claimed`):
 
 1. Dispatch the item to the vendor agent — `lisa:jira-agent` / `lisa:github-agent` /
    `lisa:linear-agent` (matching the queue's tracker) — with the item ref. This resumes the work
@@ -246,6 +270,59 @@ skipping the claim transition (the item is already `claimed`):
 > partially-built item look freshly human-approved to the next `lisa:intake` claim, and forces a
 > two-cycle recovery. Resume in place.
 
+#### Stuck-cause diagnosis: PR & deploy blockers
+
+Run this for every stalled `claimed` build item **before** considering an agent re-dispatch. The
+goal is to distinguish "work died mid-flight, just resume it" from "work is blocked on a concrete
+external state that resuming the agent cannot fix."
+
+**1. Find the associated PR(s) and deploy(s).** From the item's linked PRs (GitHub: remote/dev
+links and `gh pr list --search <issue-ref>`; JIRA: dev-status / remote links; Linear: attachments
+and git-branch links) and the deploy(s) for the resulting merge (the env-keyed `deploy.branches`
+mapping from `config-resolution`). Read each PR with the vendor's native state, e.g. GitHub
+`gh pr view <n> --json mergeable,mergeStateStatus,reviewDecision,statusCheckRollup,comments,reviews`.
+
+**2. Classify as a blocker.** Treat any of these as a real external blocker:
+
+- **Merge conflict / rebase required** — `mergeable = CONFLICTING`, or `mergeStateStatus` in
+  `DIRTY` / `BEHIND`.
+- **Failing required checks** — `statusCheckRollup` has a `FAILURE`/`ERROR`/`TIMED_OUT` conclusion,
+  or `mergeStateStatus = UNSTABLE`/`BLOCKED` due to checks.
+- **Change requests outstanding** — `reviewDecision = CHANGES_REQUESTED`, or unresolved CodeRabbit
+  (or other reviewer) comments that request changes and have not been addressed by a newer commit.
+- **Branch-protection / approvals blocked** — `mergeStateStatus = BLOCKED` for a reason other than
+  a transient check still running.
+- **Failed deploy** — the deployment for the item's merge/branch reports a failed/errored status
+  (failed deploy workflow run, failed deployment status, or the project's deploy check is red).
+
+A check that is still **queued/in progress**, or a `CLEAN`/`HAS_HOOKS` mergeable PR with no
+outstanding change request, is **not** a blocker — that is normal in-flight state. (Such a PR with
+recent check/commit activity would already have been caught as `active` by the staleness gate.)
+
+**3. On a blocker found → file a leaf fix ticket + block the item.**
+
+1. **File one build-ready leaf fix ticket** per distinct blocker via `lisa:tracker-write` (the
+   vendor-neutral leaf writer + validation gate; never a vendor `*-write-*` skill directly),
+   `issue_type: Bug` for a failing-check/conflict/failed-deploy, `Task` for review-feedback
+   follow-up, `build_ready: true` so it auto-builds. The ticket MUST name: the blocked item + its
+   PR/deploy URL, the exact blocker (conflict / which checks failed with their logs link / which
+   change requests / which deploy run), three-audience description, and Gherkin acceptance criteria
+   for "PR is mergeable / deploy is green."
+2. **Transition the stalled item `claimed → blocked`** and add an **`is blocked by`** link to the
+   new fix ticket (vendor-native: JIRA issue link `is blocked by`; GitHub/Linear `Blocked by:` line
+   + label). Post a `[lisa-repair-intake]` note naming what it is blocked by and why.
+3. **Record it** as a repair write. Do **not** dispatch the vendor agent for this item this cycle.
+
+The item now sits in `blocked`; once the fix ticket reaches a terminal state, the **Build
+`blocked` → unblock if cleared** path (next section) detects the cleared `is blocked by`
+dependency and resumes the original in place — a self-healing loop.
+
+**Idempotency.** Before filing, check for an **open** fix ticket already carrying the marker
+`[lisa-repair-intake] blocker:<item-ref>/<blocker-key>` (blocker-key is a stable slug of the
+blocker, e.g. `pr-1234/merge-conflict` or `pr-1234/checks-failing`). If one exists, reference it
+and ensure the `is blocked by` link is present rather than creating a duplicate. Honor the backoff
+window and state fingerprint (Loop prevention) so re-runs over the same unchanged blocker are no-ops.
+
 ### Build `blocked` → re-evaluate, unblock if cleared
 
 1. Read the block reason and dependencies (see Dependency clearing).
@@ -399,7 +476,7 @@ cron tick.
 - Before writing a note or re-attempting a `blocked` item, compute the current fingerprint. If
   an identical fingerprint was already posted within the **backoff window**, skip the item
   silently (record as `still_blocked` / `active`, no write).
-- Backoff window default = `stale_after` (24h). `force=true` bypasses backoff for a manual run.
+- Backoff window default = `stale_after` (2h). `force=true` bypasses backoff for a manual run.
 - A *changed* fingerprint (new blocker state, new answers, new verdict) always warrants a fresh
   note + re-attempt — backoff suppresses only no-op repeats.
 

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

@@ -0,0 +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."
+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-expo:exploratory-qa. $ARGUMENTS

package/plugins/src/expo/commands/exploratory-qa.md

@@ -1,7 +1,7 @@
 ---
-description: "Run a Playwright-backed exploratory QA pass: audit the app like a human, find user-noticeable bugs, usability issues, and gaps in automated test coverage, and file each finding as a tracked work item via lisa:tracker-write. The optional ready flag marks bug/suggestion tickets build-ready (auto-picked-up by lisa:intake) or leaves them in the backlog for human triage (default); missing-test tickets are always build-ready."
+description: "Run a first-time-user exploratory QA walkthrough: experience the app like a brand-new human user, clicking through to find anything confusing, broken, or hard to understand (machine-style labels, slow or unclear loads, cramped or cut-off UI, inconsistent UX, awkward scroll behavior) across all breakpoints, and file each finding (bug or usability issue) as a tracked work item via lisa:tracker-write. The optional ready flag marks tickets build-ready (auto-picked-up by lisa:intake) or leaves them in the backlog for human triage (default). For gaps in the automated Playwright suite, use e2e-coverage-gaps instead."
 allowed-tools: ["Skill"]
 argument-hint: "[target-url | env] [ready=true|false]"
 ---
 
-Use the /lisa-expo:exploratory-qa skill to run a human-style exploratory QA pass informed by the existing Playwright suite, then file every finding (bugs, usability issues, missing Playwright tests) as a tracked work item via lisa:tracker-write — bug/suggestion tickets build-ready or in triage per the ready flag (default: triage), missing-test tickets always build-ready. $ARGUMENTS
+Use the /lisa-expo:exploratory-qa skill to experience the app like a brand-new first-time user — landing cold on the home page and clicking through to find anything confusing, broken, or hard to understand across all breakpoints — and file each finding (bugs, usability/clarity issues) as a tracked work item via lisa:tracker-write, build-ready or in triage per the ready flag (default: triage). For automated Playwright coverage gaps, use /lisa-expo:e2e-coverage-gaps. $ARGUMENTS