@codyswann/lisa 2.187.3 → 2.188.0

package/plugins/lisa-cursor/skills/product-walkthrough/SKILL.md

@@ -1,88 +1,62 @@
 ---
 name: product-walkthrough
-description: "Methodology for evaluating the live product via a real browser (Playwright MCP) when planning work or evaluating a PRD. Reading a PRD or a mock without seeing the current product produces tickets that misjudge the change — this skill grounds the analysis in what actually exists today. Invoke this skill from notion-to-tracker (Phase 2b live-product walkthrough), jira-create, and any PRD intake flow whose work touches existing user-facing surfaces."
+description: "Methodology for evaluating the live product when planning work or evaluating a PRD. Reading a PRD or a mock without seeing the current product produces tickets that misjudge the change — this skill grounds the analysis in what actually exists today. Driving the product is owned by the `use-the-product` core (which detects the product type — DOM web, HTTP/API, canvas game, CLI, IaC — resolves the per-environment mutation policy from .lisa.config.json so production is never mutated by accident, and explores through the project's personas when defined); this skill adds the planning lens. Invoke from notion-to-tracker (Phase 2b live-product walkthrough), jira-create, and any PRD intake flow whose work touches existing user-facing surfaces."
 allowed-tools: ["Skill", "Bash", "Read", "mcp__plugin_playwright_playwright__browser_navigate", "mcp__plugin_playwright_playwright__browser_snapshot", "mcp__plugin_playwright_playwright__browser_take_screenshot", "mcp__plugin_playwright_playwright__browser_click", "mcp__plugin_playwright_playwright__browser_type", "mcp__plugin_playwright_playwright__browser_select_option", "mcp__plugin_playwright_playwright__browser_fill_form", "mcp__plugin_playwright_playwright__browser_press_key", "mcp__plugin_playwright_playwright__browser_hover", "mcp__plugin_playwright_playwright__browser_navigate_back", "mcp__plugin_playwright_playwright__browser_resize", "mcp__plugin_playwright_playwright__browser_tabs", "mcp__plugin_playwright_playwright__browser_console_messages", "mcp__plugin_playwright_playwright__browser_network_requests", "mcp__plugin_playwright_playwright__browser_wait_for", "mcp__plugin_playwright_playwright__browser_close"]
 ---
 
 # Live Product Walkthrough
 
-Reading a PRD or a mock without seeing the current product produces tickets that misjudge the change. This skill defines how to use a real browser (via Playwright MCP) to evaluate the live product *before* planning tickets, so the work is grounded in what actually exists today.
+Reading a PRD or a mock without seeing the current product produces tickets that misjudge the change. This skill defines how to evaluate the live product *before* planning tickets, so the work is grounded in what actually exists today.
+
+**How you drive the product is owned by the `use-the-product` core skill** — it detects the product type (web / API / game / CLI / IaC), resolves the target environment and its **mutation policy** from `.lisa.config.json`, and discovers the project's **personas**. A walkthrough is read-leaning: prefer the policy's **read-only** actions, and only mutate when both the policy allows it (`full`) and a flow genuinely can't be understood without it. This skill adds the **planning lens** below.
 
 ## When to invoke
 
 Always run a walkthrough when the work touches user-facing surfaces:
 
 - The PRD describes a change to an existing screen, flow, or interaction
-- The PRD adds something *next to* existing functionality (entry points, navigation, related screens)
+- The PRD adds something *next to* existing functionality (entry points, navigation, related surfaces)
 - A mock or prototype implies a re-style or re-flow of something currently shipped
 - The change is a "bug" framed as a fix to current behavior — you must see the current behavior before reasoning about the fix
 
-Skip when the work is purely backend with no user-visible surface, type-only, doc-only, or affects a screen that does not yet exist in production / dev.
-
-## Configuration
-
-Required inputs (ask if not set):
-
-| Variable | Purpose | Example |
-|----------|---------|---------|
-| `E2E_BASE_URL` | Frontend base URL to walk through | `https://dev.example.io/` |
-| Sign-in account | Test user to sign in as for the affected flows | from PRD config / 1Password / env |
-| Sign-in credentials | How to obtain (1Password item, env vars) | `E2E_TEST_PHONE`, `E2E_TEST_OTP` |
-
-Walk through `dev` (or the env named in the PRD) — never `prod` for exploratory walkthroughs unless explicitly asked.
+Skip when the work is purely internal (type-only, doc-only) or affects a surface that does not yet exist in production / dev.
 
-## Process
+## 1. Plan the walkthrough
 
-### 1. Plan the walkthrough
+Before driving anything, list the surfaces the change will touch:
 
-Before opening the browser, list the surfaces the change will touch:
-
-- Which screens/routes are involved (current and new)?
+- Which screens/routes/endpoints are involved (current and new)?
 - Which user roles need to be exercised (admin / customer / etc.)?
 - Which states matter (signed-out, signed-in, empty, populated, error, loading)?
-- Which viewports matter (desktop always; mobile when responsive; tablet rarely)?
-
-Write this list down. If you can't, the PRD is too vague — note this as a coverage smell and surface it as an Open Question on the resulting ticket.
-
-### 2. Open the browser and sign in
+- For a DOM web app, which viewports matter (desktop always; mobile when responsive)?
 
-1. `browser_navigate` to `E2E_BASE_URL`.
-2. `browser_resize` to the primary viewport (default desktop 1512×768).
-3. Sign in via the test account. Use `browser_fill_form` and `browser_click`. Capture the post-login screen with `browser_snapshot` or `browser_take_screenshot`.
+Write this list down. If you can't, the PRD is too vague — note it as a coverage smell and surface it as an Open Question on the resulting ticket.
 
-### 3. Walk the affected surfaces
+## 2. Drive the current product
 
-For each surface from step 1:
+**Invoke `use-the-product`** to detect the type, resolve the environment + mutation policy, and discover personas — then drive the surfaces from step 1 through its per-type playbook (browser for DOM, `curl` for an API, canvas+input for a game, `cdk synth`/`diff` for IaC). Capture evidence as you go: for a DOM app, a `browser_snapshot` (accessibility tree — best for reasoning) and a `browser_take_screenshot` (visual) per surface and per state, plus `browser_console_messages` / `browser_network_requests` after interactions; for an API, representative request/response pairs; for a game, screenshots of each state. If the project defines personas, walk the surfaces as the relevant archetype(s).
 
-1. Navigate to it. Capture a `browser_snapshot` (accessibility tree — better for reasoning) and a `browser_take_screenshot` (visual evidence).
-2. Exercise the relevant interactions. Capture state transitions.
-3. Capture each state that matters (empty, populated, error, loading) — explicitly trigger them where possible.
-4. For responsive changes, `browser_resize` to the secondary viewport (mobile 375×812) and re-capture.
-5. `browser_console_messages` and `browser_network_requests` after each interaction — surface any errors, 4xx/5xx, or unexpected calls.
+Honor the mutation gate: on a `read-only` env, observe without submitting; never walk a `forbidden` env (production defaults to forbidden). Treat console errors, 4xx/5xx, and unexpected calls as findings.
 
-### 4. Record findings
+## 3. Record findings
 
 For every walkthrough, record:
 
-- **What exists today**: a short prose description of the current flow, the components in use (if you can identify them from the DOM via `browser_snapshot`), and the states observed.
-- **What the PRD changes**: explicit delta — added screens, removed screens, modified components, new states, removed states.
-- **Existing-component reuse candidates**: components in the current product that could absorb the new behavior. The PRD-vs-current-product comparison drives which existing components a developer should reuse instead of building new (see `lisa:tracker-source-artifacts` §7).
-- **Design-vs-current-product divergence**: places where the mock/prototype materially diverges from what's shipped. Each divergence is a discussion item, not an automatic "rebuild from scratch" — see `lisa:tracker-source-artifacts` §3 (mocks define visual intent, not implementation shortcut).
-- **Coverage smells**: states the PRD doesn't address that exist today (e.g., the mock shows the empty state but ignores the populated state that has 90% of users).
-- **Behavioral surprises**: anything that doesn't match the PRD's assumptions about current behavior — these are usually the most valuable findings, because they invalidate parts of the PRD.
+- **What exists today**: a short prose description of the current flow, the components/endpoints in use (identify them from the snapshot/routes where you can), and the states observed.
+- **What the PRD changes**: explicit delta — added / removed / modified surfaces, new/removed states.
+- **Existing-component reuse candidates**: components or endpoints in the current product that could absorb the new behavior (see `lisa:tracker-source-artifacts` §7).
+- **Design-vs-current-product divergence**: where the mock/prototype materially diverges from what's shipped. Each divergence is a discussion item, not an automatic rebuild (see `lisa:tracker-source-artifacts` §3).
+- **Coverage smells**: states the PRD doesn't address that exist today (e.g. the mock shows the empty state but ignores the populated state 90% of users see).
+- **Behavioral surprises**: anything that doesn't match the PRD's assumptions about current behavior — usually the most valuable findings, because they invalidate parts of the PRD.
 
-### 5. Attach evidence to the originating context
+## 4. Attach evidence and close
 
-Capture screenshots/snapshots in a way that the originating ticket / Notion comment / PRD review can reference them.
+Capture evidence so the originating ticket / Notion comment / PRD review can reference it. Close the session when done (`browser_close` for a browser) — walkthroughs are short, focused, and one-shot.
 
-- For **PRD intake**: include a "Current Product" comment on the Notion PRD with the findings prose and inline screenshots of the current state alongside each affected screen mentioned in the PRD.
-- For **ticket creation**: include the findings under `## Current Product` in the ticket description (Story or Epic). Reference the screenshots as remote links if hosted, or inline them as attachments.
+- For **PRD intake**: include a "Current Product" comment on the Notion PRD with the findings prose and inline screenshots alongside each affected surface.
+- For **ticket creation**: include the findings under `## Current Product` in the ticket description (Story or Epic). Reference screenshots as remote links or attachments.
 - For **change-impact analysis**: produce a short report; the consuming skill decides where it lands.
 
-### 6. Close the browser
-
-`browser_close` when done. Walkthroughs are short, focused, and one-shot — do not leave a session open across phases.
-
 ## Findings format
 
 Use this structure when emitting walkthrough findings, so consuming skills can splice them into tickets / comments unchanged. The `## Current Product` heading matches what `lisa:jira-write-ticket` Phase 4e expects to inherit — keep the heading exact.
@@ -90,15 +64,16 @@ Use this structure when emitting walkthrough findings, so consuming skills can s
 ```text
 ## Current Product
 
-**Environment**: <E2E_BASE_URL> as <account/role>
-**Viewports exercised**: Desktop 1512×768, Mobile 375×812
+**Environment**: <target> as <account/role> (<mutation level>)
+**Explored as**: <persona(s) or "generic representative user">
+**Viewports exercised**: Desktop 1512×768, Mobile 375×812   (DOM web only)
 
 ### Surfaces walked
-1. <route> — <one-line current behavior>
-2. <route> — <one-line current behavior>
+1. <route/endpoint/screen> — <one-line current behavior>
+2. <route/endpoint/screen> — <one-line current behavior>
 
 ### What exists today
-<2-4 sentence prose summary of the current flow and components in use>
+<2-4 sentence prose summary of the current flow and components/endpoints in use>
 
 ### Delta vs. PRD
 - ADDED: <new surface/state from PRD>
@@ -107,23 +82,23 @@ Use this structure when emitting walkthrough findings, so consuming skills can s
 - UNCHANGED-BUT-IMPACTED: <existing surface PRD doesn't mention but will be affected>
 
 ### Existing-component reuse candidates
-- <component or screen> — could absorb <new behavior>
+- <component / endpoint / screen> — could absorb <new behavior>
 
 ### Design-vs-current-product divergence
-- <mock or prototype reference> diverges from <current screen> in: <specific dimension>
+- <mock or prototype reference> diverges from <current surface> in: <specific dimension>
 - Recommendation: <reuse / new build / discussion>
 
 ### Coverage smells & behavioral surprises
 - <smell or surprise>
 
 ### Evidence
-- <list of screenshots/snapshots, with captions>
+- <list of screenshots/snapshots/request-response pairs, with captions>
 ```
 
 ## Rules
 
 - Walk before you write. If the work touches existing user-facing surfaces and the walkthrough wasn't done, the resulting ticket is missing context — don't ship it.
-- Never walk `prod` for exploratory analysis. `dev` (or the env named in the PRD) only.
+- Never walk a `forbidden` environment (production is forbidden by default). Use `dev`/`staging` per the `exploration` config, and default to read-only for a planning walkthrough.
 - Treat console errors and unexpected network calls as findings — they often reveal undocumented behavior the PRD assumes is fine.
 - Findings drive `## Open Questions` on tickets, not silent assumptions. If the current product contradicts the PRD, surface it as a BLOCKER.
-- This skill captures observations; it does not edit JIRA or the PRD. Consuming skills decide where findings land (ticket description, Notion comment, validator input).
+- This skill captures observations; it does not edit the tracker or the PRD. Consuming skills decide where findings land.

package/plugins/lisa-cursor/skills/use-the-product/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: use-the-product
+description: Shared methodology for actually USING a project's product the way its real end user would — across product types (DOM web app, HTTP/API backend, canvas game, CLI/library, IaC/CDK). Detects the product's consumer-facing interface, drives it as that consumer, gated by a per-environment mutation policy read from .lisa.config.json (so the agent never mutates production data by accident), and lensed through the project's personas/subagents when it defines them. Invoked by exploratory-qa (files defect/UX tickets) and product-walkthrough (grounds planning in the live product); rarely run standalone.
+---
+
+# Use the Product
+
+## The one idea
+
+Every product has a **consumer-facing interface**. To evaluate a product you (1) **detect** that interface, (2) **resolve where you're allowed to drive it and how much you may change**, and (3) **drive it as the real consumer would** — through the project's personas when it has them. This skill owns steps 1–4 below; the **caller** decides what to *do* with what you find (`exploratory-qa` files tickets, `product-walkthrough` grounds planning).
+
+Driving the product means **interacting** with it. Static route scans, HTTP fetches, screenshots-alone, and reading the code are *supporting evidence only* — never a substitute for actually using it.
+
+## 1. Detect the product type & interface
+
+Infer from the repo; if genuinely ambiguous, ask one concise question.
+
+| Signals | Type | Consumer-facing interface |
+|---|---|---|
+| `vite`/`next`/`angular`/`svelte` + `index.html`, DOM UI | **DOM web app** | the rendered UI in a real browser |
+| API server (`nest`/`express`/`fastify`/serverless handlers), OpenAPI, no frontend | **HTTP / API backend** | the API endpoints |
+| `phaser`/`pixi`/canvas game | **Canvas game** | the canvas + input (keyboard/pointer), read visually |
+| `cdk.json` / Terraform / IaC | **IaC / CDK** | the resources it provisions (+ synth output) |
+| `bin/` CLI or published library, no server | **CLI / library** | the commands / public API |
+
+## 2. Resolve the environment & mutation policy — the gate
+
+Read the `exploration` block from `.lisa.config.json` (a repo-local config overrides a global one):
+
+```jsonc
+"exploration": {
+  "default": "<env-name>",              // which env to use when none is passed
+  "environments": {
+    "<name>": {
+      "url": "https://dev.example.io",  // web/API target (omit for local CLI/game)
+      "provision": true,                // IaC/ephemeral: stand up, then tear down
+      "mutation": "forbidden | read-only | full",
+      "identity": "<test-account ref>", // which login to use (env var / 1Password ref)
+      "prodMutationAck": "<one sentence>" // REQUIRED to allow `full` on a production-named env
+    }
+  }
+}
+```
+
+Resolve the target env: explicit argument → `default` → infer. Then the **mutation level governs everything**:
+
+- **`read-only`** — only non-mutating interactions: read endpoints (`GET`), view UI without submitting, `cdk synth`/`diff`, `--help`/dry-run. Never create / edit / delete.
+- **`full`** — create / edit / delete allowed, but **only as the `identity` test account** and under Mutation Discipline (§5).
+- **`forbidden`** — do not exercise this environment at all.
+
+**Safety rules — enforced regardless of config:**
+
+- **No `exploration` block, or an unconfigured env → treat as `read-only`.** Never mutate without an explicit policy.
+- **A production-named env (`prod` / `production`) defaults to `forbidden`.** It may be raised to `full` **only** when a written `prodMutationAck` justification is present (this is how a single-environment app — e.g. a local-only game whose only "env" is production and whose mutations are the user's own local save — deliberately opts in). A bare `production: { "mutation": "full" }` with **no** `prodMutationAck` is downgraded to `forbidden`, and you warn.
+- **Never sign in as a real user or an admin** — only the `identity` test account.
+- If evaluating something *requires* a mutation the policy forbids, stop at that boundary and report it — never escalate your own permissions.
+
+## 3. Discover personas & subagents — soft-detect
+
+Look for the project's personas: `wiki/personas/**` (target-player archetypes, stakeholders) and persona subagents (e.g. the `lisa-phaser` `target-player` / `player-advocate` agents).
+
+- **Present** → drive the product **through each relevant persona**: adopt the archetype's constraints (device, session length, goals, patience, genre-literacy) and evaluate as them; run each archetype for breadth.
+- **Absent** → drive as a single **generic representative end user** of the app's stated audience, and say so.
+
+## 4. Drive the product — per type
+
+Apply the interface's *read-only* actions always; the *mutate* actions only when the policy is `full`.
+
+- **DOM web app** — a real browser (Playwright MCP). Land cold on the entry page, then click / type / select / submit visible controls and attempt real tasks; sweep viewport widths. *(The caller's lens supplies the specific things to look for.)*
+- **HTTP / API backend** — the consumer is a client, not a browser. Read-only: read the OpenAPI/routes and call safe `GET`s (`curl`/`httpie`). Mutate: exercise representative `POST`/`PUT`/`DELETE` flows with test data as the `identity`; check status codes, payload shapes, and error responses.
+- **Canvas game** — a real browser, but the UI is **drawn to a canvas, not the DOM**. Boot it (e.g. `bun run dev` + Playwright), drive via **keyboard/pointer into the canvas**, and read state **visually via screenshots** (not the accessibility tree). Mutation is usually local save state. Judge readability, game-feel, and input responsiveness — not DOM breakpoints.
+- **CLI / library** — the interface is the command / public API. Read-only: `--help`, read-only commands, dry-runs. Mutate: run state-changing commands with disposable inputs.
+- **IaC / CDK** — the "user" is whoever **consumes the resources the stack provisions** (plus the operator). **Read-only (default):** `cdk synth` → read the generated template; `cdk diff` vs. the deployed env; verify the resources, IAM, and outputs express what a consumer would expect. Flag over-broad IAM, missing/opaque outputs, resources that don't serve their stated purpose, and drift. **Mutate (only when `mutation: "full"` *and* `provision: true` on an ephemeral/sandbox env):** `cdk deploy` to the sandbox → recurse into the API/web playbook against the provisioned resources → `cdk destroy`. Never deploy to a real account without explicit sandbox-provisioning config.
+
+## 5. Mutation Discipline — only when the policy is `full`
+
+A real user creates, edits, and deletes things — exercise those flows when, and only when, the policy allows and always as the `identity` account.
+
+- 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, then verify it. If cleanup is unavailable, that itself is a finding.
+- Avoid destructive bulk actions unless the account/data is clearly disposable.
+- Record every mutation performed, cleanup attempts, and any residue left behind.
+
+## What you return
+
+Structured, raw observations for the caller — **what** you did, **as whom** (which persona / generic user), **where** (env + mutation level), **what you saw**, and **what you could not reach and why** (especially policy boundaries you stopped at). You do **not** file tickets or write plans; the caller does.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.187.3",
+  "version": "2.188.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.187.3",
+  "version": "2.188.0",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

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

@@ -4,4 +4,4 @@ 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
+Use the /lisa-expo:e2e-coverage-gaps skill to inventory the app's routes and the existing Playwright suite, find uncovered and happy-path-only paths, confirm each gap in the running app, and file one build-ready missing-test ticket per gap via lisa:tracker-write (build-ready per the ready flag, default true). For human usability/experience findings, use /lisa:exploratory-qa. $ARGUMENTS

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

@@ -4,4 +4,4 @@ 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
+Use the /lisa-expo:e2e-coverage-gaps skill to inventory the app's routes and the existing Playwright suite, find uncovered and happy-path-only paths, confirm each gap in the running app, and file one build-ready missing-test ticket per gap via lisa:tracker-write (build-ready per the ready flag, default true). For human usability/experience findings, use /lisa:exploratory-qa. $ARGUMENTS

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

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

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

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

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

@@ -4,4 +4,4 @@ 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
+Use the /lisa-expo:e2e-coverage-gaps skill to inventory the app's routes and the existing Playwright suite, find uncovered and happy-path-only paths, confirm each gap in the running app, and file one build-ready missing-test ticket per gap via lisa:tracker-write (build-ready per the ready flag, default true). For human usability/experience findings, use /lisa:exploratory-qa. $ARGUMENTS

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

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

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

@@ -4,4 +4,4 @@ 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
+Use the /lisa-expo:e2e-coverage-gaps skill to inventory the app's routes and the existing Playwright suite, find uncovered and happy-path-only paths, confirm each gap in the running app, and file one build-ready missing-test ticket per gap via lisa:tracker-write (build-ready per the ready flag, default true). For human usability/experience findings, use /lisa:exploratory-qa. $ARGUMENTS

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/commands/e2e-coverage-gaps.md

@@ -4,4 +4,4 @@ allowed-tools: ["Skill"]
 argument-hint: "[target-url | env] [ready=true|false]"
 ---
 
-Use the /lisa-harper-fabric: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-harper-fabric:exploratory-qa. $ARGUMENTS
+Use the /lisa-harper-fabric:e2e-coverage-gaps skill to inventory the app's routes and the existing Playwright suite, find uncovered and happy-path-only paths, confirm each gap in the running app, and file one build-ready missing-test ticket per gap via lisa:tracker-write (build-ready per the ready flag, default true). For human usability/experience findings, use /lisa:exploratory-qa. $ARGUMENTS

package/plugins/lisa-harper-fabric-agy/commands/e2e-coverage-gaps.md

@@ -4,4 +4,4 @@ allowed-tools: ["Skill"]
 argument-hint: "[target-url | env] [ready=true|false]"
 ---
 
-Use the /lisa-harper-fabric: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-harper-fabric:exploratory-qa. $ARGUMENTS
+Use the /lisa-harper-fabric:e2e-coverage-gaps skill to inventory the app's routes and the existing Playwright suite, find uncovered and happy-path-only paths, confirm each gap in the running app, and file one build-ready missing-test ticket per gap via lisa:tracker-write (build-ready per the ready flag, default true). For human usability/experience findings, use /lisa:exploratory-qa. $ARGUMENTS

package/plugins/lisa-harper-fabric-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-copilot/commands/e2e-coverage-gaps.md

@@ -4,4 +4,4 @@ allowed-tools: ["Skill"]
 argument-hint: "[target-url | env] [ready=true|false]"
 ---
 
-Use the /lisa-harper-fabric: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-harper-fabric:exploratory-qa. $ARGUMENTS
+Use the /lisa-harper-fabric:e2e-coverage-gaps skill to inventory the app's routes and the existing Playwright suite, find uncovered and happy-path-only paths, confirm each gap in the running app, and file one build-ready missing-test ticket per gap via lisa:tracker-write (build-ready per the ready flag, default true). For human usability/experience findings, use /lisa:exploratory-qa. $ARGUMENTS

package/plugins/lisa-harper-fabric-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-cursor/commands/e2e-coverage-gaps.md

@@ -4,4 +4,4 @@ allowed-tools: ["Skill"]
 argument-hint: "[target-url | env] [ready=true|false]"
 ---
 
-Use the /lisa-harper-fabric: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-harper-fabric:exploratory-qa. $ARGUMENTS
+Use the /lisa-harper-fabric:e2e-coverage-gaps skill to inventory the app's routes and the existing Playwright suite, find uncovered and happy-path-only paths, confirm each gap in the running app, and file one build-ready missing-test ticket per gap via lisa:tracker-write (build-ready per the ready flag, default true). For human usability/experience findings, use /lisa:exploratory-qa. $ARGUMENTS

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -4,4 +4,4 @@ allowed-tools: ["Skill"]
 argument-hint: "[target-url | env] [ready=true|false]"
 ---
 
-Use the /lisa-rails: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-rails:exploratory-qa. $ARGUMENTS
+Use the /lisa-rails:e2e-coverage-gaps skill to inventory the app's routes and the existing Playwright suite, find uncovered and happy-path-only paths, confirm each gap in the running app, and file one build-ready missing-test ticket per gap via lisa:tracker-write (build-ready per the ready flag, default true). For human usability/experience findings, use /lisa:exploratory-qa. $ARGUMENTS

package/plugins/lisa-rails-agy/commands/e2e-coverage-gaps.md

@@ -4,4 +4,4 @@ allowed-tools: ["Skill"]
 argument-hint: "[target-url | env] [ready=true|false]"
 ---
 
-Use the /lisa-rails: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-rails:exploratory-qa. $ARGUMENTS
+Use the /lisa-rails:e2e-coverage-gaps skill to inventory the app's routes and the existing Playwright suite, find uncovered and happy-path-only paths, confirm each gap in the running app, and file one build-ready missing-test ticket per gap via lisa:tracker-write (build-ready per the ready flag, default true). For human usability/experience findings, use /lisa:exploratory-qa. $ARGUMENTS

package/plugins/lisa-rails-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.187.3",
+  "version": "2.188.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"