@codyswann/lisa 2.189.10 → 2.189.12

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

@@ -1,5 +1,5 @@
 ---
-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, rollups whose children are all terminal, GitHub PRDs missing native child links, and GitHub issues missing official Lisa lifecycle labels — 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, repairs missing native GitHub PRD child links from generated-work fallback, reconciles parent rollups to their derived state (including the intermediate-env case — e.g. all children at `On Stg` → parent `On Stg` — and a container wrongly stuck in `ready`), normalizes missing GitHub lifecycle labels to the configured PRD/build `ready` label, and closes out completed rollups. Cron-safe and bounded; default GitHub intake_mode is both and default max_candidates is 100."
+description: "Repair counterpart to /lisa:intake. Vendor-agnostic batch scanner that finds stuck or half-closed work — items in `blocked`, stalled in an in-progress role (build `claimed`, PRD `in_review`), terminal-labeled items still natively open, rollups whose children are all terminal, GitHub PRDs missing native child links, and GitHub issues missing Lisa lifecycle labels — across the same queues /lisa:intake serves. Repairs every actionable candidate inside the `max_candidates` cap: resumes stalled work in place (diagnosing PR/deploy state first; unmergeable PRs or failed deploys get a build-ready fix ticket + `blocked` instead of re-dispatch), re-validates blocked PRDs, re-dispatches blocked builds whose blockers cleared, performs terminal native closure, repairs missing GitHub child links, reconciles parent rollups, normalizes missing GitHub lifecycle labels to the configured `ready` lane, 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]"
 ---
 

package/plugins/src/base/skills/lisa-exploratory-qa/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lisa-exploratory-qa
-description: First-time-user exploratory QA pass for ANY product type (DOM web app, HTTP/API backend, canvas game, CLI/library, IaC/CDK) that FEEDS THE LIFECYCLE. Use when asked to experience a product the way a brand-new end user would — driving its real consumer-facing interface via the `use-the-product` core (which detects the product type, resolves the per-environment mutation policy from .lisa.config.json so production data is never mutated by accident, and explores through the project's personas when it defines them) to find anything confusing, broken, or hard to use (unclear purpose, human-facing jargon, machine-style labels, contextless data, wrong control semantics, dead-end flows, incomplete end-states, clipped/unreachable controls, slow loads). Static route scans, HTTP fetches, screenshots alone, or console/network checks alone are not sufficient evidence. Instead of writing a report file, it files every finding as a tracked work item via lisa-tracker-write. A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa-intake) or left in the backlog for human triage (default). For gaps in the automated test suite, use e2e-coverage-gaps instead.
+description: First-time-user exploratory QA pass for ANY product type (DOM web app, HTTP/API backend, canvas game, CLI/library, IaC/CDK) that FEEDS THE LIFECYCLE. Use when asked to experience a product the way a brand-new end user would — driving its real consumer-facing interface via the `use-the-product` core (which detects the product type, resolves the per-environment mutation policy from .lisa.config.json so production data is never mutated by accident, and explores through the project's personas when it defines them) to find anything confusing, broken, or hard to use. Static route scans, HTTP fetches, screenshots alone, or console/network checks alone are not sufficient evidence. Instead of writing a report file, it files every finding as a tracked work item via lisa-tracker-write. A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa-intake) or left in the backlog for human triage (default). For gaps in the automated test suite, use e2e-coverage-gaps instead.
 ---
 
 # Exploratory QA

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

@@ -1,6 +1,6 @@
 ---
 name: lisa-intake
-description: "Vendor-agnostic scanner for Ready queues. Given a Notion PRD database URL → finds the first Ready PRD and runs lisa-plan. Given a Confluence space or parent page URL → finds the first prd-ready PRD and runs lisa-plan. Given a Linear workspace URL or team key → finds the first prd-ready Linear project and runs lisa-plan. Given a GitHub repo URL or `org/repo` token → finds the first prd-ready GitHub issue and runs lisa-plan. Given a JIRA project key or JQL filter → finds the first Ready ticket and runs lisa-implement. Given a GitHub repo URL or `org/repo` token when `tracker = github` → finds the first `status:ready` issue and runs lisa-implement. On the PRD side it also closes the loop: each cycle rolls a ticketed PRD up to shipped and dispatches lisa-verify-prd for one shipped PRD (shipped → verified on pass; on fail, re-opened shipped → ticketed with build-ready fix tickets that auto-build and re-verify — never blocked). Designed as the cron target for /schedule — one eligible item per invocation, exits cleanly on empty. Symmetric counterpart to the single-item lisa-plan and lisa-implement skills."
+description: "Vendor-agnostic scanner for Ready queues. Notion PRD database URL → first Ready PRD → lisa-plan. Confluence space or parent page URL → first prd-ready PRD → lisa-plan. Linear workspace URL or team key → first prd-ready project → lisa-plan. GitHub repo URL or `org/repo` token → first prd-ready issue → lisa-plan, or first `status:ready` issue → lisa-implement when `tracker = github`. JIRA project key or JQL filter → first Ready ticket → lisa-implement. On the PRD side it also closes the loop: each cycle rolls a ticketed PRD up to shipped and dispatches lisa-verify-prd for one shipped PRD (shipped → verified on pass; on fail, re-opened shipped → ticketed with build-ready fix tickets that auto-build and re-verify — never blocked). Designed as the cron target for /schedule — one eligible item per invocation, exits cleanly on empty. Symmetric counterpart to the single-item lisa-plan and lisa-implement skills."
 allowed-tools: ["Skill", "Bash", "mcp__claude_ai_Notion__notion-fetch", "mcp__claude_ai_Notion__notion-search", "mcp__atlassian__getConfluencePage", "mcp__atlassian__getConfluenceSpaces", "mcp__atlassian__searchConfluenceUsingCql", "mcp__atlassian__getAccessibleAtlassianResources", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getJiraIssue"]
 ---
 

package/plugins/src/base/skills/lisa-project-ideation/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lisa-project-ideation
-description: "Generate practical, verifiable product ideas for the current host project FROM EVIDENCE-DERIVED PERSONAS, then turn the selected build-ready ideas into real PRDs via lisa-research. First derives the personas the project actually serves by mining its docs, code, data model, and releases (never invented — each persona cites its evidence), then ideates per persona. Every build-ready idea must pass a practicality gate (an obtainable data/source path) and an empirical verification gate (a user-observable outcome the agent can verify). Selected ideas are handed to lisa-research, which creates each PRD in the configured source (Notion / Confluence / GitHub / Linear) — in the draft state by default, or prd-ready (auto-picked-up by lisa-intake) when prd_ready=true. Defaults to creating one PRD (the top-ranked idea); max_prds widens the batch. Invoke for 'generate feature ideas for this project', 'what should we build next for <persona>?', 'looking at <external product>, what should we add here?'. Vendor- and stack-agnostic."
+description: "Generate practical, verifiable product ideas for the current host project FROM EVIDENCE-DERIVED PERSONAS, then turn the selected build-ready ideas into real PRDs via lisa-research. First derives the personas the project actually serves by mining its docs, code, data model, and releases (never invented — each persona cites its evidence), then ideates per persona. Every build-ready idea must pass a practicality gate (an obtainable data/source path) and an empirical verification gate (a user-observable outcome the agent can verify). Selected ideas are handed to lisa-research, which creates each PRD in the configured source (Notion / Confluence / GitHub / Linear) — in the draft state by default, or prd-ready (auto-picked-up by lisa-intake) when prd_ready=true. Defaults to creating one PRD (the top-ranked idea); max_prds widens the batch. Invoke for 'generate feature ideas for this project', 'what should we build next for <persona>?', 'looking at <external product>, what should we add here?'."
 allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep", "WebFetch", "WebSearch"]
 ---
 

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

@@ -1,6 +1,6 @@
 ---
 name: lisa-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) — but for a stalled build it first diagnoses the PR/deploy state: a PR that already merged is recovered by applying the env transition build-intake never got to (no re-dispatch); a PR that is merely behind its base is re-synced in place via `gh pr update-branch` so the already-enabled auto-merge can land (a clean rebase needs no human); and only a PR that cannot merge for a non-mechanical reason (true conflict, failing checks, unaddressed CodeRabbit/changes-requested) or a failed deploy gets a build-ready leaf fix ticket with the item moved 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 OR whose validation/quality-gate self-block now re-validates PASS (re-running `lisa-tracker-validate` against current content — the build mirror of PRD re-validation), performs terminal native closure for terminal-labeled items, reconciles parent rollups to their derived state per leaf-only-lifecycle — including the intermediate-env case (e.g. all children at `On Stg` → parent `On Stg`) and a container wrongly stuck in `ready` — and closes out 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` leaves (a container wrongly carrying `ready` is the one exception — it is rolled up from its children, since `ready` on a parent is an invariant violation, not intake's claim signal). Designed as a /schedule cron target running alongside lisa-intake."
+description: "Vendor-agnostic repair scanner — the recovery counterpart to lisa-intake. Finds work that got stuck or was left half-closed across the same queues lisa-intake serves (Notion / Confluence / Linear / GitHub PRDs; JIRA / GitHub / Linear build queues): items left in `blocked`, work stalled in an in-progress role (build `claimed`, PRD `in_review`), terminal-labeled items still natively open, and rollups whose children are all terminal. Repairs every actionable candidate up to `max_candidates`: resumes stalled work in place (diagnosing a stalled build's PR/deploy state first — merged PRs get the missed env transition, behind-base PRs are re-synced, unmergeable PRs or failed deploys get a build-ready fix ticket + `blocked`), re-validates blocked PRDs and build items whose blockers cleared, performs terminal native closure, and reconciles parent rollups to their derived state. Idempotent and loop-protected; never mutates `draft`/`verified` or `ready` leaves. A /schedule cron target alongside lisa-intake."
 allowed-tools: ["Skill", "Bash", "Read", "Write", "Edit"]
 ---
 

package/plugins/src/base/skills/lisa-verify-prd/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lisa-verify-prd
-description: "Initiative-level PRD acceptance gate. Given a PRD ref/URL (GitHub Issue, Linear project/issue, Notion page, Confluence page, or JIRA issue), resolves the source vendor, reads the PRD body and its generated top-level child work set via the prd-lifecycle-rollup contract (native hierarchy first, machine-readable generated-work section fallback — never reimplementing child enumeration), and confirms every required generated top-level work item is terminal before any verification runs. If any required top-level child is non-terminal, it reports the incomplete child set and STOPS without verifying or transitioning the PRD. When the guard passes, it runs spec-conformance against the original PRD requirements (via the spec-conformance skill) plus empirical verification appropriate to the shipped surface (via verification-lifecycle). On a CONFORMS verdict with all empirical checks passing it runs the PASS path: transitions the PRD shipped → verified and posts verification evidence. On a PARTIAL/DIVERGES conformance verdict or any failing empirical check it runs the self-healing FAIL path: it re-opens the PRD shipped → ticketed (NEVER blocked), creates build-ready fix tickets (via tracker-write with build_ready: true) for each missing/incorrect/divergent behavior — registered as the PRD's generated work — and posts a product-readable failure report (with a verification-round count) naming which requirements/ACs failed with observed-vs-expected evidence. The fix tickets auto-build, rollup re-ships the PRD once they are terminal, and a later intake cycle re-verifies — the loop closes itself and never auto-halts. Re-runs are idempotent: evidence/failure-report comments are regenerated in place via a stable sentinel marker (never appended, round incremented), fix tickets are deduped by a stable PRD-ref + requirement marker (referenced/updated, never duplicated), and the lifecycle transition is a no-op when the PRD already carries the target role (exactly one lifecycle label/status remains) — per the prd-lifecycle-rollup idempotency dedupe key (match by stable ref, never by title)."
+description: "Initiative-level PRD acceptance gate. Given a PRD ref/URL (GitHub, Linear, Notion, Confluence, or JIRA), resolves the source vendor, reads the PRD and its generated top-level child work via the prd-lifecycle-rollup contract, and confirms every required child is terminal before any verification runs — if any is non-terminal it reports the incomplete set and STOPS. When the guard passes it runs spec-conformance against the original PRD requirements plus empirical verification via verification-lifecycle. On CONFORMS with all checks passing: transitions the PRD shipped → verified and posts evidence. On PARTIAL/DIVERGES or any failing check: re-opens the PRD shipped → ticketed (NEVER blocked), creates build-ready fix tickets for each divergence, and posts a product-readable failure report — the fix tickets auto-build, rollup re-ships the PRD, and a later intake cycle re-verifies, so the loop closes itself. Idempotent re-runs: comments regenerate in place via sentinel markers; fix tickets dedupe by stable ref."
 allowed-tools: ["Skill", "Bash", "Read", "mcp__claude_ai_Notion__notion-fetch", "mcp__claude_ai_Notion__notion-get-comments", "mcp__atlassian__getConfluencePage", "mcp__atlassian__getConfluencePageDescendants", "mcp__atlassian__getJiraIssue", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getAccessibleAtlassianResources"]
 ---
 

package/plugins/src/expo/skills/owasp-zap/SKILL.md

@@ -1,3 +1,8 @@
+---
+name: owasp-zap
+description: This skill should be used when running or interpreting an OWASP ZAP baseline DAST scan of the Expo web export — after changes to HTTP headers, authentication, or security middleware, before deploying to staging or production, or when triaging ZAP findings from CI or pull request checks. Covers running scripts/zap-baseline.sh locally, risk-level triage, common findings and fixes, and .zap/baseline.conf rule configuration.
+---
+
 # OWASP ZAP Baseline Scanning
 
 OWASP ZAP (Zed Attack Proxy) performs DAST (Dynamic Application Security Testing) by scanning a running application for common security vulnerabilities from the OWASP Top 10.

package/plugins/src/harper-fabric/skills/harper-config-yaml/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: harper-config-yaml
-description: This skill should be used when creating or editing a Harper (HarperDB/Fabric) component's config.yaml — enabling a built-in extension (graphqlSchema, jsResource, rest, static, roles, loadEnv, dataLoader, fastifyRoutes), wiring an external component, or troubleshooting why an extension is not loading. Critical: it documents the no-merge footgun where a custom config.yaml replaces Harper's default config entirely. Pairs with harper-component-model, harper-resources, and harper-schema-graphql.
+description: "This skill should be used when creating or editing a Harper (HarperDB/Fabric) component's config.yaml — enabling a built-in extension (graphqlSchema, jsResource, rest, static, roles, loadEnv, dataLoader, fastifyRoutes), wiring an external component, or troubleshooting why an extension is not loading. Critical: it documents the no-merge footgun where a custom config.yaml replaces Harper's default config entirely. Pairs with harper-component-model, harper-resources, and harper-schema-graphql."
 ---
 
 # Harper config.yaml

package/plugins/src/harper-fabric/skills/harper-realtime/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: harper-realtime
-description: This skill should be used when adding or troubleshooting Harper (HarperDB/Fabric) real-time behavior: MQTT topics, WebSocket resource subscriptions, resource publish/subscribe handlers, SSE-style streaming routes, and local subscriber verification. Pairs with harper-resources, harper-config-yaml, harper-schema-graphql, and harper-build-and-deploy.
+description: "This skill should be used when adding or troubleshooting Harper (HarperDB/Fabric) real-time behavior: MQTT topics, WebSocket resource subscriptions, resource publish/subscribe handlers, SSE-style streaming routes, and local subscriber verification. Pairs with harper-resources, harper-config-yaml, harper-schema-graphql, and harper-build-and-deploy."
 ---
 
 # Harper Realtime

package/plugins/src/rails/skills/action-controller-best-practices/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: action-controller-best-practices
-description: Build or Refactor large Rails controller files into clean, maintainable code. Use when a controller action exceeds ~10 lines, a controller has custom non-RESTful actions, or when the user asks to refactor, slim down, clean up, or organize a Rails controller. Applies patterns: service objects, query objects, form objects, controller concerns, presenters/decorators, and RESTful resource extraction.
+description: "Build or Refactor large Rails controller files into clean, maintainable code. Use when a controller action exceeds ~10 lines, a controller has custom non-RESTful actions, or when the user asks to refactor, slim down, clean up, or organize a Rails controller. Applies patterns: service objects, query objects, form objects, controller concerns, presenters/decorators, and RESTful resource extraction."
 ---
 
 # Rails Controller Refactoring

package/plugins/src/rails/skills/active-record-model-best-practices/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: active-record-model-best-practices
-description: Best practices for Ruby on Rails models, splitting code into well-organized, maintainable code. Use when a model exceeds ~100 lines, has mixed responsibilities, or when the user asks to refactor, extract, clean up, or organize a Rails model. Applies patterns: concerns, service objects, query objects, form objects, and value objects.
+description: "Best practices for Ruby on Rails models, splitting code into well-organized, maintainable code. Use when a model exceeds ~100 lines, has mixed responsibilities, or when the user asks to refactor, extract, clean up, or organize a Rails model. Applies patterns: concerns, service objects, query objects, form objects, and value objects."
 ---
 
 # Rails Model Refactoring

package/scripts/lib/per-agent-hook-filter.mjs

@@ -105,7 +105,9 @@ const SCRIPT_EXCLUDE_PATTERNS = [/debug/i, /\.agy\.sh$/];
 /** Hook command shape: { type: "command", command: "..." } */
 const isEntireClaudeCodeCommand = cmd =>
   typeof cmd === "string" &&
-  /^command -v entire >\/dev\/null 2>&1 && entire hooks claude-code /.test(cmd);
+  cmd.startsWith(
+    "command -v entire >/dev/null 2>&1 && entire hooks claude-code "
+  );
 
 const scriptNameFromCommand = cmd => {
   if (typeof cmd !== "string") return null;

package/typescript/copy-contents/.husky/pre-commit

@@ -46,9 +46,26 @@ fi
 # Check for Gitleaks and run secret detection
 echo "🔐 Checking for secrets with Gitleaks..."
 if command -v gitleaks >/dev/null 2>&1; then
-  # Run gitleaks on staged files
-  gitleaks protect --staged --redact -v
-  if [ $? -ne 0 ]; then
+  # Run gitleaks on staged files. Lisa keeps the host-owned allowlist in
+  # .gitleaksignore and shared managed entries in .gitleaksignore.local.
+  GITLEAKS_IGNORE_ARGS=""
+  GITLEAKS_COMBINED_IGNORE=""
+  if [ -f ".gitleaksignore.local" ]; then
+    GITLEAKS_COMBINED_IGNORE="$(mktemp)"
+    if [ -f ".gitleaksignore" ]; then
+      cat .gitleaksignore > "$GITLEAKS_COMBINED_IGNORE"
+      printf '\n' >> "$GITLEAKS_COMBINED_IGNORE"
+    fi
+    cat .gitleaksignore.local >> "$GITLEAKS_COMBINED_IGNORE"
+    GITLEAKS_IGNORE_ARGS="--gitleaks-ignore-path=$GITLEAKS_COMBINED_IGNORE"
+  fi
+
+  gitleaks protect --staged --redact -v $GITLEAKS_IGNORE_ARGS
+  GITLEAKS_STATUS=$?
+  if [ -n "$GITLEAKS_COMBINED_IGNORE" ]; then
+    rm -f "$GITLEAKS_COMBINED_IGNORE"
+  fi
+  if [ $GITLEAKS_STATUS -ne 0 ]; then
     echo ""
     echo "❌ Secrets detected in staged files!"
     echo ""
@@ -93,4 +110,4 @@ fi
 # Run lint-staged for incremental lint and format checks
 echo "🚀 Running lint-staged..."
 $EXECUTOR lint-staged --config .lintstagedrc.json
-# END: AI GUARDRAILS
+# END: AI GUARDRAILS

package/typescript/copy-overwrite/{.gitleaksignore → .gitleaksignore.local}

@@ -1,5 +1,5 @@
 # This file is managed by Lisa.
-# Do not edit directly — changes will be overwritten on the next `lisa` run.
+# Do not edit directly - changes will be overwritten on the next `lisa` run.
 
 # CDK snapshot files contain asset hashes that can trigger false positives
 __tests__/infra/__snapshots__/sse-stream-stack.test.ts.snap:generic-api-key:380

package/typescript/create-only/.gitleaksignore

@@ -0,0 +1,5 @@
+# This file is host-owned after Lisa creates it.
+# Add project-specific false positives here; Lisa will not overwrite them.
+#
+# Lisa-managed shared entries live in .gitleaksignore.local and are loaded by
+# the Lisa pre-commit hook when present.