@codyswann/lisa 2.124.4 → 2.124.6

package/package.json

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

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

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

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

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

package/plugins/lisa-agy/plugin.json

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@@ -1,41 +1,8 @@
 {
   "name": "lisa",
-  "version": "2.124.4",
+  "version": "2.124.6",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"
-  },
-  "hooks": {
-    "PreToolUse": [
-      {
-        "matcher": "Bash",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/block-no-verify.sh"
-          }
-        ]
-      }
-    ],
-    "SessionStart": [
-      {
-        "matcher": "startup",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/install-pkgs.sh"
-          }
-        ]
-      },
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/setup-jira-cli.sh"
-          }
-        ]
-      }
-    ]
   }
 }

package/plugins/lisa-cursor/hooks/hooks.json

@@ -0,0 +1,20 @@
+{
+  "version": 1,
+  "hooks": {
+    "preToolUse": [
+      {
+        "command": "${CURSOR_PLUGIN_ROOT}/hooks/block-no-verify.sh",
+        "matcher": "Bash"
+      }
+    ],
+    "sessionStart": [
+      {
+        "command": "${CURSOR_PLUGIN_ROOT}/hooks/install-pkgs.sh",
+        "matcher": "startup"
+      },
+      {
+        "command": "${CURSOR_PLUGIN_ROOT}/hooks/setup-jira-cli.sh"
+      }
+    ]
+  }
+}

package/plugins/lisa-cursor/rules/{reference/base-rules.md → base-rules-reference.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Base Rules Reference"
+alwaysApply: false
+---
+
 Intent Routing (FIRST — before anything else):
 
 Before starting any work in a session, classify the user's initial request using the Intent Routing rule. Determine which flow applies (Research, Plan, Implement, Verify, or None) and check its readiness gate. Once a flow is established, all subsequent messages operate within it. Do not skip this step — even if the request seems simple. See the `intent-routing` rule for the full protocol.

package/plugins/lisa-cursor/rules/{eager/base-rules.md → base-rules.mdc}

@@ -1,6 +1,11 @@
+---
+description: "Base Rules (load-bearing)"
+alwaysApply: true
+---
+
 # Base Rules (load-bearing)
 
-These are mandatory disciplines that apply to every session. Full prose, JIRA dev-status query, ADF templates, etc. live in [reference/base-rules.md](../reference/base-rules.md).
+These are mandatory disciplines that apply to every session. Full prose, JIRA dev-status query, ADF templates, etc. live in [reference/base-rules.md](base-rules-reference.mdc).
 
 ## Requirement Verification
 

package/plugins/lisa-cursor/rules/{reference/coding-philosophy.md → coding-philosophy-reference.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Coding Philosophy"
+alwaysApply: false
+---
+
 # Coding Philosophy
 
 This rule enforces the core coding philosophy: **immutability**, **predictable structure**, **functional transformations**, **test-driven development**, **clean deletion**, and **simplicity**.

package/plugins/lisa-cursor/rules/{eager/coding-philosophy.md → coding-philosophy.mdc}

@@ -1,6 +1,11 @@
+---
+description: "Coding Philosophy (load-bearing)"
+alwaysApply: true
+---
+
 # Coding Philosophy (load-bearing)
 
-When writing or modifying code, follow these principles. Examples, hook structure templates, and anti-pattern catalogs live in [reference/coding-philosophy.md](../reference/coding-philosophy.md).
+When writing or modifying code, follow these principles. Examples, hook structure templates, and anti-pattern catalogs live in [reference/coding-philosophy.md](coding-philosophy-reference.mdc).
 
 ## Principle priority
 

package/plugins/lisa-cursor/rules/{reference/config-resolution.md → config-resolution-reference.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Config Resolution"
+alwaysApply: false
+---
+
 # Config Resolution
 
 Lisa is vendor-agnostic. PRDs can be sourced from Notion, Confluence, Linear, GitHub Issues, or JIRA. Tickets can be written to JIRA, GitHub Issues, or Linear. Per-project configuration lives in `.lisa.config.json` at the repo root, with optional `.lisa.config.local.json` overriding on a per-key basis.

package/plugins/lisa-cursor/rules/{eager/config-resolution.md → config-resolution.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Config Resolution (load-bearing)"
+alwaysApply: true
+---
+
 # Config Resolution (load-bearing)
 
 Lisa configuration lives in `.lisa.config.json` (committed) and `.lisa.config.local.json` (gitignored, per-developer). The local file wins where they overlap. Developer-specific identity (`atlassian.email`, etc.) MUST live in the local file, never committed.
@@ -25,4 +30,4 @@ Project tracker (`jira` / `github` / `linear`) is read from `.lisa.config.json`
 
 `repo:<name>` is the canonical label for which repo a work item belongs to. Resolve current-repo identity in this priority order: `.lisa.config.local.json` `repo` → `.lisa.config.json` `repo` → `.lisa.config.json` `github.repo` → `basename -s .git "$(git remote get-url origin)"`. If none resolve, stop with a clear error.
 
-Full reference: [reference/config-resolution.md](../reference/config-resolution.md).
+Full reference: [reference/config-resolution.md](config-resolution-reference.mdc).

package/plugins/lisa-cursor/rules/{reference/documentation-source-paths.md → documentation-source-paths-reference.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Documentation Source Paths"
+alwaysApply: false
+---
+
 # Documentation Source Paths
 
 Do not treat `docs/`, `research/`, `transcripts/`, or other source-material directories as disposable duplicates just because a project also has a `wiki/`.

package/plugins/lisa-cursor/rules/{eager/documentation-source-paths.md → documentation-source-paths.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Documentation Source Paths (load-bearing)"
+alwaysApply: true
+---
+
 # Documentation Source Paths (load-bearing)
 
 Do not treat `docs/`, `research/`, `transcripts/`, or other source-material directories as disposable duplicates just because a project also has a `wiki/`. They may be ingestion inputs, executable fixtures, runtime inputs, or historical evidence.
@@ -10,4 +15,4 @@ Before moving, absorbing, or deleting documentation-like paths:
 4. When absorbing into `wiki/`, update source notes, indexes, logs, README links, rule references, and runtime defaults that pointed at the old path.
 5. Delete a path only AFTER references are updated and verification proves the project no longer reads it.
 
-Full context (Lisa-wiki specifics, `wiki/sources/` evidence layout): [reference/documentation-source-paths.md](../reference/documentation-source-paths.md).
+Full context (Lisa-wiki specifics, `wiki/sources/` evidence layout): [reference/documentation-source-paths.md](documentation-source-paths-reference.mdc).

package/plugins/lisa-cursor/rules/{reference/empirical-inquiry.md → empirical-inquiry-reference.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Empirical Inquiry — Test, Don't Guess"
+alwaysApply: false
+---
+
 # Empirical Inquiry — Test, Don't Guess
 
 When a decision depends on a fact you are not certain of — how a tool, API, harness, runtime, environment, or dependency actually behaves — **find out empirically before you act on it.** Run the smallest experiment that settles the question, observe the real result, and then proceed from what you observed. Do not reason your way to a confident-sounding answer from documentation, prior assumption, or training knowledge when the real system is right there and a quick probe would tell you the truth.

package/plugins/lisa-cursor/rules/{eager/empirical-inquiry.md → empirical-inquiry.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Empirical Inquiry — Test, Don't Guess (load-bearing)"
+alwaysApply: true
+---
+
 # Empirical Inquiry — Test, Don't Guess (load-bearing)
 
 When a decision depends on a fact you are not certain of — how a tool, API, harness, runtime, or dependency actually behaves — **find out empirically before you act.** Run the smallest experiment that settles the question, observe the real result, and proceed from what you observed.
@@ -19,4 +24,4 @@ Do not reason your way to a confident-sounding answer from documentation, prior
 
 This is the inquiry counterpart to the `verification` rule (which proves completed work behaves correctly). Both reject "it looks correct" as evidence.
 
-Full prose: [reference/empirical-inquiry.md](../reference/empirical-inquiry.md).
+Full prose: [reference/empirical-inquiry.md](empirical-inquiry-reference.mdc).

package/plugins/lisa-cursor/rules/{reference/intent-routing.md → intent-routing-reference.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Intent Routing"
+alwaysApply: false
+---
+
 # Intent Routing
 
 MANDATORY: On the **first user message of a session**, classify the request using the Flow Classification Protocol below and state the chosen flow before doing any other work. Do not respond to the substance of the request, do not start work, do not ask questions until you have stated which flow applies. Once a flow is established, treat it as fixed for the remainder of the session — **do not re-classify on subsequent messages**, even if a follow-up looks vague or conversational ("wait, what did you just do?", "now run the tests", "thanks"). Subsequent messages operate within the established flow unless the user explicitly changes scope. Skipping classification leads to unstructured responses that bypass readiness gates.

package/plugins/lisa-cursor/rules/{eager/intent-routing.md → intent-routing.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Intent Routing (load-bearing)"
+alwaysApply: true
+---
+
 # Intent Routing (load-bearing)
 
 **On the first user message of a session**, before responding to the substance of the request, before running any tool, before asking any clarifying question:
@@ -15,4 +20,4 @@ Once a flow is established, **do not re-classify** on later messages, even if a
 
 Skipping classification or orchestration echo leads to unstructured responses that bypass readiness gates.
 
-Full reference (flow definitions, readiness gates, orchestration matrix, sub-flows): [reference/intent-routing.md](../reference/intent-routing.md).
+Full reference (flow definitions, readiness gates, orchestration matrix, sub-flows): [reference/intent-routing.md](intent-routing-reference.mdc).

package/plugins/lisa-cursor/rules/{reference/leaf-only-lifecycle.md → leaf-only-lifecycle-reference.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Leaf-Only Build-Ready Invariant, Parent Status Rollup & Terminal Native Closure"
+alwaysApply: false
+---
+
 # Leaf-Only Build-Ready Invariant, Parent Status Rollup & Terminal Native Closure
 
 This is the single vendor-neutral source of truth for three coupled lifecycle rules. Every `*-to-tracker`, `*-write-*`, `*-validate-*`, and `*-build-intake` skill cites this rule rather than restating it, so per-vendor logic does not drift.

package/plugins/lisa-cursor/rules/{eager/leaf-only-lifecycle.md → leaf-only-lifecycle.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Leaf-Only Build-Ready Invariant (load-bearing)"
+alwaysApply: true
+---
+
 # Leaf-Only Build-Ready Invariant (load-bearing)
 
 **Build-ready means a directly implementable leaf work unit.** Containers never carry build-ready.
@@ -36,4 +41,4 @@ When a leaf reaches the true terminal `done` (the production / final-env value),
 
 Intermediate env-keyed states (`status:on-dev`, `On Stg`, etc.) remain open. Idempotent — if already closed, report and continue.
 
-Full vendor mechanics + the state machine in prose: [reference/leaf-only-lifecycle.md](../reference/leaf-only-lifecycle.md).
+Full vendor mechanics + the state machine in prose: [reference/leaf-only-lifecycle.md](leaf-only-lifecycle-reference.mdc).

package/plugins/lisa-cursor/rules/{reference/prd-lifecycle-rollup.md → prd-lifecycle-rollup-reference.mdc}

@@ -1,3 +1,8 @@
+---
+description: "PRD Lifecycle Rollup & Generated-Top-Level-Work Contract"
+alwaysApply: false
+---
+
 # PRD Lifecycle Rollup & Generated-Top-Level-Work Contract
 
 This is the single vendor-neutral source of truth for how a PRD owns the work it generates and how its lifecycle rolls up to `shipped` from that work. Every PRD-source and PRD-intake skill (`prd-backlink`, `prd-ticket-coverage`, `*-prd-intake`, `*-to-tracker`) cites this rule by slug rather than restating it, so PRD→child linking and PRD closure rollup behave identically across GitHub, Linear, JIRA/Atlassian, Confluence, and Notion instead of drifting per vendor.

package/plugins/lisa-cursor/rules/{eager/prd-lifecycle-rollup.md → prd-lifecycle-rollup.mdc}

@@ -1,3 +1,8 @@
+---
+description: "PRD Lifecycle Rollup & Generated-Top-Level-Work Contract (load-bearing)"
+alwaysApply: true
+---
+
 # PRD Lifecycle Rollup & Generated-Top-Level-Work Contract (load-bearing)
 
 The vendor-neutral source of truth for how a PRD owns the work it generated and how its lifecycle rolls up to `shipped`. Companion to `leaf-only-lifecycle` (which governs build-lifecycle of leaves); this rule governs PRD lifecycle and rollup from generated top-level children.
@@ -28,4 +33,4 @@ PRD rolls from `ticketed` to `shipped` when every required generated top-level c
 
 Re-runs of intake/backlink must dedupe by child-ref identity (e.g. `owner/repo#number` for GitHub, Linear issue UUID, JIRA key) — never by URL string, which varies by formatting.
 
-Full vendor matrix, predicate definitions, non-goals: [reference/prd-lifecycle-rollup.md](../reference/prd-lifecycle-rollup.md).
+Full vendor matrix, predicate definitions, non-goals: [reference/prd-lifecycle-rollup.md](prd-lifecycle-rollup-reference.mdc).

package/plugins/lisa-cursor/rules/{reference/repo-scope-split.md → repo-scope-split-reference.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Repo Scope & Work-Time Splitting"
+alwaysApply: false
+---
+
 # Repo Scope & Work-Time Splitting
 
 Leaf work units are single-repo. A **leaf work unit** is an individually implementable ticket with no child tickets — issue types **Bug, Task, Sub-task, Improvement**. Each must name exactly one repository. **Epic, Story, Spike** are coordination containers and may span repos.

package/plugins/lisa-cursor/rules/{eager/repo-scope-split.md → repo-scope-split.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Repo Scope & Work-Time Splitting (load-bearing)"
+alwaysApply: true
+---
+
 # Repo Scope & Work-Time Splitting (load-bearing)
 
 **Leaf work units are single-repo.** A leaf is an individually implementable ticket with no children — types **Bug, Task, Sub-task, Improvement**. Each names exactly one repo. **Epic, Story, Spike** are coordination containers and may span repos.
@@ -36,4 +41,4 @@ A tracker can oversee multiple repos. Build-intake claims only current-repo tick
 2. **Multi-repo leaf → split, never claim.** Each split sibling is created build-ready and stamped with its own `repo:<name>`.
 3. **Wrong-repo single-repo leaf → skip** (label keeps it cheap next cycle).
 
-Vendor mechanics (JIRA/GitHub/Linear) and full procedure: [reference/repo-scope-split.md](../reference/repo-scope-split.md).
+Vendor mechanics (JIRA/GitHub/Linear) and full procedure: [reference/repo-scope-split.md](repo-scope-split-reference.mdc).

package/plugins/lisa-cursor/rules/{reference/security-audit-handling.md → security-audit-handling-reference.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Security Audit Handling"
+alwaysApply: false
+---
+
 # Security Audit Handling
 
 If `git push` fails because the pre-push hook reports security vulnerabilities, follow these steps. Never use `--no-verify` to bypass the security audit.

package/plugins/lisa-cursor/rules/{eager/security-audit-handling.md → security-audit-handling.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Security Audit Handling (load-bearing)"
+alwaysApply: true
+---
+
 # Security Audit Handling (load-bearing)
 
 If `git push` fails because the pre-push hook reports security vulnerabilities, follow the rules below. **Never use `--no-verify`** to bypass the security audit.
@@ -26,4 +31,4 @@ Before adding any override, verify:
 3. If transitive with patch: `bundle update <gem>` to bump the lockfile only, commit, retry.
 4. If no patch but safe: document the exception, retry.
 
-Full procedure with examples: [reference/security-audit-handling.md](../reference/security-audit-handling.md).
+Full procedure with examples: [reference/security-audit-handling.md](security-audit-handling-reference.mdc).

package/plugins/lisa-cursor/rules/{reference/usage-accounting.md → usage-accounting-reference.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Usage Accounting"
+alwaysApply: false
+---
+
 # Usage Accounting
 
 Lisa usage accounting is a vendor-neutral contract for attaching AI usage and cost telemetry to the artifacts Lisa creates or updates. It governs the section shape, machine-readable tokens, source/pricing semantics, rollup behavior, and idempotent rewrite rules. Writer skills and lifecycle skills attach telemetry by following this contract; they do not invent artifact-local formats.

package/plugins/lisa-cursor/rules/{eager/usage-accounting.md → usage-accounting.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Usage Accounting (load-bearing)"
+alwaysApply: true
+---
+
 # Usage Accounting (load-bearing)
 
 Lisa attaches AI usage and cost telemetry to every artifact it creates/updates. The format is a single canonical managed section.
@@ -25,4 +30,4 @@ Each direct entry records ONE logical Lisa run on ONE artifact. `entry_id` is th
 
 Container artifacts (Epic, PRD, etc.) roll up usage from their direct children. Roll-up is recursive — a parent's `## Lisa Usage` aggregates its descendants' direct entries. Re-writes are idempotent: re-running an intake or lifecycle skill must not duplicate entries.
 
-Full schema (all 17 fields, pricing semantics, rollup math, idempotent-rewrite rules): [reference/usage-accounting.md](../reference/usage-accounting.md).
+Full schema (all 17 fields, pricing semantics, rollup math, idempotent-rewrite rules): [reference/usage-accounting.md](usage-accounting-reference.mdc).

package/plugins/lisa-cursor/rules/{reference/verification.md → verification-reference.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Empirical Verification"
+alwaysApply: false
+---
+
 # Empirical Verification
 
 This repository supports AI agents as first-class contributors.

package/plugins/lisa-cursor/rules/{eager/verification.md → verification.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Empirical Verification (load-bearing)"
+alwaysApply: true
+---
+
 # Empirical Verification (load-bearing)
 
 **Verification is not linting, typechecking, or testing.** Those are *quality checks* — necessary prerequisites, but NOT verification.
@@ -18,4 +23,4 @@
 - **Verifier agent** — acts as the end user / API client / operator. Independent from Builder when possible.
 - **Human overseer** — approves risky operations and anything agents cannot fully verify.
 
-Full operational contract (verification types, evidence formats, escalation protocol): [reference/verification.md](../reference/verification.md).
+Full operational contract (verification types, evidence formats, escalation protocol): [reference/verification.md](verification-reference.mdc).

package/plugins/lisa-cursor/rules/{reference/wiki-knowledge-source.md → wiki-knowledge-source-reference.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Wiki as Knowledge Source"
+alwaysApply: false
+---
+
 # Wiki as Knowledge Source
 
 If this project has an LLM Wiki (a `wiki/` directory with an `index.md`), treat it as the canonical source of durable project knowledge. The wiki is curated and current; ad-hoc scraping of code, tickets, chat history, or stale READMEs is not.

package/plugins/lisa-cursor/rules/{eager/wiki-knowledge-source.md → wiki-knowledge-source.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Wiki as Knowledge Source (load-bearing)"
+alwaysApply: true
+---
+
 # Wiki as Knowledge Source (load-bearing)
 
 If the project has an LLM Wiki (a `wiki/` directory with `index.md`), treat it as the canonical source of durable project knowledge.
@@ -13,4 +18,4 @@ The wiki documents knowledge; it does NOT override executable behavior. When wik
 
 If the project has no `wiki/`, this rule does not apply.
 
-Full prose: [reference/wiki-knowledge-source.md](../reference/wiki-knowledge-source.md).
+Full prose: [reference/wiki-knowledge-source.md](wiki-knowledge-source-reference.mdc).

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

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

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.124.4",
+  "version": "2.124.6",
   "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.124.4",
+  "version": "2.124.6",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.124.4",
+  "version": "2.124.6",
   "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.124.4",
+  "version": "2.124.6",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

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

package/plugins/lisa-harper-fabric-cursor/rules/{harper-fabric.md → harper-fabric.mdc}

@@ -1,3 +1,8 @@
+---
+description: "Harper/Fabric Project Rules"
+alwaysApply: true
+---
+
 # Harper/Fabric Project Rules
 
 These rules apply to Harper/Fabric component apps managed by Lisa.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.124.4",
+  "version": "2.124.6",
   "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.124.4",
+  "version": "2.124.6",
   "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.124.4",
+  "version": "2.124.6",
   "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.124.4",
+  "version": "2.124.6",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"