@codyswann/lisa 2.195.2 → 2.195.4

package/package.json

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

package/plugins/lisa/commands/lisa/validate-tracker-mapping.md

@@ -9,7 +9,7 @@ Common usage:
 
 - `/lisa:validate-tracker-mapping` — audit the current repo's mapping (read-only).
 - `/lisa:validate-tracker-mapping repair=true` — audit and repair config drift in the current repo.
-- `/lisa:validate-tracker-mapping projects=~/workspace/geminisportsai/projects/*` — sweep every Lisa project under a directory.
-- `/lisa:validate-tracker-mapping workspaces=~/workspace/lisa/.lisa.workspaces.json filter=geminisportsai` — sweep the projects in a workspaces file whose paths match a substring.
+- `/lisa:validate-tracker-mapping projects=~/workspace/acme/projects/*` — sweep every Lisa project under a directory.
+- `/lisa:validate-tracker-mapping workspaces=~/workspace/lisa/.lisa.workspaces.json filter=acme` — sweep the projects in a workspaces file whose paths match a substring.
 
 Use this when you suspect a JIRA/GitHub/Linear/Notion status, label, or option was renamed or deleted out from under Lisa — the failure mode that leaves builds unable to find their completion transition and items silently stuck. Run it read-only (or on a schedule) to detect drift; run it with `repair=true` to fix the config. Repair only ever edits the config to match the live names — it never renames anything in the tracker.

package/plugins/lisa/rules/reference/config-resolution.md

@@ -248,7 +248,7 @@ Each vendor section is **conditionally required**: required only when that vendo
 | Field | Required when | Where it lives | Notes |
 |-------|---------------|----------------|-------|
 | `atlassian.cloudId` | `tracker = "jira"`, `source = "jira"`, `source = "confluence"`, or any `confluence-*` / `jira-*` skill is invoked | **committed** (`.lisa.config.json`) | Atlassian Cloud site UUID. Same for every developer on the project. Resolve once via `curl https://<site>/_edge/tenant_info` or `getAccessibleAtlassianResources`. Shared between JIRA and Confluence (same Atlassian site). |
-| `atlassian.site` | same as above | **committed** | Human-readable site URL (e.g. `propswap.atlassian.net`). Same for every developer. |
+| `atlassian.site` | same as above | **committed** | Human-readable site URL (e.g. `acme.atlassian.net`). Same for every developer. |
 | `atlassian.email` | when the developer's machine has multiple Atlassian accounts that can access the configured site | **local** (`.lisa.config.local.json`) | Per-developer. `--site` alone cannot disambiguate which acli profile to switch to when two accounts both have access to the same site (e.g., a personal account and a work account both invited to a customer's site). The setup skill writes this to the local override file, NEVER the committed file. |
 
 #### `jira`

package/plugins/lisa/skills/lisa-atlassian-access/SKILL.md

@@ -282,7 +282,7 @@ Substrate column meanings:
 - Multiple cells filled means tier ordering applies — try acli, then MCP, then curl, taking the first that has an adapter for the op AND is identity-matched.
 - One cell means only that substrate can perform the op.
 
-`<SITE>` = `.atlassian.site` (e.g. `propswap.atlassian.net`). `<CLOUDID>` = `.atlassian.cloudId`. `<AUTH>` = `Basic $(printf '%s:%s' "$email" "$ATLASSIAN_API_TOKEN" | base64)`. JIRA curl writes use the cloudId-bound Atlassian gateway `https://api.atlassian.com/ex/jira/<CLOUDID>/rest/api/3/...`; JIRA curl reads may use either that gateway or `https://<SITE>/rest/api/3/...` after the token account check. Confluence uses `/wiki/rest/api/...` (v1) or `/api/v2/...` (v2).
+`<SITE>` = `.atlassian.site` (e.g. `acme.atlassian.net`). `<CLOUDID>` = `.atlassian.cloudId`. `<AUTH>` = `Basic $(printf '%s:%s' "$email" "$ATLASSIAN_API_TOKEN" | base64)`. JIRA curl writes use the cloudId-bound Atlassian gateway `https://api.atlassian.com/ex/jira/<CLOUDID>/rest/api/3/...`; JIRA curl reads may use either that gateway or `https://<SITE>/rest/api/3/...` after the token account check. Confluence uses `/wiki/rest/api/...` (v1) or `/api/v2/...` (v2).
 
 | Operation | acli adapter | MCP adapter | curl adapter |
 |---|---|---|---|

package/plugins/lisa/skills/lisa-notion-prd-intake/SKILL.md

@@ -11,7 +11,7 @@ allowed-tools: ["Skill", "Bash", "Read", "Write", "Edit", "AskUserQuestion"]
 `$ARGUMENTS` is a Notion database URL (or bare database ID) — for example:
 
 ```text
-https://www.notion.so/geminisports/28fd00244d7d47c5866876f7de48c0fe?v=34eba63a2800815891a3000c643f0ea8
+https://www.notion.so/acme/<database-id>?v=<view-id>
 ```
 
 Run one intake cycle against that database. The first eligible PRD in the configured `ready` status is claimed, validated, routed to either `blocked` (with clarifying comments) or `ticketed` (with destination tickets created), then the cycle exits. Remaining ready PRDs stay queued for later scheduler invocations.

package/plugins/lisa/skills/lisa-validate-tracker-mapping/SKILL.md

@@ -23,8 +23,8 @@ It is the audit/repair counterpart to `/lisa:setup:jira` (and the other `setup:*
 ## Arguments
 
 - (none) — audit the **current repo** (`./.lisa.config.json`).
-- `projects=<glob-or-path>` — batch sweep. Expands to every directory under the glob that contains a `.lisa.config.json`. Example: `projects=~/workspace/geminisportsai/projects/*`.
-- `workspaces=<file>` — batch sweep driven by a Lisa workspaces file (the `{ "<project-path>": "<branch>" }` map used by `/lisa:update-projects`). Each key is a project path to audit. Combine with `filter=<substring>` to restrict to matching paths (e.g. `filter=geminisportsai`).
+- `projects=<glob-or-path>` — batch sweep. Expands to every directory under the glob that contains a `.lisa.config.json`. Example: `projects=~/workspace/acme/projects/*`.
+- `workspaces=<file>` — batch sweep driven by a Lisa workspaces file (the `{ "<project-path>": "<branch>" }` map used by `/lisa:update-projects`). Each key is a project path to audit. Combine with `filter=<substring>` to restrict to matching paths (e.g. `filter=acme`).
 - `repair=true` — enable config repair (see confirmation policy). Default `false`.
 - `lane=build|prd|both` — which mapping family to check. Default `both`. `build` = the destination `tracker` workflow; `prd` = the PRD `source` status/label mapping.
 

package/plugins/lisa-agy/commands/lisa/validate-tracker-mapping.md

@@ -9,7 +9,7 @@ Common usage:
 
 - `/lisa:validate-tracker-mapping` — audit the current repo's mapping (read-only).
 - `/lisa:validate-tracker-mapping repair=true` — audit and repair config drift in the current repo.
-- `/lisa:validate-tracker-mapping projects=~/workspace/geminisportsai/projects/*` — sweep every Lisa project under a directory.
-- `/lisa:validate-tracker-mapping workspaces=~/workspace/lisa/.lisa.workspaces.json filter=geminisportsai` — sweep the projects in a workspaces file whose paths match a substring.
+- `/lisa:validate-tracker-mapping projects=~/workspace/acme/projects/*` — sweep every Lisa project under a directory.
+- `/lisa:validate-tracker-mapping workspaces=~/workspace/lisa/.lisa.workspaces.json filter=acme` — sweep the projects in a workspaces file whose paths match a substring.
 
 Use this when you suspect a JIRA/GitHub/Linear/Notion status, label, or option was renamed or deleted out from under Lisa — the failure mode that leaves builds unable to find their completion transition and items silently stuck. Run it read-only (or on a schedule) to detect drift; run it with `repair=true` to fix the config. Repair only ever edits the config to match the live names — it never renames anything in the tracker.

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/skills/lisa-atlassian-access/SKILL.md

@@ -282,7 +282,7 @@ Substrate column meanings:
 - Multiple cells filled means tier ordering applies — try acli, then MCP, then curl, taking the first that has an adapter for the op AND is identity-matched.
 - One cell means only that substrate can perform the op.
 
-`<SITE>` = `.atlassian.site` (e.g. `propswap.atlassian.net`). `<CLOUDID>` = `.atlassian.cloudId`. `<AUTH>` = `Basic $(printf '%s:%s' "$email" "$ATLASSIAN_API_TOKEN" | base64)`. JIRA curl writes use the cloudId-bound Atlassian gateway `https://api.atlassian.com/ex/jira/<CLOUDID>/rest/api/3/...`; JIRA curl reads may use either that gateway or `https://<SITE>/rest/api/3/...` after the token account check. Confluence uses `/wiki/rest/api/...` (v1) or `/api/v2/...` (v2).
+`<SITE>` = `.atlassian.site` (e.g. `acme.atlassian.net`). `<CLOUDID>` = `.atlassian.cloudId`. `<AUTH>` = `Basic $(printf '%s:%s' "$email" "$ATLASSIAN_API_TOKEN" | base64)`. JIRA curl writes use the cloudId-bound Atlassian gateway `https://api.atlassian.com/ex/jira/<CLOUDID>/rest/api/3/...`; JIRA curl reads may use either that gateway or `https://<SITE>/rest/api/3/...` after the token account check. Confluence uses `/wiki/rest/api/...` (v1) or `/api/v2/...` (v2).
 
 | Operation | acli adapter | MCP adapter | curl adapter |
 |---|---|---|---|

package/plugins/lisa-agy/skills/lisa-notion-prd-intake/SKILL.md

@@ -11,7 +11,7 @@ allowed-tools: ["Skill", "Bash", "Read", "Write", "Edit", "AskUserQuestion"]
 `$ARGUMENTS` is a Notion database URL (or bare database ID) — for example:
 
 ```text
-https://www.notion.so/geminisports/28fd00244d7d47c5866876f7de48c0fe?v=34eba63a2800815891a3000c643f0ea8
+https://www.notion.so/acme/<database-id>?v=<view-id>
 ```
 
 Run one intake cycle against that database. The first eligible PRD in the configured `ready` status is claimed, validated, routed to either `blocked` (with clarifying comments) or `ticketed` (with destination tickets created), then the cycle exits. Remaining ready PRDs stay queued for later scheduler invocations.

package/plugins/lisa-agy/skills/lisa-validate-tracker-mapping/SKILL.md

@@ -23,8 +23,8 @@ It is the audit/repair counterpart to `/lisa:setup:jira` (and the other `setup:*
 ## Arguments
 
 - (none) — audit the **current repo** (`./.lisa.config.json`).
-- `projects=<glob-or-path>` — batch sweep. Expands to every directory under the glob that contains a `.lisa.config.json`. Example: `projects=~/workspace/geminisportsai/projects/*`.
-- `workspaces=<file>` — batch sweep driven by a Lisa workspaces file (the `{ "<project-path>": "<branch>" }` map used by `/lisa:update-projects`). Each key is a project path to audit. Combine with `filter=<substring>` to restrict to matching paths (e.g. `filter=geminisportsai`).
+- `projects=<glob-or-path>` — batch sweep. Expands to every directory under the glob that contains a `.lisa.config.json`. Example: `projects=~/workspace/acme/projects/*`.
+- `workspaces=<file>` — batch sweep driven by a Lisa workspaces file (the `{ "<project-path>": "<branch>" }` map used by `/lisa:update-projects`). Each key is a project path to audit. Combine with `filter=<substring>` to restrict to matching paths (e.g. `filter=acme`).
 - `repair=true` — enable config repair (see confirmation policy). Default `false`.
 - `lane=build|prd|both` — which mapping family to check. Default `both`. `build` = the destination `tracker` workflow; `prd` = the PRD `source` status/label mapping.
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.195.2",
+  "version": "2.195.4",
   "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.195.2",
+  "version": "2.195.4",
   "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.195.2",
+  "version": "2.195.4",
   "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.195.2",
+  "version": "2.195.4",
   "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.195.2",
+  "version": "2.195.4",
   "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.195.2",
+  "version": "2.195.4",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-copilot/commands/lisa/validate-tracker-mapping.md

@@ -9,7 +9,7 @@ Common usage:
 
 - `/lisa:validate-tracker-mapping` — audit the current repo's mapping (read-only).
 - `/lisa:validate-tracker-mapping repair=true` — audit and repair config drift in the current repo.
-- `/lisa:validate-tracker-mapping projects=~/workspace/geminisportsai/projects/*` — sweep every Lisa project under a directory.
-- `/lisa:validate-tracker-mapping workspaces=~/workspace/lisa/.lisa.workspaces.json filter=geminisportsai` — sweep the projects in a workspaces file whose paths match a substring.
+- `/lisa:validate-tracker-mapping projects=~/workspace/acme/projects/*` — sweep every Lisa project under a directory.
+- `/lisa:validate-tracker-mapping workspaces=~/workspace/lisa/.lisa.workspaces.json filter=acme` — sweep the projects in a workspaces file whose paths match a substring.
 
 Use this when you suspect a JIRA/GitHub/Linear/Notion status, label, or option was renamed or deleted out from under Lisa — the failure mode that leaves builds unable to find their completion transition and items silently stuck. Run it read-only (or on a schedule) to detect drift; run it with `repair=true` to fix the config. Repair only ever edits the config to match the live names — it never renames anything in the tracker.

package/plugins/lisa-copilot/rules/reference/config-resolution.md

@@ -248,7 +248,7 @@ Each vendor section is **conditionally required**: required only when that vendo
 | Field | Required when | Where it lives | Notes |
 |-------|---------------|----------------|-------|
 | `atlassian.cloudId` | `tracker = "jira"`, `source = "jira"`, `source = "confluence"`, or any `confluence-*` / `jira-*` skill is invoked | **committed** (`.lisa.config.json`) | Atlassian Cloud site UUID. Same for every developer on the project. Resolve once via `curl https://<site>/_edge/tenant_info` or `getAccessibleAtlassianResources`. Shared between JIRA and Confluence (same Atlassian site). |
-| `atlassian.site` | same as above | **committed** | Human-readable site URL (e.g. `propswap.atlassian.net`). Same for every developer. |
+| `atlassian.site` | same as above | **committed** | Human-readable site URL (e.g. `acme.atlassian.net`). Same for every developer. |
 | `atlassian.email` | when the developer's machine has multiple Atlassian accounts that can access the configured site | **local** (`.lisa.config.local.json`) | Per-developer. `--site` alone cannot disambiguate which acli profile to switch to when two accounts both have access to the same site (e.g., a personal account and a work account both invited to a customer's site). The setup skill writes this to the local override file, NEVER the committed file. |
 
 #### `jira`

package/plugins/lisa-copilot/skills/lisa-atlassian-access/SKILL.md

@@ -282,7 +282,7 @@ Substrate column meanings:
 - Multiple cells filled means tier ordering applies — try acli, then MCP, then curl, taking the first that has an adapter for the op AND is identity-matched.
 - One cell means only that substrate can perform the op.
 
-`<SITE>` = `.atlassian.site` (e.g. `propswap.atlassian.net`). `<CLOUDID>` = `.atlassian.cloudId`. `<AUTH>` = `Basic $(printf '%s:%s' "$email" "$ATLASSIAN_API_TOKEN" | base64)`. JIRA curl writes use the cloudId-bound Atlassian gateway `https://api.atlassian.com/ex/jira/<CLOUDID>/rest/api/3/...`; JIRA curl reads may use either that gateway or `https://<SITE>/rest/api/3/...` after the token account check. Confluence uses `/wiki/rest/api/...` (v1) or `/api/v2/...` (v2).
+`<SITE>` = `.atlassian.site` (e.g. `acme.atlassian.net`). `<CLOUDID>` = `.atlassian.cloudId`. `<AUTH>` = `Basic $(printf '%s:%s' "$email" "$ATLASSIAN_API_TOKEN" | base64)`. JIRA curl writes use the cloudId-bound Atlassian gateway `https://api.atlassian.com/ex/jira/<CLOUDID>/rest/api/3/...`; JIRA curl reads may use either that gateway or `https://<SITE>/rest/api/3/...` after the token account check. Confluence uses `/wiki/rest/api/...` (v1) or `/api/v2/...` (v2).
 
 | Operation | acli adapter | MCP adapter | curl adapter |
 |---|---|---|---|

package/plugins/lisa-copilot/skills/lisa-notion-prd-intake/SKILL.md

@@ -11,7 +11,7 @@ allowed-tools: ["Skill", "Bash", "Read", "Write", "Edit", "AskUserQuestion"]
 `$ARGUMENTS` is a Notion database URL (or bare database ID) — for example:
 
 ```text
-https://www.notion.so/geminisports/28fd00244d7d47c5866876f7de48c0fe?v=34eba63a2800815891a3000c643f0ea8
+https://www.notion.so/acme/<database-id>?v=<view-id>
 ```
 
 Run one intake cycle against that database. The first eligible PRD in the configured `ready` status is claimed, validated, routed to either `blocked` (with clarifying comments) or `ticketed` (with destination tickets created), then the cycle exits. Remaining ready PRDs stay queued for later scheduler invocations.

package/plugins/lisa-copilot/skills/lisa-validate-tracker-mapping/SKILL.md

@@ -23,8 +23,8 @@ It is the audit/repair counterpart to `/lisa:setup:jira` (and the other `setup:*
 ## Arguments
 
 - (none) — audit the **current repo** (`./.lisa.config.json`).
-- `projects=<glob-or-path>` — batch sweep. Expands to every directory under the glob that contains a `.lisa.config.json`. Example: `projects=~/workspace/geminisportsai/projects/*`.
-- `workspaces=<file>` — batch sweep driven by a Lisa workspaces file (the `{ "<project-path>": "<branch>" }` map used by `/lisa:update-projects`). Each key is a project path to audit. Combine with `filter=<substring>` to restrict to matching paths (e.g. `filter=geminisportsai`).
+- `projects=<glob-or-path>` — batch sweep. Expands to every directory under the glob that contains a `.lisa.config.json`. Example: `projects=~/workspace/acme/projects/*`.
+- `workspaces=<file>` — batch sweep driven by a Lisa workspaces file (the `{ "<project-path>": "<branch>" }` map used by `/lisa:update-projects`). Each key is a project path to audit. Combine with `filter=<substring>` to restrict to matching paths (e.g. `filter=acme`).
 - `repair=true` — enable config repair (see confirmation policy). Default `false`.
 - `lane=build|prd|both` — which mapping family to check. Default `both`. `build` = the destination `tracker` workflow; `prd` = the PRD `source` status/label mapping.
 

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

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

package/plugins/lisa-cursor/commands/lisa/validate-tracker-mapping.md

@@ -9,7 +9,7 @@ Common usage:
 
 - `/lisa:validate-tracker-mapping` — audit the current repo's mapping (read-only).
 - `/lisa:validate-tracker-mapping repair=true` — audit and repair config drift in the current repo.
-- `/lisa:validate-tracker-mapping projects=~/workspace/geminisportsai/projects/*` — sweep every Lisa project under a directory.
-- `/lisa:validate-tracker-mapping workspaces=~/workspace/lisa/.lisa.workspaces.json filter=geminisportsai` — sweep the projects in a workspaces file whose paths match a substring.
+- `/lisa:validate-tracker-mapping projects=~/workspace/acme/projects/*` — sweep every Lisa project under a directory.
+- `/lisa:validate-tracker-mapping workspaces=~/workspace/lisa/.lisa.workspaces.json filter=acme` — sweep the projects in a workspaces file whose paths match a substring.
 
 Use this when you suspect a JIRA/GitHub/Linear/Notion status, label, or option was renamed or deleted out from under Lisa — the failure mode that leaves builds unable to find their completion transition and items silently stuck. Run it read-only (or on a schedule) to detect drift; run it with `repair=true` to fix the config. Repair only ever edits the config to match the live names — it never renames anything in the tracker.

package/plugins/lisa-cursor/rules/config-resolution-reference.mdc

@@ -253,7 +253,7 @@ Each vendor section is **conditionally required**: required only when that vendo
 | Field | Required when | Where it lives | Notes |
 |-------|---------------|----------------|-------|
 | `atlassian.cloudId` | `tracker = "jira"`, `source = "jira"`, `source = "confluence"`, or any `confluence-*` / `jira-*` skill is invoked | **committed** (`.lisa.config.json`) | Atlassian Cloud site UUID. Same for every developer on the project. Resolve once via `curl https://<site>/_edge/tenant_info` or `getAccessibleAtlassianResources`. Shared between JIRA and Confluence (same Atlassian site). |
-| `atlassian.site` | same as above | **committed** | Human-readable site URL (e.g. `propswap.atlassian.net`). Same for every developer. |
+| `atlassian.site` | same as above | **committed** | Human-readable site URL (e.g. `acme.atlassian.net`). Same for every developer. |
 | `atlassian.email` | when the developer's machine has multiple Atlassian accounts that can access the configured site | **local** (`.lisa.config.local.json`) | Per-developer. `--site` alone cannot disambiguate which acli profile to switch to when two accounts both have access to the same site (e.g., a personal account and a work account both invited to a customer's site). The setup skill writes this to the local override file, NEVER the committed file. |
 
 #### `jira`

package/plugins/lisa-cursor/skills/lisa-atlassian-access/SKILL.md

@@ -282,7 +282,7 @@ Substrate column meanings:
 - Multiple cells filled means tier ordering applies — try acli, then MCP, then curl, taking the first that has an adapter for the op AND is identity-matched.
 - One cell means only that substrate can perform the op.
 
-`<SITE>` = `.atlassian.site` (e.g. `propswap.atlassian.net`). `<CLOUDID>` = `.atlassian.cloudId`. `<AUTH>` = `Basic $(printf '%s:%s' "$email" "$ATLASSIAN_API_TOKEN" | base64)`. JIRA curl writes use the cloudId-bound Atlassian gateway `https://api.atlassian.com/ex/jira/<CLOUDID>/rest/api/3/...`; JIRA curl reads may use either that gateway or `https://<SITE>/rest/api/3/...` after the token account check. Confluence uses `/wiki/rest/api/...` (v1) or `/api/v2/...` (v2).
+`<SITE>` = `.atlassian.site` (e.g. `acme.atlassian.net`). `<CLOUDID>` = `.atlassian.cloudId`. `<AUTH>` = `Basic $(printf '%s:%s' "$email" "$ATLASSIAN_API_TOKEN" | base64)`. JIRA curl writes use the cloudId-bound Atlassian gateway `https://api.atlassian.com/ex/jira/<CLOUDID>/rest/api/3/...`; JIRA curl reads may use either that gateway or `https://<SITE>/rest/api/3/...` after the token account check. Confluence uses `/wiki/rest/api/...` (v1) or `/api/v2/...` (v2).
 
 | Operation | acli adapter | MCP adapter | curl adapter |
 |---|---|---|---|

package/plugins/lisa-cursor/skills/lisa-notion-prd-intake/SKILL.md

@@ -11,7 +11,7 @@ allowed-tools: ["Skill", "Bash", "Read", "Write", "Edit", "AskUserQuestion"]
 `$ARGUMENTS` is a Notion database URL (or bare database ID) — for example:
 
 ```text
-https://www.notion.so/geminisports/28fd00244d7d47c5866876f7de48c0fe?v=34eba63a2800815891a3000c643f0ea8
+https://www.notion.so/acme/<database-id>?v=<view-id>
 ```
 
 Run one intake cycle against that database. The first eligible PRD in the configured `ready` status is claimed, validated, routed to either `blocked` (with clarifying comments) or `ticketed` (with destination tickets created), then the cycle exits. Remaining ready PRDs stay queued for later scheduler invocations.

package/plugins/lisa-cursor/skills/lisa-validate-tracker-mapping/SKILL.md

@@ -23,8 +23,8 @@ It is the audit/repair counterpart to `/lisa:setup:jira` (and the other `setup:*
 ## Arguments
 
 - (none) — audit the **current repo** (`./.lisa.config.json`).
-- `projects=<glob-or-path>` — batch sweep. Expands to every directory under the glob that contains a `.lisa.config.json`. Example: `projects=~/workspace/geminisportsai/projects/*`.
-- `workspaces=<file>` — batch sweep driven by a Lisa workspaces file (the `{ "<project-path>": "<branch>" }` map used by `/lisa:update-projects`). Each key is a project path to audit. Combine with `filter=<substring>` to restrict to matching paths (e.g. `filter=geminisportsai`).
+- `projects=<glob-or-path>` — batch sweep. Expands to every directory under the glob that contains a `.lisa.config.json`. Example: `projects=~/workspace/acme/projects/*`.
+- `workspaces=<file>` — batch sweep driven by a Lisa workspaces file (the `{ "<project-path>": "<branch>" }` map used by `/lisa:update-projects`). Each key is a project path to audit. Combine with `filter=<substring>` to restrict to matching paths (e.g. `filter=acme`).
 - `repair=true` — enable config repair (see confirmation policy). Default `false`.
 - `lane=build|prd|both` — which mapping family to check. Default `both`. `build` = the destination `tracker` workflow; `prd` = the PRD `source` status/label mapping.
 

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

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

package/plugins/lisa-expo/.mcp.json

@@ -3,10 +3,6 @@
     "expo": {
       "type": "http",
       "url": "https://mcp.expo.dev/mcp"
-    },
-    "maestro": {
-      "command": "maestro",
-      "args": ["mcp"]
     }
   }
 }

package/plugins/lisa-expo/THIRD-PARTY-NOTICES.md

@@ -30,12 +30,20 @@ The accompanying `expo` MCP server in `.mcp.json` points at Expo's official
 remote server (`https://mcp.expo.dev/mcp`), replacing the previously bundled
 third-party `expo-local-docs-mcp` stdio server.
 
-The `maestro` MCP server in `.mcp.json` runs the official Maestro CLI's
-built-in MCP server (`maestro mcp`, STDIO) — nothing is bundled; it requires
-the host machine's own Maestro CLI (with a Java runtime) and exposes device
-automation tools (list_devices, inspect_screen, take_screenshot, run flows,
-cheat_sheet, and Maestro Cloud variants) to coding agents. Servers whose CLI
-is absent simply fail to start without affecting the rest of the plugin.
+The Maestro CLI's built-in MCP server (`maestro mcp`, STDIO) is intentionally
+NOT registered in `.mcp.json`. Coding agents spawn stdio servers with a
+non-login PATH, so an always-on entry fails visibly (Claude Code shows a
+"Failed to reconnect … -32000" error every session) on any machine missing the
+Maestro CLI or a resolvable Java runtime — which is most of the fleet. Opt in
+per machine instead, e.g.:
+
+```
+claude mcp add --scope local maestro -- maestro mcp
+```
+
+ensuring `maestro` and a Java runtime are on the non-interactive PATH (mise
+users: `claude mcp add --scope local maestro -- mise exec java -- maestro mcp`
+from a directory where Java is active).
 
 ### MIT License
 

package/plugins/lisa-expo/skills/atomic-design-gluestack/references/folder-structure.md

@@ -3,7 +3,7 @@
 ## Complete Directory Structure
 
 ```
-thumbwar-frontend/
+acme-frontend/
 ├── app/                                    # Expo Router - PAGES live here
 │   ├── (auth)/                            # Auth route group
 │   │   ├── login.tsx                      # Login page

package/plugins/lisa-expo-agy/THIRD-PARTY-NOTICES.md

@@ -30,12 +30,20 @@ The accompanying `expo` MCP server in `.mcp.json` points at Expo's official
 remote server (`https://mcp.expo.dev/mcp`), replacing the previously bundled
 third-party `expo-local-docs-mcp` stdio server.
 
-The `maestro` MCP server in `.mcp.json` runs the official Maestro CLI's
-built-in MCP server (`maestro mcp`, STDIO) — nothing is bundled; it requires
-the host machine's own Maestro CLI (with a Java runtime) and exposes device
-automation tools (list_devices, inspect_screen, take_screenshot, run flows,
-cheat_sheet, and Maestro Cloud variants) to coding agents. Servers whose CLI
-is absent simply fail to start without affecting the rest of the plugin.
+The Maestro CLI's built-in MCP server (`maestro mcp`, STDIO) is intentionally
+NOT registered in `.mcp.json`. Coding agents spawn stdio servers with a
+non-login PATH, so an always-on entry fails visibly (Claude Code shows a
+"Failed to reconnect … -32000" error every session) on any machine missing the
+Maestro CLI or a resolvable Java runtime — which is most of the fleet. Opt in
+per machine instead, e.g.:
+
+```
+claude mcp add --scope local maestro -- maestro mcp
+```
+
+ensuring `maestro` and a Java runtime are on the non-interactive PATH (mise
+users: `claude mcp add --scope local maestro -- mise exec java -- maestro mcp`
+from a directory where Java is active).
 
 ### MIT License
 

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

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

package/plugins/lisa-expo-agy/skills/atomic-design-gluestack/references/folder-structure.md

@@ -3,7 +3,7 @@
 ## Complete Directory Structure
 
 ```
-thumbwar-frontend/
+acme-frontend/
 ├── app/                                    # Expo Router - PAGES live here
 │   ├── (auth)/                            # Auth route group
 │   │   ├── login.tsx                      # Login page

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.195.2",
+  "version": "2.195.4",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"
@@ -12,12 +12,6 @@
     "expo": {
       "type": "http",
       "url": "https://mcp.expo.dev/mcp"
-    },
-    "maestro": {
-      "command": "maestro",
-      "args": [
-        "mcp"
-      ]
     }
   }
 }

package/plugins/lisa-expo-copilot/.mcp.json

@@ -3,10 +3,6 @@
     "expo": {
       "type": "http",
       "url": "https://mcp.expo.dev/mcp"
-    },
-    "maestro": {
-      "command": "maestro",
-      "args": ["mcp"]
     }
   }
 }

package/plugins/lisa-expo-copilot/THIRD-PARTY-NOTICES.md

@@ -30,12 +30,20 @@ The accompanying `expo` MCP server in `.mcp.json` points at Expo's official
 remote server (`https://mcp.expo.dev/mcp`), replacing the previously bundled
 third-party `expo-local-docs-mcp` stdio server.
 
-The `maestro` MCP server in `.mcp.json` runs the official Maestro CLI's
-built-in MCP server (`maestro mcp`, STDIO) — nothing is bundled; it requires
-the host machine's own Maestro CLI (with a Java runtime) and exposes device
-automation tools (list_devices, inspect_screen, take_screenshot, run flows,
-cheat_sheet, and Maestro Cloud variants) to coding agents. Servers whose CLI
-is absent simply fail to start without affecting the rest of the plugin.
+The Maestro CLI's built-in MCP server (`maestro mcp`, STDIO) is intentionally
+NOT registered in `.mcp.json`. Coding agents spawn stdio servers with a
+non-login PATH, so an always-on entry fails visibly (Claude Code shows a
+"Failed to reconnect … -32000" error every session) on any machine missing the
+Maestro CLI or a resolvable Java runtime — which is most of the fleet. Opt in
+per machine instead, e.g.:
+
+```
+claude mcp add --scope local maestro -- maestro mcp
+```
+
+ensuring `maestro` and a Java runtime are on the non-interactive PATH (mise
+users: `claude mcp add --scope local maestro -- mise exec java -- maestro mcp`
+from a directory where Java is active).
 
 ### MIT License
 

package/plugins/lisa-expo-copilot/skills/atomic-design-gluestack/references/folder-structure.md

@@ -3,7 +3,7 @@
 ## Complete Directory Structure
 
 ```
-thumbwar-frontend/
+acme-frontend/
 ├── app/                                    # Expo Router - PAGES live here
 │   ├── (auth)/                            # Auth route group
 │   │   ├── login.tsx                      # Login page

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

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

package/plugins/lisa-expo-cursor/THIRD-PARTY-NOTICES.md

@@ -30,12 +30,20 @@ The accompanying `expo` MCP server in `.mcp.json` points at Expo's official
 remote server (`https://mcp.expo.dev/mcp`), replacing the previously bundled
 third-party `expo-local-docs-mcp` stdio server.
 
-The `maestro` MCP server in `.mcp.json` runs the official Maestro CLI's
-built-in MCP server (`maestro mcp`, STDIO) — nothing is bundled; it requires
-the host machine's own Maestro CLI (with a Java runtime) and exposes device
-automation tools (list_devices, inspect_screen, take_screenshot, run flows,
-cheat_sheet, and Maestro Cloud variants) to coding agents. Servers whose CLI
-is absent simply fail to start without affecting the rest of the plugin.
+The Maestro CLI's built-in MCP server (`maestro mcp`, STDIO) is intentionally
+NOT registered in `.mcp.json`. Coding agents spawn stdio servers with a
+non-login PATH, so an always-on entry fails visibly (Claude Code shows a
+"Failed to reconnect … -32000" error every session) on any machine missing the
+Maestro CLI or a resolvable Java runtime — which is most of the fleet. Opt in
+per machine instead, e.g.:
+
+```
+claude mcp add --scope local maestro -- maestro mcp
+```
+
+ensuring `maestro` and a Java runtime are on the non-interactive PATH (mise
+users: `claude mcp add --scope local maestro -- mise exec java -- maestro mcp`
+from a directory where Java is active).
 
 ### MIT License
 

package/plugins/lisa-expo-cursor/mcp.json

@@ -3,10 +3,6 @@
     "expo": {
       "type": "http",
       "url": "https://mcp.expo.dev/mcp"
-    },
-    "maestro": {
-      "command": "maestro",
-      "args": ["mcp"]
     }
   }
 }

package/plugins/lisa-expo-cursor/skills/atomic-design-gluestack/references/folder-structure.md

@@ -3,7 +3,7 @@
 ## Complete Directory Structure
 
 ```
-thumbwar-frontend/
+acme-frontend/
 ├── app/                                    # Expo Router - PAGES live here
 │   ├── (auth)/                            # Auth route group
 │   │   ├── login.tsx                      # Login page

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

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