@codyswann/lisa 4.74.9 → 4.75.0

package/plugins/lisa-devin/skills/lisa-wiki-install/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: lisa-wiki-install
+description: "Bootstrap the LLM Wiki kernel (lisa-wiki plugin) in a host project. Solves the chicken-and-egg gap: the base lisa plugin can install the wiki plugin so its setup skill becomes discoverable. Edits .claude/settings.json to enable lisa-wiki@lisa and confirm the CodySwannGT/lisa marketplace, then for Codex verifies whether the .codex/skills/lisa overlay already carries lisa-wiki-* skills (printed by Lisa's apply) and nudges the user to refresh the overlay if missing. Idempotent. Never auto-runs `lisa apply`. After this skill, reload the runtime and run /setup:wiki (Claude) or $lisa-wiki-setup (Codex) to scaffold the wiki itself."
+allowed-tools: ["Bash", "Read", "Write", "Edit"]
+---
+
+# Install the LLM Wiki kernel
+
+This skill makes the `lisa-wiki` plugin visible in the current project so its scaffolder (`/setup:wiki` / `$lisa-wiki-setup`) can run. It does **not** scaffold the wiki itself — that is the wiki plugin's job. This skill only flips the install bit and verifies the Codex overlay carries the kernel.
+
+## Why this skill exists
+
+`lisa-wiki` is published as `AVAILABLE` (not `INSTALLED_BY_DEFAULT`) in Lisa's marketplace. A downstream project that never enabled it has no way to discover the wiki's setup command — a chicken-and-egg bootstrap gap. Because the base `lisa` plugin is auto-enabled everywhere, putting the bootstrap here is what makes the wiki reachable.
+
+## Asymmetry note
+
+The two runtimes work differently:
+
+- **Claude Code** loads plugin skills per-project through `.claude/settings.json` `enabledPlugins`. The wiki skills are invisible until `lisa-wiki@lisa` is enabled there. This skill makes that edit.
+- **Codex** loads Lisa skills through an overlay path (`src/codex/skills-installer.ts` runs from `Lisa.apply()` and copies every built `plugins/<p>/skills/<n>/` into `.codex/skills/lisa/`). Wiki skills land in that overlay automatically every time the project re-applies Lisa. This skill does not mutate Codex config — it only checks whether the overlay carries `lisa-wiki-setup` and tells the user how to refresh if missing.
+
+## Workflow
+
+### Step 1 — Verify we are in a project, not Lisa itself
+
+```bash
+cwd="$(pwd)"
+if [ -f "$cwd/.lisa-source" ] || { [ -d "$cwd/plugins/src/base" ] && [ -f "$cwd/.claude-plugin/marketplace.json" ]; }; then
+  echo "This is the Lisa monorepo itself — the base plugin's wiki kernel already lives here."
+  echo "Run /setup:wiki to scaffold a wiki, or invoke this skill from inside a downstream project."
+  exit 0
+fi
+```
+
+### Step 2 — Enable lisa-wiki@lisa in the Claude project settings
+
+Read `<cwd>/.claude/settings.json` (create with `{}` if absent). Then, using the **Edit** or **Write** tool with valid JSON (not jq one-liners that risk corrupting comments / formatting):
+
+1. Ensure `enabledPlugins` is an object.
+2. Set `enabledPlugins["lisa-wiki@lisa"] = true`.
+3. Ensure `extraKnownMarketplaces` is an object containing the entry below if it is not already present (do **not** overwrite an existing entry):
+
+   ```json
+   "CodySwannGT/lisa": {
+     "source": {
+       "source": "github",
+       "repo": "CodySwannGT/lisa"
+     }
+   }
+   ```
+
+4. Pretty-print the file with 2-space indentation and a trailing newline.
+
+If `enabledPlugins["lisa-wiki@lisa"]` was already `true`, log "Claude: lisa-wiki@lisa already enabled — no change." If not, log "Claude: enabled lisa-wiki@lisa in .claude/settings.json."
+
+**Do not** edit `.claude/settings.local.json` — that file is per-user and is not the right surface for a project-level enablement.
+
+### Step 3 — Verify the Codex overlay carries lisa-wiki
+
+```bash
+codex_wiki_setup=".codex/skills/lisa/lisa-wiki-setup/SKILL.md"
+if [ -f "$codex_wiki_setup" ]; then
+  echo "Codex: lisa-wiki overlay already present (found $codex_wiki_setup). Nothing to do for Codex."
+else
+  echo "Codex: lisa-wiki skills not found in .codex/skills/lisa/."
+  if [ -d ".agents" ] || [ -d ".codex" ]; then
+    echo "  → This project appears Codex-wired but its overlay is stale or predates lisa-wiki."
+    echo "  → Refresh it by running your project's Lisa apply command, e.g.:"
+    echo "       npx lisa --harness=codex ."
+    echo "    (or whatever shape your project uses to apply Lisa for Codex)."
+  else
+    echo "  → This project does not have a Codex installation yet (no .agents/ or .codex/). Skip if Codex parity is not needed."
+  fi
+fi
+```
+
+**Do not** invoke `lisa apply` automatically. `lisa apply` rewrites more than the wiki overlay; it must remain the user's explicit choice.
+
+### Step 4 — Hand off
+
+Print:
+
+```
+Wiki kernel install complete.
+
+Next steps:
+  • Reload your runtime so it picks up the newly-enabled plugin (Claude: /reload or restart the session; Codex: restart `codex`).
+  • Then run /setup:wiki (Claude) or $lisa-wiki-setup (Codex) to scaffold wiki/ in this project.
+```
+
+## Rules
+
+- Idempotent. Re-running produces no spurious changes once both flags are set.
+- Project-scoped only. Never touch `~/.codex/config.toml` or any user-global config.
+- Never run `lisa apply` on the user's behalf.
+- Never edit `.claude/settings.local.json` — it is user-scoped overrides.
+- Preserve human-authored content. Only flip the enablement key and add the marketplace entry if missing.
+
+## Related
+
+`lisa-wiki-setup` (the actual scaffolder, lives in the `lisa-wiki` plugin once enabled), `lisa-wiki-doctor`, `lisa-wiki-usage`.

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

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

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

@@ -0,0 +1,11 @@
+{
+  "name": "lisa-expo",
+  "version": "4.75.0",
+  "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
+  "author": {
+    "name": "Cody Swann"
+  },
+  "dependencies": [
+    "lisa-typescript"
+  ]
+}

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

@@ -0,0 +1,8 @@
+{
+  "name": "lisa-expo",
+  "version": "4.75.0",
+  "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
+  "author": {
+    "name": "Cody Swann"
+  }
+}

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

@@ -0,0 +1,8 @@
+{
+  "mcpServers": {
+    "expo": {
+      "type": "http",
+      "url": "https://mcp.expo.dev/mcp"
+    }
+  }
+}

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

@@ -0,0 +1,84 @@
+# Third-Party Notices
+
+## Official Expo skills (vendored)
+
+The following skills under `skills/` are vendored verbatim from Expo's official
+plugin and are **not** Lisa-authored. Do not hand-edit them; re-vendor from
+upstream to update.
+
+- **Source:** https://github.com/expo/skills (`plugins/expo/skills/`)
+- **Upstream commit:** `510373b50956ef4dc84c20bb4c9cce70b618aa06`
+- **License:** MIT — Copyright (c) 2025-present 650 Industries, Inc. (aka Expo)
+
+Vendored skills:
+
+```
+add-app-clip            expo-cicd-workflows     expo-ui-jetpack-compose
+building-native-ui      expo-deployment         expo-ui-swift-ui
+eas-update-insights     expo-dev-client         native-data-fetching
+expo-api-routes         expo-module             upgrading-expo
+expo-brownfield         expo-tailwind-setup     use-dom
+```
+
+These ship alongside Lisa's own opinionated Expo/React Native skills
+(`apollo-client`, `gluestack-nativewind`, `container-view-pattern`, etc.), which
+they complement rather than replace. Notably both `expo-tailwind-setup`
+(Tailwind v4 / NativeWind v5) and Lisa's `gluestack-nativewind` (Gluestack v3 /
+NativeWind v4) are kept intentionally; choose per project.
+
+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 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.
+
+The supported path is the **`/lisa-expo:maestro-mcp-setup`** skill (Codex:
+`$maestro-mcp-setup`), which detects the Maestro CLI and a usable Java runtime,
+installs or guides whatever is missing, and registers `maestro mcp` at
+**local/per-machine scope** with an absolute command path and injected
+`JAVA_HOME`/`PATH` — so the spawn works even under a non-login PATH.
+
+To register by hand instead, keep it at local scope and inject the toolchain,
+e.g.:
+
+```
+# Resolve a real JAVA_HOME from the JVM (robust when `java` is a shim/symlink):
+JAVA_HOME="$(java -XshowSettings:properties -version 2>&1 | sed -n 's/^[[:space:]]*java\.home = //p' | head -n1)"
+claude mcp add --scope local maestro \
+  --env "JAVA_HOME=$JAVA_HOME" --env "PATH=$JAVA_HOME/bin:$HOME/.maestro/bin:$PATH" \
+  -- "$HOME/.maestro/bin/maestro" mcp
+```
+
+Never register at `--scope project` / a committed `.mcp.json` — that is the
+always-on form that reds out every other machine in the fleet.
+
+### MIT License
+
+```
+The MIT License (MIT)
+
+Copyright (c) 2025-present 650 Industries, Inc. (aka Expo)
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+```

package/plugins/lisa-expo-devin/agents/ops-specialist.md

@@ -0,0 +1,124 @@
+---
+name: ops-specialist
+description: Operations specialist agent for Expo + serverless backend projects. Runs the full stack locally, deploys frontend (EAS) and backend (Serverless), checks logs (local, browser, device, CloudWatch), monitors errors (Sentry), runs browser UAT via Playwright MCP tools, manages database migrations, and performs performance analysis. Self-contained with all operational knowledge.
+tools: Read, Grep, Glob, Bash
+skills:
+  - ops-run-local
+  - ops-deploy
+  - ops-check-logs
+  - ops-verify-health
+  - ops-browser-uat
+  - ops-db-ops
+  - ops-monitor-errors
+  - ops-performance
+---
+
+# Ops Specialist Agent
+
+You are an operations specialist for an Expo + serverless backend application. Your mission is to **run, monitor, deploy, debug, and UAT the application** across local and remote environments. You operate with full operational knowledge embedded in this prompt — you do not need to search for setup instructions.
+
+## Architecture Summary
+
+| Layer | Stack | Key Tech |
+|-------|-------|----------|
+| Frontend | Expo (React Native for Web, iOS, Android) | bun, Apollo Client, Expo Router |
+| Backend | NestJS (Serverless Framework on AWS Lambda) | TypeORM, PostgreSQL, Cognito, Redis, GraphQL |
+| Auth | AWS Cognito | Phone + OTP flow |
+| CI/CD | GitHub Actions | EAS Update (OTA), Serverless deploy |
+| Monitoring | Sentry | Frontend + Backend projects |
+
+## Repository Paths
+
+- **Frontend**: The current project directory (this repo). Use `.` or `$CLAUDE_PROJECT_DIR` in commands.
+- **Backend**: Resolved via the `BACKEND_DIR` environment variable. Defaults to `../backend-v2` (sibling directory convention).
+
+### Path Resolution
+
+All skills use `${BACKEND_DIR:-../backend-v2}` in bash commands. This means:
+- If `BACKEND_DIR` is set, use that path.
+- Otherwise, assume the backend repo is at `../backend-v2` relative to the frontend root.
+
+### Developer Setup
+
+Each developer sets their backend path in `.claude/settings.local.json` (gitignored):
+
+```json
+{
+  "env": {
+    "BACKEND_DIR": "/path/to/your/backend"
+  }
+}
+```
+
+If the backend is a sibling directory named `backend-v2`, no configuration is needed — the default works.
+
+## Project Discovery
+
+On first invocation, discover project-specific values by reading these files:
+
+| Value | Source File | How to Extract |
+|-------|------------|----------------|
+| Environment URLs | `.env.localhost`, `.env.development`, `.env.staging`, `.env.production` | `EXPO_PUBLIC_GRAPHQL_BASE_URL` for backend; frontend URLs from `e2e/constants.ts` |
+| Test credentials | `e2e/constants.ts` | `PHONE_NUMBER` and `OTP` exports |
+| UI selectors | `e2e/selectors.ts` | `selectors` object with all `data-testid` values |
+| Login flow | `e2e/fixtures/auth.fixture.ts` | `createAuthFixture` function with step-by-step login |
+| AWS profiles | Backend `package.json` | Scripts matching `aws:signin:*` pattern |
+| Lambda functions | Backend `package.json` | Scripts matching `logs:*` and `deploy:function:*` patterns |
+| Deploy commands | Backend `package.json` | Scripts matching `deploy:*` pattern |
+| Migration commands | Backend `package.json` | Scripts matching `migration:*` pattern |
+| Sentry config | Frontend `package.json` | `@sentry/react-native` dependency; org/project from `.sentryclirc` or Sentry DSN in `.env.*` |
+| Frontend scripts | Frontend `package.json` | All available `scripts` |
+
+## App Routes
+
+Discover routes from the `app/` directory (Expo Router file-based routing):
+
+| Route | Purpose |
+|-------|---------|
+| `/signin` | Login page |
+| `/confirm-code` | OTP entry |
+| `/` | Home screen |
+
+Read `app/` directory structure to discover all available routes.
+
+## Skills Reference
+
+| Skill | Purpose |
+|-------|---------|
+| `ops-run-local` | Start, stop, restart, or check status of local dev environment |
+| `ops-deploy` | Deploy frontend (EAS) or backend (Serverless) to any environment |
+| `ops-check-logs` | View local, browser, device, or remote CloudWatch logs |
+| `ops-verify-health` | Health check all services across environments |
+| `ops-browser-uat` | Browser-based UAT via Playwright MCP tools |
+| `ops-db-ops` | Database migrations, reverts, schema generation, GraphQL codegen |
+| `ops-monitor-errors` | Monitor Sentry for unresolved errors |
+| `ops-performance` | Lighthouse audits, bundle analysis, k6 load tests |
+
+## Troubleshooting Quick Reference
+
+| Problem | Likely Cause | Fix |
+|---------|-------------|-----|
+| `port 8081 already in use` | Previous Metro bundler running | `lsof -ti :8081 \| xargs kill -9` |
+| `port 3000 already in use` | Previous backend running | `lsof -ti :3000 \| xargs kill -9` |
+| `ExpiredTokenException` | AWS credentials expired | Interactive local: refresh the backend AWS signin flow. Headless: use the environment-backed AWS profile; do not start an SSO browser/device flow |
+| Metro bundler crash | Cache corruption | `bun start:local --clear` |
+| `ECONNREFUSED localhost:3000` | Backend not running | Start backend first, then frontend |
+| Migration fails | Missing AWS credentials | Verify `aws sts get-caller-identity --profile {profile}`; use interactive signin only locally, environment-backed profile headless |
+| EAS CLI not found | Not installed globally | `npm install -g eas-cli` |
+| `sls` not found | Serverless not installed | `cd $BACKEND_DIR && bun install` |
+| GraphQL schema mismatch | Stale generated types | Run `generate:types:{env}` script |
+| `BACKEND_DIR` not set | Missing env config | Set in `.claude/settings.local.json` or use default `../backend-v2` |
+
+## Rules
+
+- Always verify empirically — never assume something works because the code looks correct
+- Always discover project-specific values from source files before operations
+- Always check prerequisites (ports, AWS credentials, running services) before operations
+- Always resolve `$BACKEND_DIR` before running backend commands — verify the directory exists
+- Never deploy to production without explicit human confirmation
+- Never run destructive database operations without explicit human confirmation
+- Always use test credentials from `e2e/constants.ts` for browser automation
+- Always use the correct `--profile` and `--region` for AWS CLI commands (discover from backend scripts)
+- Always start backend before frontend for full-stack local development
+- Always take screenshots at verification points during browser UAT
+- Always report results in structured tables

package/plugins/lisa-expo-devin/hooks/devin-tool-name-shim.sh

@@ -0,0 +1,30 @@
+#!/bin/sh
+# Generated by scripts/generate-devin-plugin-artifacts.mjs — do not edit.
+#
+# Devin CLI names its tools in lowercase (exec, write, edit, read, ...) while
+# Lisa's guards test Claude's names (Bash, Write, Edit, Read, ...). The field
+# names inside tool_input already match, so translating tool_name is enough
+# for an unchanged guard to evaluate a Devin tool call (CodySwannGT/lisa#4426).
+#
+# Usage: devin-tool-name-shim.sh <hook command> [args...]
+payload=$(cat)
+normalized=$payload
+if command -v jq >/dev/null 2>&1; then
+  mapped=$(printf '%s' "$payload" | jq -c '
+    if (.tool_name | type) == "string" then
+      .tool_name |= ({
+        "exec": "Bash",
+        "write": "Write",
+        "edit": "Edit",
+        "read": "Read",
+        "notebook_edit": "NotebookEdit",
+        "grep": "Grep",
+        "glob": "Glob",
+        "webfetch": "WebFetch",
+        "run_subagent": "Task",
+        "skill": "Skill",
+        "todo_write": "TodoWrite"
+      }[.] // .)
+    else . end' 2>/dev/null) && [ -n "$mapped" ] && normalized=$mapped
+fi
+printf '%s' "$normalized" | "$@"

package/plugins/lisa-expo-devin/hooks/register-maestro-mcp.sh

@@ -0,0 +1,84 @@
+#!/usr/bin/env bash
+##
+# SessionStart hook: register the Maestro MCP server for THIS machine — but only
+# when the toolchain is already present.
+#
+# The Maestro stdio server is intentionally NOT in the distributed .mcp.json: an
+# always-on entry reds out ("Failed to reconnect ... -32000") every session on
+# any machine lacking the Maestro CLI or a login-PATH Java runtime (see
+# THIRD-PARTY-NOTICES and the expo plugin history b12d5d3 -> b1f3efd, where the
+# always-on entry broke the whole fleet). This hook is the SAFE inverse: it
+# registers at LOCAL scope, with an ABSOLUTE command path and injected
+# JAVA_HOME/PATH, ONLY when both `maestro` and a usable `java` resolve — and
+# stays completely silent otherwise. Machines without the toolchain are never
+# touched, so they never red. The registration takes effect on the NEXT session
+# (MCP servers connect at startup), exactly like the other setup hooks.
+#
+# Fast + idempotent: unequipped machines (most of the fleet) exit after a couple
+# of `command -v` probes; equipped machines re-register only if not already set.
+#
+# Parity note: this auto-register hook is Claude-specific — it uses SessionStart
+# semantics and the `claude mcp add` verb. Other harnesses (Codex, Cursor,
+# OpenCode, Antigravity, Copilot) enable Maestro MCP via the vendor-agnostic
+# `maestro-mcp-setup` skill, which registers the same absolute-command +
+# injected-env server at each agent's local/user scope. Extending automatic
+# registration to those agents' native session hooks is deliberate follow-up, not
+# a silent drop.
+##
+
+set -euo pipefail
+
+# Drain the hook envelope so the caller's pipe closes cleanly.
+cat >/dev/null 2>&1 || true
+
+# A hook must never interrupt the session; swallow any unexpected failure.
+trap 'exit 0' ERR
+
+# Need the Claude CLI to register at all.
+command -v claude >/dev/null 2>&1 || exit 0
+
+# 1. Resolve the Maestro CLI to an ABSOLUTE path (a bare `maestro` relies on the
+#    very PATH that is missing when the agent spawns the stdio server).
+MAESTRO_BIN="$(command -v maestro 2>/dev/null || true)"
+if [ -z "${MAESTRO_BIN}" ] && [ -x "${HOME}/.maestro/bin/maestro" ]; then
+  MAESTRO_BIN="${HOME}/.maestro/bin/maestro"
+fi
+[ -n "${MAESTRO_BIN}" ] || exit 0 # CLI absent -> stay silent, never register.
+
+# 2. Resolve a usable Java, honoring the project's version manager before any
+#    ambient java. No Java -> stay silent (the spawn would die without it).
+JAVA_BIN=""
+if command -v mise >/dev/null 2>&1 && JAVA_BIN="$(mise which java 2>/dev/null)"; then
+  :
+elif command -v asdf >/dev/null 2>&1 && JAVA_BIN="$(asdf which java 2>/dev/null)"; then
+  :
+elif [ -x "${SDKMAN_DIR:-${HOME}/.sdkman}/candidates/java/current/bin/java" ]; then
+  # SDKMAN's `sdk` is a shell function absent here; use its stable symlink.
+  JAVA_BIN="${SDKMAN_DIR:-${HOME}/.sdkman}/candidates/java/current/bin/java"
+elif command -v java >/dev/null 2>&1; then
+  JAVA_BIN="$(command -v java)"
+fi
+[ -n "${JAVA_BIN}" ] && [ -x "${JAVA_BIN}" ] || exit 0
+
+# Derive JAVA_HOME from the JVM itself, robust when `java` is a shim/symlink whose
+# parent is not a JDK root; fall back to bin/.. only if the query yields nothing.
+JAVA_HOME_DIR="$("${JAVA_BIN}" -XshowSettings:properties -version 2>&1 \
+  | sed -n 's/^[[:space:]]*java\.home = //p' | head -n 1)"
+if [ -z "${JAVA_HOME_DIR}" ] || [ ! -x "${JAVA_HOME_DIR}/bin/java" ]; then
+  JAVA_HOME_DIR="$(cd "$(dirname "${JAVA_BIN}")/.." && pwd)"
+fi
+JBIN_DIR="${JAVA_HOME_DIR}/bin"
+MBIN_DIR="$(dirname "${MAESTRO_BIN}")"
+
+# 3. Already registered (any scope)? Nothing to do.
+claude mcp get maestro >/dev/null 2>&1 && exit 0
+
+# 4. Register at LOCAL scope (per-machine, uncommitted) with the absolute command
+#    and injected toolchain env, so the stdio spawn finds Java regardless of the
+#    inherited PATH. Failure is non-fatal and silent.
+claude mcp add --scope local maestro \
+  --env "JAVA_HOME=${JAVA_HOME_DIR}" \
+  --env "PATH=${JBIN_DIR}:${MBIN_DIR}:${PATH}" \
+  -- "${MAESTRO_BIN}" mcp >/dev/null 2>&1 || true
+
+exit 0

package/plugins/lisa-expo-devin/hooks.json

@@ -0,0 +1,14 @@
+{
+  "hooks": {
+    "SessionStart": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/devin-tool-name-shim.sh ${CLAUDE_PLUGIN_ROOT}/hooks/register-maestro-mcp.sh"
+          }
+        ]
+      }
+    ]
+  }
+}