@codyswann/lisa 2.189.7 → 2.189.8

package/plugins/lisa-rails-cursor/skills/e2e-coverage-gaps/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: e2e-coverage-gaps
-description: Playwright/e2e coverage-gap explorer that FEEDS THE LIFECYCLE. Use when asked to find paths the automated end-to-end suite does NOT cover — routes with no test at all, or flows that are only happy-path tested (missing error, validation, permission, empty, loading, and edge states). It inventories the app's routes and the existing Playwright tests, explores the running app to confirm each uncovered or under-covered path is real and reachable, and files one build-ready missing-test ticket per gap via lisa:tracker-write. For human usability/experience issues (confusing, cramped, or broken UI), use the exploratory-qa skill instead.
+description: Playwright/e2e coverage-gap explorer that FEEDS THE LIFECYCLE. Use when asked to find paths the automated end-to-end suite does NOT cover — routes with no test at all, or flows that are only happy-path tested (missing error, validation, permission, empty, loading, and edge states). It inventories the app's routes and the existing Playwright tests, explores the running app to confirm each uncovered or under-covered path is real and reachable, and files one build-ready missing-test ticket per gap via lisa-tracker-write. For human usability/experience issues (confusing, cramped, or broken UI), use the lisa-exploratory-qa skill instead.
 ---
 
 # E2E Coverage Gaps
@@ -14,7 +14,7 @@ is real and reachable, then file each gap as a **build-ready missing-test work i
 Lisa lifecycle.
 
 This skill is purely about **automated-coverage gaps**. It does not judge whether the UI is confusing
-or pretty — for human usability findings, use the `exploratory-qa` skill.
+or pretty — for human usability findings, use the `lisa-exploratory-qa` skill.
 
 ## Parameters
 
@@ -67,7 +67,7 @@ Map routes/flows against existing coverage and classify each gap:
 
 ### 6. File One Ticket Per Gap
 
-Each confirmed gap becomes a leaf **missing-test** work item created via `lisa:tracker-write` (the
+Each confirmed gap becomes a leaf **missing-test** work item created via `lisa-tracker-write` (the
 vendor-neutral writer — it dispatches to the configured tracker and runs the validation gate; never
 call a vendor `*-write-*` skill directly), `issue_type: Task`, **build-ready per the `ready` flag
 (default `true`)**. Pass `build_ready` explicitly on every create. Each ticket MUST specify:
@@ -101,5 +101,5 @@ No report file. Emit a concise in-session summary:
 - Every ticket must stand alone for an implementer who was not in the session and must be concretely
   automatable (named route, behavior, and stable hook).
 - Do not refile gaps already covered or already ticketed (marker check).
-- This skill is about automated coverage only — route human usability issues to `exploratory-qa`.
+- This skill is about automated coverage only — route human usability issues to `lisa-exploratory-qa`.
 - Preserve unrelated repo changes.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.189.7",
+  "version": "2.189.8",
   "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.189.7",
+  "version": "2.189.8",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.189.7",
+  "version": "2.189.8",
   "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-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.189.7",
+  "version": "2.189.8",
   "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-cursor/.claude-plugin/plugin.json

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.189.7",
+  "version": "2.189.8",
   "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.189.7",
+  "version": "2.189.8",
   "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/skills/lisa-wiki-add-ingest/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Add Ingest"
+display_name: "Wiki Add Ingest"
 short_description: "Scaffold a project-specific \"front-door\" ingest skill that does something unique (classify a source, fetch from a special system, stamp…"
 default_prompt:
   - "Use $lisa-wiki-add-ingest: Scaffold a project-specific \"front-door\" ingest skill that does something unique (classify a source, fetch from a special system, stamp…."

package/plugins/lisa-wiki/skills/lisa-wiki-add-role/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Add Role"
+display_name: "Wiki Add Role"
 short_description: "Scaffold a domain-expert \"digital staff\" role over the wiki — a dual-runtime subagent (Claude + Codex) plus a staff doc page — from a…"
 default_prompt:
   - "Use $lisa-wiki-add-role: Scaffold a domain-expert \"digital staff\" role over the wiki — a dual-runtime subagent (Claude + Codex) plus a staff doc page — from a…."

package/plugins/lisa-wiki/skills/lisa-wiki-connector-confluence/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Connector Confluence"
+display_name: "Wiki Connector Confluence"
 short_description: "Produce sanitized Confluence source notes for lisa-wiki ingest via the Atlassian MCP"
 default_prompt:
   - "Use $lisa-wiki-connector-confluence: Produce sanitized Confluence source notes for lisa-wiki ingest via the Atlassian MCP."

package/plugins/lisa-wiki/skills/lisa-wiki-connector-docs/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Connector Docs"
+display_name: "Wiki Connector Docs"
 short_description: "Ingest a local document (PDF, DOCX, Markdown, text) into a sanitized source note for lisa-wiki ingest"
 default_prompt:
   - "Use $lisa-wiki-connector-docs: Ingest a local document (PDF, DOCX, Markdown, text) into a sanitized source note for lisa-wiki ingest."

package/plugins/lisa-wiki/skills/lisa-wiki-connector-git/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Connector Git"
+display_name: "Wiki Connector Git"
 short_description: "Produce sanitized git/PR-history source notes for lisa-wiki ingest"
 default_prompt:
   - "Use $lisa-wiki-connector-git: Produce sanitized git/PR-history source notes for lisa-wiki ingest."

package/plugins/lisa-wiki/skills/lisa-wiki-connector-jira/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Connector Jira"
+display_name: "Wiki Connector Jira"
 short_description: "Produce sanitized JIRA source notes for lisa-wiki ingest via the Atlassian MCP"
 default_prompt:
   - "Use $lisa-wiki-connector-jira: Produce sanitized JIRA source notes for lisa-wiki ingest via the Atlassian MCP."

package/plugins/lisa-wiki/skills/lisa-wiki-connector-memory/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Connector Memory"
+display_name: "Wiki Connector Memory"
 short_description: "Ingest the agent's PROJECT-SCOPED memory into a sanitized source note"
 default_prompt:
   - "Use $lisa-wiki-connector-memory: Ingest the agent's PROJECT-SCOPED memory into a sanitized source note."

package/plugins/lisa-wiki/skills/lisa-wiki-connector-notion/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Connector Notion"
+display_name: "Wiki Connector Notion"
 short_description: "Produce sanitized Notion source notes for lisa-wiki ingest via the Notion MCP"
 default_prompt:
   - "Use $lisa-wiki-connector-notion: Produce sanitized Notion source notes for lisa-wiki ingest via the Notion MCP."

package/plugins/lisa-wiki/skills/lisa-wiki-connector-roles/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Connector Roles"
+display_name: "Wiki Connector Roles"
 short_description: "Ingest the wiki's own digital-staff roster (config.staff[] + wiki/staff/*) into a sanitized source note"
 default_prompt:
   - "Use $lisa-wiki-connector-roles: Ingest the wiki's own digital-staff roster (config.staff[] + wiki/staff/*) into a sanitized source note."

package/plugins/lisa-wiki/skills/lisa-wiki-connector-slack/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Connector Slack"
+display_name: "Wiki Connector Slack"
 short_description: "Ingest a Slack channel into sanitized source notes via a user token"
 default_prompt:
   - "Use $lisa-wiki-connector-slack: Ingest a Slack channel into sanitized source notes via a user token."

package/plugins/lisa-wiki/skills/lisa-wiki-connector-web/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Connector Web"
+display_name: "Wiki Connector Web"
 short_description: "Ingest a public URL into a sanitized source note for lisa-wiki ingest (via WebFetch)"
 default_prompt:
   - "Use $lisa-wiki-connector-web: Ingest a public URL into a sanitized source note for lisa-wiki ingest (via WebFetch)."

package/plugins/lisa-wiki/skills/lisa-wiki-doctor/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Doctor"
+display_name: "Wiki Doctor"
 short_description: "Verify that a wiki is correctly set up and (after migration) fully functional"
 default_prompt:
   - "Use $lisa-wiki-doctor: Verify that a wiki is correctly set up and (after migration) fully functional."

package/plugins/lisa-wiki/skills/lisa-wiki-ingest/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Ingest"
+display_name: "Wiki Ingest"
 short_description: "Ingest source material into the LLM Wiki"
 default_prompt:
   - "Use $lisa-wiki-ingest: Ingest source material into the LLM Wiki."

package/plugins/lisa-wiki/skills/lisa-wiki-lint/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Lint"
+display_name: "Wiki Lint"
 short_description: "Health-check the LLM Wiki"
 default_prompt:
   - "Use $lisa-wiki-lint: Health-check the LLM Wiki."

package/plugins/lisa-wiki/skills/lisa-wiki-migrate/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Migrate"
+display_name: "Wiki Migrate"
 short_description: "Migrate an existing, hand-rolled wiki implementation onto the lisa-wiki kernel — phased and compatibility-first, with a strict no-loss…"
 default_prompt:
   - "Use $lisa-wiki-migrate: Migrate an existing, hand-rolled wiki implementation onto the lisa-wiki kernel — phased and compatibility-first, with a strict no-loss…."

package/plugins/lisa-wiki/skills/lisa-wiki-onboard-me/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Onboard Me"
+display_name: "Wiki Onboard Me"
 short_description: "Onboard a user to the project via its LLM Wiki"
 default_prompt:
   - "Use $lisa-wiki-onboard-me: Onboard a user to the project via its LLM Wiki."

package/plugins/lisa-wiki/skills/lisa-wiki-query/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Query"
+display_name: "Wiki Query"
 short_description: "Answer a question from the LLM Wiki with citations"
 default_prompt:
   - "Use $lisa-wiki-query: Answer a question from the LLM Wiki with citations."

package/plugins/lisa-wiki/skills/lisa-wiki-setup/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Setup"
+display_name: "Wiki Setup"
 short_description: "Scaffold, repair, verify, or upgrade a project's LLM Wiki from its config"
 default_prompt:
   - "Use $lisa-wiki-setup: Scaffold, repair, verify, or upgrade a project's LLM Wiki from its config."

package/plugins/lisa-wiki/skills/lisa-wiki-setup-automations/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Setup Automations"
+display_name: "Wiki Setup Automations"
 short_description: "Set up the recurring LLM Wiki ingest automation on the local workstation using the CURRENT runtime's native scheduler — Codex automations…"
 default_prompt:
   - "Use $lisa-wiki-setup-automations: Set up the recurring LLM Wiki ingest automation on the local workstation using the CURRENT runtime's native scheduler — Codex automations…."

package/plugins/lisa-wiki/skills/lisa-wiki-status/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Status"
+display_name: "Wiki Status"
 short_description: "Report Lisa wiki source freshness across enabled ingestion connectors"
 default_prompt:
   - "Use $lisa-wiki-status: Report Lisa wiki source freshness across enabled ingestion connectors."

package/plugins/lisa-wiki/skills/lisa-wiki-tear-down-automations/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Tear Down Automations"
+display_name: "Wiki Tear Down Automations"
 short_description: "Remove the recurring LLM Wiki ingest automation that /lisa-wiki:setup-automations created for this project (the lisa-wiki-auto-<project>-*…"
 default_prompt:
   - "Use $lisa-wiki-tear-down-automations: Remove the recurring LLM Wiki ingest automation that /lisa-wiki:setup-automations created for this project (the lisa-wiki-auto-<project>-*…."

package/plugins/lisa-wiki/skills/lisa-wiki-usage/agents/openai.yaml

@@ -1,4 +1,4 @@
-display_name: "Lisa Wiki Usage"
+display_name: "Wiki Usage"
 short_description: "Explain how to browse, query, and contribute to this project's LLM Wiki"
 default_prompt:
   - "Use $lisa-wiki-usage: Explain how to browse, query, and contribute to this project's LLM Wiki."

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

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

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

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

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

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

package/plugins/src/base/agents/learnings-synthesizer.md

@@ -15,7 +15,7 @@ You answer one question: **For every signal the miners surfaced, what category o
 What you do NOT decide:
 - Whether a signal is "worth keeping". That is the human's call. Surface it; let them mark Reject if they disagree.
 - Whether the spec was correct. That is `spec-conformance-specialist`.
-- What gets persisted where. That is `lisa:debrief-apply`, after the human triages.
+- What gets persisted where. That is `lisa-debrief-apply`, after the human triages.
 
 You **categorize** and **dedupe**. That is it.
 
@@ -36,7 +36,7 @@ Map every finding to exactly one category. When a finding could fit two, pick th
 | **Edge case** | A failure mode (input, state, environment, concurrency, etc.) that the original spec or Plan did not list. Should have been caught by Edge Case Brainstorm. | Append to Edge Case Brainstorm checklist in `intent-routing.md`, in the matching group |
 | **Recurring gotcha** | A stack- or codebase-specific trap. Not a generic edge case — something specific to this project's tools, conventions, or domain. ("This ORM silently truncates X." "Our auth header is renamed in lambda Y.") | Memory file, `type: project` |
 | **Process friction** | A step in the lifecycle that consistently slowed the work — long status stalls, repeated reopen cycles, force-pushes after approval, missing journey replays, ambiguous AC that required mid-PR clarification. | `PROJECT_RULES.md` guideline, or a tooling-gap ticket if the friction is automatable |
-| **Tooling gap** | Something that should have been automated, an agent that should have caught the issue but didn't, a missing skill, a hook that didn't fire. | A new ticket via `lisa:tracker-write` |
+| **Tooling gap** | Something that should have been automated, an agent that should have caught the issue but didn't, a missing skill, a hook that didn't fire. | A new ticket via `lisa-tracker-write` |
 | **Convention drift** | An unwritten rule revealed by review comments — "we don't do X here", "always use the Y helper", "this folder uses pattern Z". The convention is real but undocumented. | `CLAUDE.md` or `PROJECT_RULES.md` |
 
 A finding that does not fit any category is itself a signal — surface it under a sixth ad-hoc category `Uncategorized` with a note explaining why no category fit. Better to surface than to drop.

package/plugins/src/base/agents/linear-agent.md

@@ -51,9 +51,9 @@ Resolve build labels from `.lisa.config.json` `linear.labels.build.*` (defaults:
 
 If `linear-verify` returns `FAIL` on any of the above, do NOT continue to build. **Draft the missing spec content first, then block for confirmation** — never bounce a raw "go write all this" checklist back to the creator:
 1. **Best-effort autofill (before blocking).** Run the **draft-then-block procedure** in the `pre-flight-autofill` rule: draft every *authorable* missing section — Technical Approach, Out of Scope, Gherkin acceptance criteria, expected-vs-actual, Repository, Relationship Search (run the git + Linear search, don't fabricate it), a Validation Journey **draft** via `linear-add-journey`, and Target Backend Environment — from the item's own content (title, description, screenshots, design links, repro steps) plus the codebase. For bugs, parse the reported environment from bare env names and env-bearing URLs before recommending any default; the reported environment wins. Write it into the description via `linear-write-issue` as clearly-labeled assumptions/recommendations (never overwrite the creator's prose), then re-run `linear-verify`. Whatever the agent could author is now structured spec; only genuinely human-only inputs remain.
-2. Update labels via `lisa:linear-access operation: save-issue`: remove the current build label, add the configured `blocked` label **and** the configured `human_needed` marker label. (Create either label via `create_issue_label` if needed.) Even after the agent drafted what it could, a pre-flight gate failure bounces the item back to its creator because it still needs a human to **confirm the drafted assumptions** or supply something no agent can invent — real missing credentials, access, or an irreducible product/scoping decision — so the marker tells a human scanning the board which blocked items are waiting on them. The marker is additive to `blocked`, not a replacement. (See the `config-resolution` rule's "Build markers" for when the marker applies and when it must NOT.)
+2. Update labels via `lisa-linear-access operation: save-issue`: remove the current build label, add the configured `blocked` label **and** the configured `human_needed` marker label. (Create either label via `create_issue_label` if needed.) Even after the agent drafted what it could, a pre-flight gate failure bounces the item back to its creator because it still needs a human to **confirm the drafted assumptions** or supply something no agent can invent — real missing credentials, access, or an irreducible product/scoping decision — so the marker tells a human scanning the board which blocked items are waiting on them. The marker is additive to `blocked`, not a replacement. (See the `config-resolution` rule's "Build markers" for when the marker applies and when it must NOT.)
 3. Reassign the item to the **Issue creator** (the human who filed it — Linear's `creator` field).
-4. Post the **confirmation comment** from the `pre-flight-autofill` rule via `lisa:linear-access operation: save-comment`, **not** a bare remediation checklist: disclose it is a Claude draft, give one line per drafted section naming the key assumption made, list any remaining human-only item as a specific question with a recommended default, and close with *"review the drafted sections, correct anything wrong, then flip back to Ready and it builds — or reply with corrections."* Prefix with `[{repo}]`.
+4. Post the **confirmation comment** from the `pre-flight-autofill` rule via `lisa-linear-access operation: save-comment`, **not** a bare remediation checklist: disclose it is a Claude draft, give one line per drafted section naming the key assumption made, list any remaining human-only item as a specific question with a recommended default, and close with *"review the drafted sections, correct anything wrong, then flip back to Ready and it builds — or reply with corrections."* Prefix with `[{repo}]`.
 5. Stop. Do not run triage, do not delegate to a flow, do not start work.
 
 **Exception — single-repo scope is split, not blocked.** A single-repo-scope FAIL is the one gate failure the agent fixes rather than bounces to the creator: a cross-repo work unit is a decomposition error the agent owns (S10 is `product_relevant: false`), not a product question. Instead of blocking, run the **work-time split procedure** in the `repo-scope-split` rule — narrow this item to one repo, create a sibling Issue per additional repo cloning its metadata (same `projectId`), add the producer→consumer blocking relation, comment on the original, then re-run `linear-verify` on the original and every new sibling. Block (per the path above) only if the split is ambiguous (see "When to block instead of split"). If single-repo scope was the only FAIL and the split succeeded, proceed to Step 3 once every resulting item passes.
@@ -130,7 +130,7 @@ The label transitions ARE the canonical signal. The native `state` field stays a
 
 - Never auto-transition the native Linear `state`, with one explicit exception: when `linear-verify` returns `FAIL` for the pre-flight gate (Step 2), first run the `pre-flight-autofill` draft-then-block procedure (draft the authorable missing sections into the description as labeled assumptions), then update labels to the configured `blocked` label, add the configured `human_needed` marker label (`linear.labels.build.human_needed`, default `human-needed`), and reassign to the creator with a confirmation comment. Every other status change remains a label-driven suggestion.
 - Always read the full item graph via `linear-read-issue` before determining intent — don't rely on type labels alone.
-- Never create or materially edit an item by calling MCP write tools directly — always delegate to `linear-write-issue` so relationships, Gherkin criteria, and metadata gates are enforced. Two explicit exceptions are permitted: (1) the Step 2 pre-flight failure path (when `linear-verify` returns `FAIL`) may call `lisa:linear-access operation: save-issue` and `lisa:linear-access operation: save-comment` directly to set `status:blocked`, add the configured `human_needed` marker label, and reassign to the creator — this narrow exception is already granted by the rule above; (2) the Step 3 triage path may call `lisa:linear-access operation: save-comment` to post triage findings and `lisa:linear-access operation: save-issue` to add the `claude-triaged-{repo}` label — these are lightweight metadata updates that do not create or materially edit ticket content and therefore do not need to route through `linear-write-issue`.
+- Never create or materially edit an item by calling MCP write tools directly — always delegate to `linear-write-issue` so relationships, Gherkin criteria, and metadata gates are enforced. Two explicit exceptions are permitted: (1) the Step 2 pre-flight failure path (when `linear-verify` returns `FAIL`) may call `lisa-linear-access operation: save-issue` and `lisa-linear-access operation: save-comment` directly to set `status:blocked`, add the configured `human_needed` marker label, and reassign to the creator — this narrow exception is already granted by the rule above; (2) the Step 3 triage path may call `lisa-linear-access operation: save-comment` to post triage findings and `lisa-linear-access operation: save-issue` to add the `claude-triaged-{repo}` label — these are lightweight metadata updates that do not create or materially edit ticket content and therefore do not need to route through `linear-write-issue`.
 - If sign-in credentials are in the item, extract and pass them to the flow. If the item touches an authenticated surface and credentials are missing, that is a Step 2 failure — block and reassign rather than guessing.
 - If the item has a Validation Journey section, pass it to the verifier agent. The Validation Journey's local-verification step must point at the target backend environment named in the description.
 - For bug items, the reported environment named in the description or reproduction steps drives the implementation base branch via `deploy.branches`. If no environment can be found anywhere in the item, fall back to the configured default branch and record that assumption. If the reported environment is present but missing from `deploy.branches`, or its mapped branch is absent on the remote, stop and report the missing environment/branch mapping instead of defaulting. A non-integration environment fix must be merged and verified on that environment branch, then forward cherry-picked down to the integration branch through a linked follow-up.

package/plugins/src/base/commands/lisa/analyze-claude-remote.md

@@ -0,0 +1,6 @@
+---
+description: "Audit whether this repository can run as a Claude Code remote routine (cloud session) and inventory everything Lisa AND the host project must install or configure in the cloud environment — CLIs/binaries, environment variables/secrets, startup hooks, MCP scope/auth, and the user-scoped config and auto-memory gaps that don't replicate remotely. Read-only; emits grouped findings plus a machine-readable inventory."
+argument-hint: "[--section=<name>] [--json]"
+---
+
+Use the /lisa-analyze-claude-remote skill to audit this repository's readiness to run as a Claude Code remote routine and inventory what the cloud environment must install and configure. $ARGUMENTS

package/plugins/src/base/commands/lisa/automation-status.md

@@ -0,0 +1,12 @@
+---
+description: "Inspect the current project's Lisa automation fleet and report whether the expected recurring jobs exist, match Lisa's setup contract, and show healthy recent activity. Read-only by default."
+---
+
+Use the /lisa-automation-status skill to inspect the current project's expected Lisa automations, compare them with the runtime's scheduler metadata, and report fleet health, drift, staleness, unsupported jobs, and remediation hints. $ARGUMENTS
+
+Common operator usage:
+
+- `/lisa:automation-status`
+- `/lisa:automation-status --verbose`
+
+This surface is read-only in v1. Use it to understand whether Lisa's unattended jobs are healthy before deciding whether to rerun `/lisa:setup-automations`, inspect scheduler errors, or use `/lisa:intake` / `/lisa:repair-intake` to address queue fallout.

package/plugins/src/base/commands/lisa/codify-verification.md

@@ -0,0 +1,6 @@
+---
+description: "Convert empirical verification into a regression test (Playwright for UI, integration test for API/DB, benchmark for performance, etc.) so it doesn't regress. Mandatory step after verification passes — invoked from verification-lifecycle and from each Build/Fix/Improve flow."
+argument-hint: "<verification-type> <what-was-verified>"
+---
+
+Use the /lisa-codify-verification skill to encode the empirical verification that just passed as a regression test, in the appropriate framework for the verification type. $ARGUMENTS

package/plugins/src/base/commands/lisa/cross-pollinate.md

@@ -0,0 +1,15 @@
+---
+description: "Detect locally-authored agent definitions and regenerate them in the formats of the other coding agents this project supports (per .lisa.config.json)."
+allowed-tools: ["Skill"]
+argument-hint: "[path] [--dry-run] [--write]"
+---
+
+Use the /lisa-cross-pollinate skill to detect this project's locally-authored
+coding-agent definitions (skills, subagents, rules, commands, hooks, MCP) and
+make each available in the formats of the other agents the project's
+`.lisa.config.json` harness includes. $ARGUMENTS
+
+Provenance is tracked in `.lisa/cross-pollination.lock.json`: the run is
+idempotent, garbage-collects orphaned translations, never overwrites a
+hand-edited target, and reports any conflict or unsupported translation rather
+than guessing.

package/plugins/src/base/commands/lisa/debrief/apply.md

@@ -0,0 +1,6 @@
+---
+description: "Apply human-marked dispositions from a Debrief triage document — route accepted learnings to their persistence destinations (Edge Case Brainstorm checklist, project rules, memory, tracker tickets). Reads the triage doc produced by /lisa:debrief; deterministic and idempotent."
+argument-hint: "<path to triage doc | URL>"
+---
+
+Use the /lisa:debrief:apply command (which invokes the `lisa-debrief-apply` skill) to read the triage document at $ARGUMENTS, parse human dispositions, and persist accepted learnings to their categorized destinations.

package/plugins/src/base/commands/lisa/debrief.md

@@ -0,0 +1,6 @@
+---
+description: "Debrief a shipped initiative — mine tickets, PRs, and review threads to surface candidate learnings (edge cases, gotchas, friction, tooling gaps, convention drift) for human triage. Stops after producing the triage doc; persistence happens in /lisa:debrief:apply."
+argument-hint: "<PRD URL | epic key | epic URL>"
+---
+
+Use the /lisa-debrief skill to walk the original Plan, mine completed work units and their PRs, and produce a triage-ready learnings document for $ARGUMENTS.

package/plugins/src/base/commands/lisa/doctor.md

@@ -0,0 +1,6 @@
+---
+description: "Audit whether the current repository is ready to use Lisa. Runs grouped read-only readiness checks for config, runtime surfaces, tracker/source access, automation prerequisites, and optional GitHub Project/wiki coordination, then reports PASS/WARN/FAIL/SKIP results plus an overall verdict."
+argument-hint: "[--fix=false]"
+---
+
+Use the /lisa-doctor skill to audit whether the current repository is ready to use Lisa, report grouped PASS/WARN/FAIL/SKIP checks, and emit an overall readiness verdict. $ARGUMENTS

package/plugins/src/base/commands/lisa/exploratory-qa.md

@@ -0,0 +1,7 @@
+---
+description: "Run a first-time-user exploratory QA pass on any product type (DOM web app, HTTP/API backend, canvas game, CLI/library, IaC/CDK): experience the product the way a brand-new end user would by driving its real consumer-facing interface via the use-the-product core (which detects the product type, resolves the per-environment mutation policy from .lisa.config.json so production is never mutated by accident, and explores through the project's personas when defined), finding anything confusing, broken, or hard to use, and filing each finding (bug or usability issue) as a tracked work item via lisa-tracker-write. Static scans, HTTP fetches, screenshots alone, or console/network checks alone are not sufficient. 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 test suite, use the e2e-coverage-gaps skill if your stack provides one."
+allowed-tools: ["Skill"]
+argument-hint: "[target-url | env] [ready=true|false]"
+---
+
+Use the lisa-exploratory-qa skill to experience the product the way a brand-new first-time end user would — driving its real consumer-facing interface via the use-the-product core (product-type detection, per-environment mutation policy, and persona-lensed exploration), finding anything confusing, broken, or hard to use, and filing 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). Static scans, HTTP fetches, screenshots alone, or console/network checks alone are not enough. For automated test-coverage gaps, use the e2e-coverage-gaps skill if your stack provides one. $ARGUMENTS

package/plugins/src/base/commands/lisa/fix/linter-error.md

@@ -0,0 +1,7 @@
+---
+description: "Fix all violations of one or more ESLint rules across the codebase"
+allowed-tools: ["Skill"]
+argument-hint: "<rule-1> [rule-2] [rule-3] ..."
+---
+
+Use the /lisa-fix-linter-error skill to fix linter errors. $ARGUMENTS

package/plugins/src/base/commands/lisa/generate-claude-remote-build-script.md

@@ -0,0 +1,6 @@
+---
+description: "Generate the setup/build script and environment-variable template to paste into a Claude Code remote routine environment so this repo runs in the cloud. Runs /lisa:analyze-claude-remote, then writes an idempotent, detect-before-install bash script that installs the required package manager and CLIs for Lisa and the host project, plus a commented env-var template (names only) and a domain allowlist. Cloud-proxy aware and fits the environment-cache time budget."
+argument-hint: "[--out=<path>] [--include-optional] [--print]"
+---
+
+Use the /lisa-generate-claude-remote-build-script skill to generate the cloud-environment setup script and env-var template for running this repo as a Claude Code remote routine. $ARGUMENTS

package/plugins/src/base/commands/lisa/git/commit.md

@@ -0,0 +1,7 @@
+---
+description: "Create conventional commits for current changes"
+allowed-tools: ["Skill"]
+argument-hint: "[commit-message-hint]"
+---
+
+Use the /lisa-git-commit skill to create conventional commits for current changes. $ARGUMENTS

package/plugins/src/base/commands/lisa/git/prune.md

@@ -0,0 +1,6 @@
+---
+description: "Prune local branches that have been deleted on remote"
+allowed-tools: ["Skill"]
+---
+
+Use the /lisa-git-prune skill to prune local branches that have been deleted on remote.

package/plugins/src/base/commands/lisa/git/submit-pr.md

@@ -0,0 +1,7 @@
+---
+description: "Push changes and create or update a pull request"
+allowed-tools: ["Skill"]
+argument-hint: "[pr-title-or-description-hint]"
+---
+
+Use the /lisa-git-submit-pr skill to push changes and create or update a pull request. $ARGUMENTS

package/plugins/src/base/commands/lisa/implement.md

@@ -0,0 +1,6 @@
+---
+description: "Implement a single work item end-to-end. Vendor-agnostic: given a work-item URL/key (JIRA, Linear, GitHub Issues) or description, reads it, determines work type (Build/Fix/Improve/Investigate), assembles an agent team, runs the full lifecycle through PR + evidence. For batch processing of all Status=Ready tickets in a queue, use /lisa:intake instead."
+argument-hint: "<single-work-item-url | key | description>"
+---
+
+Use the /lisa-implement skill to take the work item from spec to shipped: read the source, determine work type, assemble an agent team, and run the full lifecycle through PR creation, code review, deploy, and empirical verification. $ARGUMENTS

package/plugins/src/base/commands/lisa/improve/code-complexity.md

@@ -0,0 +1,6 @@
+---
+description: "Reduce the cognitive complexity threshold by 2 and fix all violations"
+allowed-tools: ["Skill"]
+---
+
+Use the /lisa-improve-code-complexity skill to lower code complexity.

package/plugins/src/base/commands/lisa/improve/max-lines-per-function.md

@@ -0,0 +1,7 @@
+---
+description: "Reduce max lines per function threshold and fix violations"
+allowed-tools: ["Skill"]
+argument-hint: "<max-lines-per-function-value>"
+---
+
+Use the /lisa-improve-max-lines-per-function skill to reduce max function lines. $ARGUMENTS

package/plugins/src/base/commands/lisa/improve/max-lines.md

@@ -0,0 +1,7 @@
+---
+description: "Reduce max file lines threshold and fix violations"
+allowed-tools: ["Skill"]
+argument-hint: "<max-lines-value>"
+---
+
+Use the /lisa-improve-max-lines skill to reduce max lines. $ARGUMENTS

package/plugins/src/base/commands/lisa/improve/test-coverage.md

@@ -0,0 +1,7 @@
+---
+description: "Increase test coverage to a specified threshold percentage"
+allowed-tools: ["Skill"]
+argument-hint: "<threshold-percentage>"
+---
+
+Use the /lisa-improve-test-coverage skill to increase test coverage. $ARGUMENTS

package/plugins/src/base/commands/lisa/improve/tests.md

@@ -0,0 +1,7 @@
+---
+description: "Improve test quality by analyzing and strengthening weak, brittle, or poorly-written tests"
+allowed-tools: ["Skill"]
+argument-hint: "<target-description>"
+---
+
+Use the /lisa-improve-tests skill to improve test quality. $ARGUMENTS

package/plugins/src/base/commands/lisa/intake-explain.md

@@ -0,0 +1,31 @@
+---
+description: "Inspect one PRD or build item, explain how Lisa classifies it right now, and report the exact intake or repair gate affecting it. Read-only by default."
+argument-hint: "<item-ref>"
+---
+
+Use the /lisa-intake-explain skill to inspect a single repo-scoped PRD or build item, explain its current lifecycle role, and report whether Lisa would intake it, repair it, hold it, skip it, or leave it product-owned. $ARGUMENTS
+
+Common operator usage:
+
+- `/lisa:intake-explain https://github.com/acme/repo/issues/123`
+- `/lisa:intake-explain PRD-456`
+- `/lisa:intake-explain https://linear.app/acme/issue/ENG-123/example`
+
+The diagnosis uses stable verdicts:
+
+- `ELIGIBLE_FOR_INTAKE`: run `/lisa:intake <queue>` when normal pickup is the next move.
+- `ELIGIBLE_FOR_REPAIR`: run `/lisa:repair-intake <queue>` when Lisa-owned stuck work is actionable.
+- `WAITING_ON_STALENESS`: wait and re-check after the configured freshness window.
+- `HELD_BY_BLOCKERS`: clear the listed dependency or blocker before rerunning intake.
+- `NON_LEAF_CONTAINER`: decompose the item or move build-ready status to leaf work.
+- `PRODUCT_OWNED_STATE`: finish product clarification, promotion, or verification first.
+- `MISCONFIGURED`: fix lifecycle labels, repo scope, or queue configuration before relying on automation.
+
+Use it for these operator workflows:
+
+- Intake triage: confirm whether one item would be picked up by `/lisa:intake` right now.
+- Repair triage: decide whether a blocked or in-progress item is stale enough for `/lisa:repair-intake`.
+- Product follow-up: distinguish product-owned draft/shipped/verified states from Lisa-owned work.
+- Queue cleanup: identify leaf-only, repo-scope, dependency, or lifecycle-adoption fixes without mutating the item.
+
+This surface is read-only in v1. It never claims, relabels, comments on, repairs, or decomposes the item; it only reports the item facts, verdict, decisive gate, and smallest useful next action before an operator chooses `/lisa:intake`, `/lisa:repair-intake`, `/lisa:queue-status`, or a tracker-native fix.

package/plugins/src/base/commands/lisa/intake.md

@@ -0,0 +1,6 @@
+---
+description: "Vendor-agnostic batch scanner for Ready queues. Notion PRD database URL → finds Status=Ready PRDs and runs lisa-plan per item. Confluence space or parent-page URL → finds prd-ready PRDs and runs lisa-plan per item. Linear workspace or team URL → finds prd-ready Linear projects and runs lisa-plan per item. GitHub repo URL or org/repo token → finds prd-ready GitHub issues and runs lisa-plan per item (PRD-source mode), or finds status:ready issues and runs lisa-implement per item when tracker=github (build-queue mode). JIRA project key or JQL → finds Ready tickets and runs lisa-implement per item. Designed as the cron target for /schedule."
+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>"
+---
+
+Use the /lisa-intake skill to scan the queue for Ready items and dispatch one eligible Ready item per invocation through the appropriate single-item lifecycle skill — and, on the PRD side, close the loop by dispatching /lisa:verify-prd for one shipped PRD per cycle (shipped → verified on pass, or re-opened to ticketed with build-ready fix tickets that auto-build and re-verify on fail — never blocked). $ARGUMENTS

package/plugins/src/base/commands/lisa/monitor.md

@@ -0,0 +1,6 @@
+---
+description: "Monitor application health AND audit observability completeness for the current repo, then file build-ready tickets for anomalies and instrumentation gaps. Health/logs/errors/performance via the stack ops-specialist or stack-agnostic base probing; repo-scoped, idempotent, capped; files by default, --dry-run previews."
+argument-hint: "[environment] [--dry-run] [--report-only] [--all-gaps] [max_candidates=<n>]"
+---
+
+Use the /lisa-monitor skill to check application health, logs, errors, and performance for the named environment, audit observability completeness, and file build-ready tickets for the anomalies and gaps it finds. Use `--dry-run` to preview without filing, `--report-only` for a health/audit summary with no filing, or `--all-gaps` to also file recommended-tier gaps (session replay, product analytics). $ARGUMENTS

package/plugins/src/base/commands/lisa/parity-code-review.md

@@ -0,0 +1,6 @@
+---
+description: "Lisa-native code review of the current git diff — correctness bugs, security issues, and obvious defects, reported as severity-ranked findings with file:line references. Vendor-neutral cross-agent equivalent of the upstream code-review command."
+argument-hint: "[optional: path or scope hint]"
+---
+
+Use the /lisa-parity-code-review skill to review the current branch and working-tree diff for correctness bugs, security issues, and obvious defects, and report findings ranked by severity with file:line references. $ARGUMENTS

package/plugins/src/base/commands/lisa/parity-code-simplifier.md

@@ -0,0 +1,6 @@
+---
+description: "Behavior-preserving simplification of recently-changed code — dedup, reuse, readability, and dead-code removal, quality only (never a bug hunt). Vendor-neutral cross-agent equivalent of the upstream code-simplifier agent."
+argument-hint: "[optional: path or scope hint]"
+---
+
+Use the /lisa-parity-code-simplifier skill to simplify the recently-changed code — removing duplication and dead code, reusing existing utilities, and improving readability — without altering behavior, then verify tests still pass. $ARGUMENTS

package/plugins/src/base/commands/lisa/parity-coderabbit.md

@@ -0,0 +1,6 @@
+---
+description: "Thorough PR-style review of the full diff — bugs, security, performance, and maintainability — with concrete fixes and a structured summary. An independent Lisa-native review (does NOT call CodeRabbit's service); vendor-neutral cross-agent equivalent of the upstream coderabbit plugin."
+argument-hint: "[optional: PR number, path, or scope hint]"
+---
+
+Use the /lisa-parity-coderabbit skill to run a thorough PR-style review of the full diff — flagging bugs, security, performance, and maintainability issues with concrete suggested fixes — and produce a structured summary with a verdict. $ARGUMENTS