@codyswann/lisa 2.110.1 → 2.112.0

package/package.json

@@ -82,7 +82,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.110.1",
+  "version": "2.112.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.110.1",
+  "version": "2.112.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.110.1",
+  "version": "2.112.0",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/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/lisa/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/lisa/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/lisa-cdk/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.110.1",
+  "version": "2.112.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.110.1",
+  "version": "2.112.0",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

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

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

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

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

package/plugins/lisa-expo/.mcp.json

@@ -1,8 +1,8 @@
 {
   "mcpServers": {
-    "expo-docs": {
-      "command": "npx",
-      "args": ["expo-local-docs-mcp"]
+    "expo": {
+      "type": "http",
+      "url": "https://mcp.expo.dev/mcp"
     }
   }
 }

package/plugins/lisa-expo/THIRD-PARTY-NOTICES.md

@@ -0,0 +1,57 @@
+# Third-Party Notices
+
+## Official Expo skills (vendored)
+
+The following skills under `skills/` are vendored verbatim from Expo's official
+plugin and are **not** Lisa-authored. Do not hand-edit them; re-vendor from
+upstream to update.
+
+- **Source:** https://github.com/expo/skills (`plugins/expo/skills/`)
+- **Upstream commit:** `510373b50956ef4dc84c20bb4c9cce70b618aa06`
+- **License:** MIT — Copyright (c) 2025-present 650 Industries, Inc. (aka Expo)
+
+Vendored skills:
+
+```
+add-app-clip            expo-cicd-workflows     expo-ui-jetpack-compose
+building-native-ui      expo-deployment         expo-ui-swift-ui
+eas-update-insights     expo-dev-client         native-data-fetching
+expo-api-routes         expo-module             upgrading-expo
+expo-brownfield         expo-tailwind-setup     use-dom
+```
+
+These ship alongside Lisa's own opinionated Expo/React Native skills
+(`apollo-client`, `gluestack-nativewind`, `container-view-pattern`, etc.), which
+they complement rather than replace. Notably both `expo-tailwind-setup`
+(Tailwind v4 / NativeWind v5) and Lisa's `gluestack-nativewind` (Gluestack v3 /
+NativeWind v4) are kept intentionally; choose per project.
+
+The accompanying `expo` MCP server in `.mcp.json` points at Expo's official
+remote server (`https://mcp.expo.dev/mcp`), replacing the previously bundled
+third-party `expo-local-docs-mcp` stdio server.
+
+### MIT License
+
+```
+The MIT License (MIT)
+
+Copyright (c) 2025-present 650 Industries, Inc. (aka Expo)
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+```

package/plugins/lisa-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/lisa-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

package/plugins/lisa-expo/skills/add-app-clip/SKILL.md

@@ -0,0 +1,280 @@
+---
+name: add-app-clip
+description: Add an iOS App Clip target to an Expo app. Use when the user mentions App Clip, AASA, apple-app-site-association, appclips, smart app banner, or wants to ship a lightweight iOS Clip invoked from a URL alongside their parent app.
+---
+
+# Add an App Clip to an Expo App
+
+Adds an iOS App Clip target to an Expo project. The Clip lives in `targets/clip/`, ships alongside the parent app, and is invoked from a URL on the app's domain via an Apple App Site Association (AASA) file.
+
+The parent app's bundle ID becomes `com.<username>.<app-name>` and the Clip's is automatically derived as `<parent>.clip` (e.g. `com.bacon.may20.clip`).
+
+## 1. Set `bundleIdentifier` and `appleTeamId`
+
+`bun create target` warns if these are missing. Add to `app.json`:
+
+```json
+{
+  "expo": {
+    "ios": {
+      "bundleIdentifier": "com.<username>.<app-name>",
+      "appleTeamId": "XX57RJ5UTD"
+    }
+  }
+}
+```
+
+## 2. Add the App Clip target
+
+```sh
+bun create target clip
+```
+
+This installs [`@bacons/apple-targets`](https://github.com/EvanBacon/expo-apple-targets), adds it to the `plugins` array in `app.json`, and writes:
+
+- `targets/clip/expo-target.config.js` — the target's config plugin
+- `targets/clip/Info.plist` — Clip Info.plist
+- `targets/clip/AppDelegate.swift`, `Assets.xcassets`, etc.
+
+Pick a good icon or reuse the existing one defined in the app — check it with `bunx expo config` under the `icon` or `ios.icon` key.
+
+## 3. Wire up associated domains
+
+The parent app and the Clip each need the Associated Domains entitlement pointing at the domain that hosts the AASA file.
+
+In `app.json`, add both `applinks:` (parent) and `appclips:` (Clip invocation) entries:
+
+```json
+{
+  "expo": {
+    "ios": {
+      "associatedDomains": [
+        "applinks:may20.expo.app",
+        "appclips:may20.expo.app"
+      ]
+    }
+  }
+}
+```
+
+In `targets/clip/expo-target.config.js`, declare the Clip's entitlement:
+
+```js
+/** @type {import('@bacons/apple-targets/app.plugin').ConfigFunction} */
+module.exports = (config) => ({
+  type: "clip",
+  icon: "https://github.com/expo.png",
+  entitlements: {
+    "com.apple.developer.associated-domains": ["appclips:may20.expo.app"],
+  },
+});
+```
+
+> If you skip this, `expo prebuild` will print: `Apple App Clip may require the associated domains entitlement but none were found`.
+
+## 4. Register bundle IDs and create the App Store entry
+
+```sh
+bunx setup-safari
+```
+
+This logs in to the Apple Developer account, registers `com.bacon.may20`, creates the App Store Connect entry, and prints:
+
+- A starter `apple-app-site-association` JSON
+- A `<meta name="apple-itunes-app">` tag with the iTunes app id
+- Team ID, iTunes ID, and Bundle ID
+
+## 5. Host the AASA file
+
+App Clips are invoked when iOS fetches `https://<your-domain>/.well-known/apple-app-site-association` and finds a matching `appclips` entry.
+
+```sh
+mkdir -p public/.well-known
+touch public/.well-known/apple-app-site-association
+```
+
+Paste the JSON `setup-safari` printed, but **add an `appclips` block** for the Clip's full app ID (`<TeamID>.<ClipBundleID>`). The output of `setup-safari` only covers the parent app:
+
+```json
+{
+  "applinks": {
+    "details": [
+      {
+        "appIDs": ["XX57RJ5UTD.com.bacon.may20"],
+        "components": [{ "/": "*", "comment": "Matches all routes" }]
+      }
+    ]
+  },
+  "appclips": {
+    "apps": ["XX57RJ5UTD.com.bacon.may20.clip"]
+  },
+  "activitycontinuation": {
+    "apps": ["XX57RJ5UTD.com.bacon.may20"]
+  },
+  "webcredentials": {
+    "apps": ["XX57RJ5UTD.com.bacon.may20"]
+  }
+}
+```
+
+Notes:
+
+- The file has **no extension** and **no `Content-Type` requirements** beyond being served as-is. Expo Router static export serves files in `public/` verbatim.
+- The `appclips` block is what lets a URL on the domain launch the Clip.
+- `webcredentials` is used for sharing credentials between the website, parent app, and the App Clip.
+- `activitycontinuation` is optional and used for sharing the link between mobile and desktop. Must be used with `Head` from expo-router — see https://docs.expo.dev/router/advanced/apple-handoff/
+- Notation and route-disabling details: https://sosumi.ai/documentation/xcode/supporting-associated-domains
+
+## 6. Add the Smart App Banner meta tag
+
+Create `src/app/+html.tsx` (Expo Router's HTML shell) and add the tag from `setup-safari`. Create the versioned template if it doesn't exist:
+
+```sh
+bunx expo customize src/app/+html.tsx
+```
+
+Add the meta tag to the `<head>`:
+
+```tsx
+import { ScrollViewStyleReset } from "expo-router/html";
+
+export default function Root({ children }: { children: React.ReactNode }) {
+  return (
+    <html lang="en">
+      <head>
+        <meta charSet="utf-8" />
+        <meta httpEquiv="X-UA-Compatible" content="IE=edge" />
+        <meta name="viewport" content="width=device-width, initial-scale=1" />
+        <meta name="apple-itunes-app" content="app-id=6771566491" />
+        <ScrollViewStyleReset />
+      </head>
+      <body>{children}</body>
+    </html>
+  );
+}
+```
+
+To make the website show the App Clip card instead of the install card, use:
+
+```html
+<meta
+  name="apple-itunes-app"
+  content="app-id=6771566491, app-clip-bundle-id=com.bacon.may20.clip, app-clip-display=card"
+/>
+```
+
+## 7. Deploy the website
+
+The AASA file must be live before iOS will trust the association. Use [EAS Hosting](https://docs.expo.dev/eas/hosting/):
+
+```sh
+bunx expo export -p web
+eas deploy --prod
+```
+
+This publishes the site (including `/.well-known/apple-app-site-association`) at `https://<slug>.expo.app`. Verify:
+
+```sh
+curl https://may20.expo.app/.well-known/apple-app-site-association
+```
+
+## 8. Mirror permissions
+
+Inspect the parent app's permissions after prebuild:
+
+```sh
+npx expo config --type introspect
+```
+
+Look at the `infoPlist` object — mirror the permission keys in the App Clip's `Info.plist` so matching APIs can be used from the Clip.
+
+Set `deploymentTarget: "17.6"` in the Clip's target config — App Clips have a higher minimum size limit in iOS 17.6.
+
+If the app uses push notifications or location services, add to the App Clip's `Info.plist` to request the necessary permissions:
+
+```xml
+<key>NSAppClip</key>
+<dict>
+  <key>NSAppClipRequestEphemeralUserNotification</key>
+  <false/>
+  <key>NSAppClipRequestLocationConfirmation</key>
+  <true/>
+</dict>
+```
+
+## 9. Build and submit to TestFlight
+
+```sh
+bunx testflight
+```
+
+This will:
+
+1. Generate an `eas.json` if missing.
+2. Set up credentials for **both** targets (parent + Clip). Each gets its own provisioning profile but can share a single Distribution Certificate.
+3. Sync capabilities — note `Enabled: Associated Domains` for the Clip target.
+4. Build, upload, and schedule a TestFlight submission.
+
+## 10. Configure App Clip metadata
+
+Pull existing App Store metadata to local:
+
+```sh
+eas metadata:pull
+```
+
+Add `apple.appClip` to `store.config.json`. Up to 3 invocation URLs can launch the Clip from a web page:
+
+```json
+{
+  "configVersion": 0,
+  "apple": {
+    "appClip": {
+      "defaultExperience": {
+        "action": "PLAY",
+        "releaseWithAppStoreVersion": true,
+        "reviewDetail": {
+          "invocationUrls": ["https://may20.expo.app/", null, null]
+        },
+        "info": {
+          "en-US": {
+            "subtitle": "Instantly native with Expo",
+            "headerImage": "store/apple/app-clip/en-US/asc-app-clip.png"
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+The `headerImage` must be a 1800x1200 PNG with no opacity.
+
+Push back to the store:
+
+```sh
+eas metadata:push
+```
+
+Apple's recommended App Clip metadata guidelines: https://sosumi.ai/documentation/appclip/configuring-the-launch-experience-of-your-app-clip
+
+## What you get
+
+- Parent app target: `com.bacon.may20`
+- App Clip target: `com.bacon.may20.clip`, lives in `targets/clip/`
+- AASA hosted at `https://may20.expo.app/.well-known/apple-app-site-association`
+- Smart App Banner meta tag on every web route
+- Every route linked to its native counterpart
+- TestFlight build of the parent app with the Clip embedded
+
+Once Apple invokes the Clip from a URL on the domain, iOS opens `targets/clip/`'s entry point which loads the React Native app.
+
+## Native detection (optional)
+
+To let JS detect when it's running inside an App Clip and present an install prompt for the full app, create a local Expo module (`bunx create-expo-module --local`) that exposes `navigator.appClip.prompt()`.
+
+See [./references/native-module.md](./references/native-module.md) for the Swift module, TypeScript interface, and usage.
+
+## References
+
+- ./references/native-module.md — Local Expo module to detect App Clip context and present the SKOverlay install prompt

package/plugins/lisa-expo/skills/add-app-clip/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Add App Clip"
+short_description: "Add an iOS App Clip target to an Expo app"
+default_prompt:
+  - "Use $add-app-clip: Add an iOS App Clip target to an Expo app."