@codyswann/lisa 3.45.3 → 3.45.5

package/dist/opencode/plugin-templates/lisa-session-bootstrap.ts

@@ -4,7 +4,8 @@
  * OpenCode runs a plugin's factory function once when it loads the plugin at
  * session start, which is the natural home for Lisa's Codex SessionStart hooks:
  *   - install-pkgs.sh   → install dependencies when node_modules is missing
- *   - setup-jira-cli.sh → write jira-cli config from environment variables
+ *   - setup-jira-cli.sh → write jira-cli config from environment variables, only
+ *     when the project's configured tracker is jira
  *
  * Both are fully fail-open (wrapped in try/catch) so a package-manager or
  * filesystem hiccup never bricks OpenCode startup, mirroring the Codex scripts.
@@ -61,6 +62,10 @@ export const LisaSessionBootstrap = async ({
   }
 
   // setup-jira-cli: write jira-cli config from environment variables and non-secret Lisa config.
+  // Gated on `tracker: "jira"` — a project on Linear or GitHub Issues has no use
+  // for a jira-cli config, and writing one made a false implicit claim about the
+  // project's tracker. Fails closed: an absent tracker writes nothing, because
+  // Lisa treats a missing `tracker` as unconfigured, not as a jira default.
   try {
     const readLisaConfig = (path: string[]) => {
       for (const file of [".lisa.config.local.json", ".lisa.config.json"]) {
@@ -82,6 +87,7 @@ export const LisaSessionBootstrap = async ({
       }
       return undefined;
     };
+    if (readLisaConfig(["tracker"]) !== "jira") return {};
     const atlassianSite = readLisaConfig(["atlassian", "site"]);
     const server =
       process.env.JIRA_SERVER ??

package/package.json

@@ -132,7 +132,7 @@
     "ws": ">=8.21.0"
   },
   "name": "@codyswann/lisa",
-  "version": "3.45.3",
+  "version": "3.45.5",
   "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": "3.45.3",
+  "version": "3.45.5",
   "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": "3.45.3",
+  "version": "3.45.5",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/.codex-plugin/skills/lisa-analyze-claude-remote/SKILL.md

@@ -28,7 +28,7 @@ This skill ships in the base Lisa plugin and is distributed to every host projec
 discover requirements **dynamically from the repo** rather than assuming Lisa-repo specifics. It
 audits two layers together:
 
-- **Lisa's needs** — startup hooks (`install-pkgs.sh`, `setup-jira-cli.sh`, rule injection),
+- **Lisa's needs** — startup hooks (`install-pkgs.sh`, `setup-jira-cli.sh` — tracker-gated, rule injection),
   the configured `tracker`/`source`, and the CLIs/MCP/env those imply.
 - **The host project's needs** — its own package manager, build/test tooling, app runtime
   dependencies, CI-assumed binaries, and project-scoped MCP servers.
@@ -71,7 +71,9 @@ Group the findings as:
    runs, whether it is headless-safe, whether it needs network or write access to system paths,
    and whether it fits the cloud setup-script time budget (~5 minutes for environment caching;
    `SessionStart` hooks re-run every session and must be fast). Lisa's `install-pkgs.sh` and
-   `setup-jira-cli.sh` are the usual headline items.
+   `setup-jira-cli.sh` are the usual headline items. Note that `setup-jira-cli.sh` is gated on
+   `tracker: "jira"` — on a project using another tracker it exits immediately and needs no
+   environment at all, so do not report its JIRA env vars as required there.
 
 3. **External CLIs / binaries** — scan hooks, `scripts/`, committed skills/commands, and
    `.github/workflows/` for invoked binaries that a base cloud image likely lacks. Assume node,
@@ -256,7 +258,7 @@ unsuffixed `…_TOKEN`/`…_KEY` is the simplest to set in a single-account rout
 
 ### JIRA — `tracker: jira`
 - Headless substrate: `jira-cli` + curl (Basic auth). The acli and Atlassian-MCP tiers need prior interactive/OAuth auth → not viable headless.
-- Env: `JIRA_API_TOKEN`, `JIRA_SERVER` (e.g. `https://acme.atlassian.net`), `JIRA_LOGIN` (account email), `JIRA_PROJECT` (default project key); optional `JIRA_INSTALLATION` (default `cloud`), `JIRA_BOARD`. (`setup-jira-cli.sh` writes the jira-cli config from these on SessionStart.)
+- Env: `JIRA_API_TOKEN`, `JIRA_SERVER` (e.g. `https://acme.atlassian.net`), `JIRA_LOGIN` (account email), `JIRA_PROJECT` (default project key); optional `JIRA_INSTALLATION` (default `cloud`), `JIRA_BOARD`. (`setup-jira-cli.sh` writes the jira-cli config from these on SessionStart — but only when `.lisa.config*.json` sets `tracker: "jira"`; on any other tracker the hook is a no-op.)
 - Acquire: `https://id.atlassian.com/manage-profile/security/api-tokens`.
 - Access: the API token inherits the Atlassian user's permissions — the user must have Browse/Create/Edit/Transition on the target project. An unscoped token suffices for jira-cli; a scoped token must cover the JIRA project read/write operations.
 

package/plugins/lisa/hooks/block-managed-file-edits.sh

@@ -141,14 +141,24 @@ lisaignored() {
         ;;
     esac
     if [ "$selected" -ne 0 ]; then
-      # shellcheck disable=SC2254 -- the pattern is a glob on purpose.
+      # The pattern is a glob on purpose, so it is deliberately unquoted.
+      #
+      # The reason sits on its own line because a shellcheck directive is
+      # `key=value` pairs and NOTHING else. Written as
+      # `disable=SC2254 -- <prose>`, the trailing words are read as more
+      # directive keys: the directive fails with SC1072/SC1073, shellcheck
+      # stops checking the rest of THIS FILE, and SC2254 is left unsuppressed
+      # as well. Measured with shellcheck 0.11.0. Do not rejoin these lines.
+      # shellcheck disable=SC2254
       case "$rel" in $pattern) selected=0 ;; esac
     fi
     if [ "$selected" -ne 0 ]; then
       case "$pattern" in
         */*) ;;
         *)
-          # shellcheck disable=SC2254 -- ditto, matched against the basename.
+          # Ditto, matched against the basename — and ditto about the reason
+          # living on its own line rather than after the directive.
+          # shellcheck disable=SC2254
           case "${rel##*/}" in $pattern) selected=0 ;; esac
           ;;
       esac

package/plugins/lisa/hooks/setup-jira-cli.sh

@@ -3,6 +3,13 @@
 # Writes the JIRA CLI config file from environment variables.
 # Runs on SessionStart so the config is available for every session.
 #
+# Gated on the project's configured tracker: this only writes anything when
+# `.lisa.config*.json` declares `tracker: "jira"`. A project on Linear or GitHub
+# Issues has no use for a jira-cli config, and writing one made a false implicit
+# claim about which tracker the project runs on. The gate fails closed — an
+# unreadable or absent tracker writes nothing — because Lisa treats a missing
+# `tracker` as unconfigured rather than as a jira default (see lisa-tracker-read).
+#
 # Required env vars (must be created in your Claude Code Web environment):
 #   JIRA_INSTALLATION - cloud or local
 #   JIRA_SERVER       - Atlassian instance URL (falls back to .lisa.config*.json atlassian.site)
@@ -42,6 +49,11 @@ read_lisa_config() {
   printf '%s' "${value}"
 }
 
+# Tracker gate: do nothing unless this project actually runs on JIRA.
+if [[ "$(read_lisa_config '.tracker')" != "jira" ]]; then
+  exit 0
+fi
+
 if [[ -z "${JIRA_SERVER:-}" ]]; then
   ATLASSIAN_SITE="$(read_lisa_config '.atlassian.site')"
   if [[ -n "${ATLASSIAN_SITE}" ]]; then

package/plugins/lisa/skills/lisa-analyze-claude-remote/SKILL.md

@@ -28,7 +28,7 @@ This skill ships in the base Lisa plugin and is distributed to every host projec
 discover requirements **dynamically from the repo** rather than assuming Lisa-repo specifics. It
 audits two layers together:
 
-- **Lisa's needs** — startup hooks (`install-pkgs.sh`, `setup-jira-cli.sh`, rule injection),
+- **Lisa's needs** — startup hooks (`install-pkgs.sh`, `setup-jira-cli.sh` — tracker-gated, rule injection),
   the configured `tracker`/`source`, and the CLIs/MCP/env those imply.
 - **The host project's needs** — its own package manager, build/test tooling, app runtime
   dependencies, CI-assumed binaries, and project-scoped MCP servers.
@@ -71,7 +71,9 @@ Group the findings as:
    runs, whether it is headless-safe, whether it needs network or write access to system paths,
    and whether it fits the cloud setup-script time budget (~5 minutes for environment caching;
    `SessionStart` hooks re-run every session and must be fast). Lisa's `install-pkgs.sh` and
-   `setup-jira-cli.sh` are the usual headline items.
+   `setup-jira-cli.sh` are the usual headline items. Note that `setup-jira-cli.sh` is gated on
+   `tracker: "jira"` — on a project using another tracker it exits immediately and needs no
+   environment at all, so do not report its JIRA env vars as required there.
 
 3. **External CLIs / binaries** — scan hooks, `scripts/`, committed skills/commands, and
    `.github/workflows/` for invoked binaries that a base cloud image likely lacks. Assume node,
@@ -256,7 +258,7 @@ unsuffixed `…_TOKEN`/`…_KEY` is the simplest to set in a single-account rout
 
 ### JIRA — `tracker: jira`
 - Headless substrate: `jira-cli` + curl (Basic auth). The acli and Atlassian-MCP tiers need prior interactive/OAuth auth → not viable headless.
-- Env: `JIRA_API_TOKEN`, `JIRA_SERVER` (e.g. `https://acme.atlassian.net`), `JIRA_LOGIN` (account email), `JIRA_PROJECT` (default project key); optional `JIRA_INSTALLATION` (default `cloud`), `JIRA_BOARD`. (`setup-jira-cli.sh` writes the jira-cli config from these on SessionStart.)
+- Env: `JIRA_API_TOKEN`, `JIRA_SERVER` (e.g. `https://acme.atlassian.net`), `JIRA_LOGIN` (account email), `JIRA_PROJECT` (default project key); optional `JIRA_INSTALLATION` (default `cloud`), `JIRA_BOARD`. (`setup-jira-cli.sh` writes the jira-cli config from these on SessionStart — but only when `.lisa.config*.json` sets `tracker: "jira"`; on any other tracker the hook is a no-op.)
 - Acquire: `https://id.atlassian.com/manage-profile/security/api-tokens`.
 - Access: the API token inherits the Atlassian user's permissions — the user must have Browse/Create/Edit/Transition on the target project. An unscoped token suffices for jira-cli; a scoped token must cover the JIRA project read/write operations.
 

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/skills/lisa-analyze-claude-remote/SKILL.md

@@ -28,7 +28,7 @@ This skill ships in the base Lisa plugin and is distributed to every host projec
 discover requirements **dynamically from the repo** rather than assuming Lisa-repo specifics. It
 audits two layers together:
 
-- **Lisa's needs** — startup hooks (`install-pkgs.sh`, `setup-jira-cli.sh`, rule injection),
+- **Lisa's needs** — startup hooks (`install-pkgs.sh`, `setup-jira-cli.sh` — tracker-gated, rule injection),
   the configured `tracker`/`source`, and the CLIs/MCP/env those imply.
 - **The host project's needs** — its own package manager, build/test tooling, app runtime
   dependencies, CI-assumed binaries, and project-scoped MCP servers.
@@ -71,7 +71,9 @@ Group the findings as:
    runs, whether it is headless-safe, whether it needs network or write access to system paths,
    and whether it fits the cloud setup-script time budget (~5 minutes for environment caching;
    `SessionStart` hooks re-run every session and must be fast). Lisa's `install-pkgs.sh` and
-   `setup-jira-cli.sh` are the usual headline items.
+   `setup-jira-cli.sh` are the usual headline items. Note that `setup-jira-cli.sh` is gated on
+   `tracker: "jira"` — on a project using another tracker it exits immediately and needs no
+   environment at all, so do not report its JIRA env vars as required there.
 
 3. **External CLIs / binaries** — scan hooks, `scripts/`, committed skills/commands, and
    `.github/workflows/` for invoked binaries that a base cloud image likely lacks. Assume node,
@@ -256,7 +258,7 @@ unsuffixed `…_TOKEN`/`…_KEY` is the simplest to set in a single-account rout
 
 ### JIRA — `tracker: jira`
 - Headless substrate: `jira-cli` + curl (Basic auth). The acli and Atlassian-MCP tiers need prior interactive/OAuth auth → not viable headless.
-- Env: `JIRA_API_TOKEN`, `JIRA_SERVER` (e.g. `https://acme.atlassian.net`), `JIRA_LOGIN` (account email), `JIRA_PROJECT` (default project key); optional `JIRA_INSTALLATION` (default `cloud`), `JIRA_BOARD`. (`setup-jira-cli.sh` writes the jira-cli config from these on SessionStart.)
+- Env: `JIRA_API_TOKEN`, `JIRA_SERVER` (e.g. `https://acme.atlassian.net`), `JIRA_LOGIN` (account email), `JIRA_PROJECT` (default project key); optional `JIRA_INSTALLATION` (default `cloud`), `JIRA_BOARD`. (`setup-jira-cli.sh` writes the jira-cli config from these on SessionStart — but only when `.lisa.config*.json` sets `tracker: "jira"`; on any other tracker the hook is a no-op.)
 - Acquire: `https://id.atlassian.com/manage-profile/security/api-tokens`.
 - Access: the API token inherits the Atlassian user's permissions — the user must have Browse/Create/Edit/Transition on the target project. An unscoped token suffices for jira-cli; a scoped token must cover the JIRA project read/write operations.
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "3.45.3",
+  "version": "3.45.5",
   "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": "3.45.3",
+  "version": "3.45.5",
   "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": "3.45.3",
+  "version": "3.45.5",
   "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": "3.45.3",
+  "version": "3.45.5",
   "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": "3.45.3",
+  "version": "3.45.5",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

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

package/plugins/lisa-copilot/hooks/block-managed-file-edits.sh

@@ -141,14 +141,24 @@ lisaignored() {
         ;;
     esac
     if [ "$selected" -ne 0 ]; then
-      # shellcheck disable=SC2254 -- the pattern is a glob on purpose.
+      # The pattern is a glob on purpose, so it is deliberately unquoted.
+      #
+      # The reason sits on its own line because a shellcheck directive is
+      # `key=value` pairs and NOTHING else. Written as
+      # `disable=SC2254 -- <prose>`, the trailing words are read as more
+      # directive keys: the directive fails with SC1072/SC1073, shellcheck
+      # stops checking the rest of THIS FILE, and SC2254 is left unsuppressed
+      # as well. Measured with shellcheck 0.11.0. Do not rejoin these lines.
+      # shellcheck disable=SC2254
       case "$rel" in $pattern) selected=0 ;; esac
     fi
     if [ "$selected" -ne 0 ]; then
       case "$pattern" in
         */*) ;;
         *)
-          # shellcheck disable=SC2254 -- ditto, matched against the basename.
+          # Ditto, matched against the basename — and ditto about the reason
+          # living on its own line rather than after the directive.
+          # shellcheck disable=SC2254
           case "${rel##*/}" in $pattern) selected=0 ;; esac
           ;;
       esac

package/plugins/lisa-copilot/hooks/setup-jira-cli.sh

@@ -3,6 +3,13 @@
 # Writes the JIRA CLI config file from environment variables.
 # Runs on SessionStart so the config is available for every session.
 #
+# Gated on the project's configured tracker: this only writes anything when
+# `.lisa.config*.json` declares `tracker: "jira"`. A project on Linear or GitHub
+# Issues has no use for a jira-cli config, and writing one made a false implicit
+# claim about which tracker the project runs on. The gate fails closed — an
+# unreadable or absent tracker writes nothing — because Lisa treats a missing
+# `tracker` as unconfigured rather than as a jira default (see lisa-tracker-read).
+#
 # Required env vars (must be created in your Claude Code Web environment):
 #   JIRA_INSTALLATION - cloud or local
 #   JIRA_SERVER       - Atlassian instance URL (falls back to .lisa.config*.json atlassian.site)
@@ -42,6 +49,11 @@ read_lisa_config() {
   printf '%s' "${value}"
 }
 
+# Tracker gate: do nothing unless this project actually runs on JIRA.
+if [[ "$(read_lisa_config '.tracker')" != "jira" ]]; then
+  exit 0
+fi
+
 if [[ -z "${JIRA_SERVER:-}" ]]; then
   ATLASSIAN_SITE="$(read_lisa_config '.atlassian.site')"
   if [[ -n "${ATLASSIAN_SITE}" ]]; then

package/plugins/lisa-copilot/skills/lisa-analyze-claude-remote/SKILL.md

@@ -28,7 +28,7 @@ This skill ships in the base Lisa plugin and is distributed to every host projec
 discover requirements **dynamically from the repo** rather than assuming Lisa-repo specifics. It
 audits two layers together:
 
-- **Lisa's needs** — startup hooks (`install-pkgs.sh`, `setup-jira-cli.sh`, rule injection),
+- **Lisa's needs** — startup hooks (`install-pkgs.sh`, `setup-jira-cli.sh` — tracker-gated, rule injection),
   the configured `tracker`/`source`, and the CLIs/MCP/env those imply.
 - **The host project's needs** — its own package manager, build/test tooling, app runtime
   dependencies, CI-assumed binaries, and project-scoped MCP servers.
@@ -71,7 +71,9 @@ Group the findings as:
    runs, whether it is headless-safe, whether it needs network or write access to system paths,
    and whether it fits the cloud setup-script time budget (~5 minutes for environment caching;
    `SessionStart` hooks re-run every session and must be fast). Lisa's `install-pkgs.sh` and
-   `setup-jira-cli.sh` are the usual headline items.
+   `setup-jira-cli.sh` are the usual headline items. Note that `setup-jira-cli.sh` is gated on
+   `tracker: "jira"` — on a project using another tracker it exits immediately and needs no
+   environment at all, so do not report its JIRA env vars as required there.
 
 3. **External CLIs / binaries** — scan hooks, `scripts/`, committed skills/commands, and
    `.github/workflows/` for invoked binaries that a base cloud image likely lacks. Assume node,
@@ -256,7 +258,7 @@ unsuffixed `…_TOKEN`/`…_KEY` is the simplest to set in a single-account rout
 
 ### JIRA — `tracker: jira`
 - Headless substrate: `jira-cli` + curl (Basic auth). The acli and Atlassian-MCP tiers need prior interactive/OAuth auth → not viable headless.
-- Env: `JIRA_API_TOKEN`, `JIRA_SERVER` (e.g. `https://acme.atlassian.net`), `JIRA_LOGIN` (account email), `JIRA_PROJECT` (default project key); optional `JIRA_INSTALLATION` (default `cloud`), `JIRA_BOARD`. (`setup-jira-cli.sh` writes the jira-cli config from these on SessionStart.)
+- Env: `JIRA_API_TOKEN`, `JIRA_SERVER` (e.g. `https://acme.atlassian.net`), `JIRA_LOGIN` (account email), `JIRA_PROJECT` (default project key); optional `JIRA_INSTALLATION` (default `cloud`), `JIRA_BOARD`. (`setup-jira-cli.sh` writes the jira-cli config from these on SessionStart — but only when `.lisa.config*.json` sets `tracker: "jira"`; on any other tracker the hook is a no-op.)
 - Acquire: `https://id.atlassian.com/manage-profile/security/api-tokens`.
 - Access: the API token inherits the Atlassian user's permissions — the user must have Browse/Create/Edit/Transition on the target project. An unscoped token suffices for jira-cli; a scoped token must cover the JIRA project read/write operations.
 

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

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

package/plugins/lisa-cursor/hooks/block-managed-file-edits.sh

@@ -141,14 +141,24 @@ lisaignored() {
         ;;
     esac
     if [ "$selected" -ne 0 ]; then
-      # shellcheck disable=SC2254 -- the pattern is a glob on purpose.
+      # The pattern is a glob on purpose, so it is deliberately unquoted.
+      #
+      # The reason sits on its own line because a shellcheck directive is
+      # `key=value` pairs and NOTHING else. Written as
+      # `disable=SC2254 -- <prose>`, the trailing words are read as more
+      # directive keys: the directive fails with SC1072/SC1073, shellcheck
+      # stops checking the rest of THIS FILE, and SC2254 is left unsuppressed
+      # as well. Measured with shellcheck 0.11.0. Do not rejoin these lines.
+      # shellcheck disable=SC2254
       case "$rel" in $pattern) selected=0 ;; esac
     fi
     if [ "$selected" -ne 0 ]; then
       case "$pattern" in
         */*) ;;
         *)
-          # shellcheck disable=SC2254 -- ditto, matched against the basename.
+          # Ditto, matched against the basename — and ditto about the reason
+          # living on its own line rather than after the directive.
+          # shellcheck disable=SC2254
           case "${rel##*/}" in $pattern) selected=0 ;; esac
           ;;
       esac

package/plugins/lisa-cursor/hooks/setup-jira-cli.sh

@@ -3,6 +3,13 @@
 # Writes the JIRA CLI config file from environment variables.
 # Runs on SessionStart so the config is available for every session.
 #
+# Gated on the project's configured tracker: this only writes anything when
+# `.lisa.config*.json` declares `tracker: "jira"`. A project on Linear or GitHub
+# Issues has no use for a jira-cli config, and writing one made a false implicit
+# claim about which tracker the project runs on. The gate fails closed — an
+# unreadable or absent tracker writes nothing — because Lisa treats a missing
+# `tracker` as unconfigured rather than as a jira default (see lisa-tracker-read).
+#
 # Required env vars (must be created in your Claude Code Web environment):
 #   JIRA_INSTALLATION - cloud or local
 #   JIRA_SERVER       - Atlassian instance URL (falls back to .lisa.config*.json atlassian.site)
@@ -42,6 +49,11 @@ read_lisa_config() {
   printf '%s' "${value}"
 }
 
+# Tracker gate: do nothing unless this project actually runs on JIRA.
+if [[ "$(read_lisa_config '.tracker')" != "jira" ]]; then
+  exit 0
+fi
+
 if [[ -z "${JIRA_SERVER:-}" ]]; then
   ATLASSIAN_SITE="$(read_lisa_config '.atlassian.site')"
   if [[ -n "${ATLASSIAN_SITE}" ]]; then

package/plugins/lisa-cursor/skills/lisa-analyze-claude-remote/SKILL.md

@@ -28,7 +28,7 @@ This skill ships in the base Lisa plugin and is distributed to every host projec
 discover requirements **dynamically from the repo** rather than assuming Lisa-repo specifics. It
 audits two layers together:
 
-- **Lisa's needs** — startup hooks (`install-pkgs.sh`, `setup-jira-cli.sh`, rule injection),
+- **Lisa's needs** — startup hooks (`install-pkgs.sh`, `setup-jira-cli.sh` — tracker-gated, rule injection),
   the configured `tracker`/`source`, and the CLIs/MCP/env those imply.
 - **The host project's needs** — its own package manager, build/test tooling, app runtime
   dependencies, CI-assumed binaries, and project-scoped MCP servers.
@@ -71,7 +71,9 @@ Group the findings as:
    runs, whether it is headless-safe, whether it needs network or write access to system paths,
    and whether it fits the cloud setup-script time budget (~5 minutes for environment caching;
    `SessionStart` hooks re-run every session and must be fast). Lisa's `install-pkgs.sh` and
-   `setup-jira-cli.sh` are the usual headline items.
+   `setup-jira-cli.sh` are the usual headline items. Note that `setup-jira-cli.sh` is gated on
+   `tracker: "jira"` — on a project using another tracker it exits immediately and needs no
+   environment at all, so do not report its JIRA env vars as required there.
 
 3. **External CLIs / binaries** — scan hooks, `scripts/`, committed skills/commands, and
    `.github/workflows/` for invoked binaries that a base cloud image likely lacks. Assume node,
@@ -256,7 +258,7 @@ unsuffixed `…_TOKEN`/`…_KEY` is the simplest to set in a single-account rout
 
 ### JIRA — `tracker: jira`
 - Headless substrate: `jira-cli` + curl (Basic auth). The acli and Atlassian-MCP tiers need prior interactive/OAuth auth → not viable headless.
-- Env: `JIRA_API_TOKEN`, `JIRA_SERVER` (e.g. `https://acme.atlassian.net`), `JIRA_LOGIN` (account email), `JIRA_PROJECT` (default project key); optional `JIRA_INSTALLATION` (default `cloud`), `JIRA_BOARD`. (`setup-jira-cli.sh` writes the jira-cli config from these on SessionStart.)
+- Env: `JIRA_API_TOKEN`, `JIRA_SERVER` (e.g. `https://acme.atlassian.net`), `JIRA_LOGIN` (account email), `JIRA_PROJECT` (default project key); optional `JIRA_INSTALLATION` (default `cloud`), `JIRA_BOARD`. (`setup-jira-cli.sh` writes the jira-cli config from these on SessionStart — but only when `.lisa.config*.json` sets `tracker: "jira"`; on any other tracker the hook is a no-op.)
 - Acquire: `https://id.atlassian.com/manage-profile/security/api-tokens`.
 - Access: the API token inherits the Atlassian user's permissions — the user must have Browse/Create/Edit/Transition on the target project. An unscoped token suffices for jira-cli; a scoped token must cover the JIRA project read/write operations.
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "3.45.3",
+  "version": "3.45.5",
   "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": "3.45.3",
+  "version": "3.45.5",
   "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": "3.45.3",
+  "version": "3.45.5",
   "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": "3.45.3",
+  "version": "3.45.5",
   "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": "3.45.3",
+  "version": "3.45.5",
   "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": "3.45.3",
+  "version": "3.45.5",
   "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": "3.45.3",
+  "version": "3.45.5",
   "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": "3.45.3",
+  "version": "3.45.5",
   "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": "3.45.3",
+  "version": "3.45.5",
   "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": "3.45.3",
+  "version": "3.45.5",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

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

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

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

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

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

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

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

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

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

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

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