@codyswann/lisa 2.123.2 → 2.124.0

package/plugins/lisa-agy/skills/generate-claude-remote-build-script/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: generate-claude-remote-build-script
+description: "Generate the setup/build script (and env-var template) to paste into a Claude Code remote routine environment so this repo runs in the cloud. Runs /lisa:analyze-claude-remote to inventory needs, then writes an idempotent, detect-before-install bash script that installs the required CLIs/binaries and package manager for both Lisa and the host project, plus a commented environment-variable template (names only, never real secrets) and a list of custom domains to allowlist. The script is fast (fits the ~5-minute environment-cache budget), re-runnable, and cloud-proxy aware."
+allowed-tools: ["Skill", "Bash", "Read", "Write", "Glob", "Grep"]
+---
+
+# Generate Claude Remote Build Script: $ARGUMENTS
+
+Produce the artifacts a user pastes into a **Claude Code remote routine environment** so this repo
+runs in the cloud: a setup/build script that installs everything the environment needs, plus an
+environment-variable template and a network-allowlist list.
+
+## Purpose
+
+A routine's cloud environment lets you configure a **setup script** (runs once, cached) and
+**environment variables**. This skill turns the read-only inventory from
+`/lisa:analyze-claude-remote` into those concrete artifacts so the user doesn't hand-assemble them.
+
+This skill ships in the base Lisa plugin and is distributed to every host project, so the generated
+script must reflect **what this repo actually needs** — Lisa's startup hooks and configured
+tracker/source, plus the host project's own package manager and tooling — not a hardcoded list.
+
+## Inputs
+
+- Optional flags in `$ARGUMENTS`:
+  - `--out=<path>` — where to write the script. Default `scripts/claude-remote-setup.sh`.
+  - `--include-optional` — also install `OPTIONAL` (dormant-stack) tools. Default: required only.
+  - `--print` — print the script to stdout instead of writing a file.
+
+## Procedure
+
+1. **Inventory.** Invoke `/lisa:analyze-claude-remote --json` and parse its machine-readable
+   inventory block (`packageManager`, `tools`, `env`, `mcp`, `gaps`, `allowlistDomains`). If the
+   analysis cannot run, stop and report why — never emit a script from guesses.
+
+2. **Compose the setup script** from the inventory. The script must be:
+   - **Idempotent & detect-before-install** — every install guarded by a `command -v <tool>` check
+     so re-runs are no-ops and already-present tools are skipped.
+   - **Fast** — fits the ~5-minute environment-cache budget; avoid heavyweight installs unless
+     `REQUIRED`. Long/optional installs (docker images, chromium, ruby) go in a clearly-marked
+     optional section gated by `--include-optional`.
+   - **PATH-correct** — export the package manager's bin dir (e.g. `$HOME/.bun/bin`) after install
+     so subsequent steps and the cached environment resolve it.
+   - **Cloud-proxy aware** — when the package manager is flagged `RISK` (bun), add a comment
+     documenting the known proxy package-fetch issue and, where safe, run the install with retries
+     so a transient proxy failure doesn't poison the cache. Do not silently swap package managers if
+     `engines` forbids it; surface the risk as a comment instead.
+   - **Non-fatal on optional tools** — `REQUIRED` tool failures should exit non-zero (so the env
+     build fails loudly); `OPTIONAL` tool failures should warn and continue.
+
+3. **Emit the environment-variable template.** Write a commented block listing every `env` entry
+   from the inventory grouped by integration, marked `REQUIRED`/`OPTIONAL` and `secret`/`plain`,
+   with the reason. **Never write real secret values** — only names and placeholders, because the
+   environment config is visible to anyone who can edit it. Include feature flags actually set in
+   `.claude/settings.json` (e.g. `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS`) so cloud behavior matches
+   local.
+
+4. **Emit the allowlist + gaps notice.** List any custom domains the setup or runtime reaches
+   (from `allowlistDomains`) that the user must add to the environment's network access, and echo
+   the `gaps` from the analysis (auto-memory not synced, interactive-auth/stdio-MCP unavailable,
+   etc.) as a header comment so the user knows what the script **cannot** fix.
+
+5. **Write and report.** Write the script to `--out` (default `scripts/claude-remote-setup.sh`),
+   `chmod +x` it, and print: the path, a one-line summary of what it installs and which env vars to
+   set, and the exact next step (paste its contents — or a `bash scripts/claude-remote-setup.sh`
+   invocation — into the routine environment's setup script, and add the env vars in the
+   environment config). When `--print` is passed, print to stdout and do not write a file.
+
+## Generated script shape
+
+The emitted script should follow this skeleton (populated from the live inventory — this is the
+shape, not a fixed payload):
+
+```bash
+#!/usr/bin/env bash
+# Claude Code remote-routine setup for <repo>. Generated by /lisa:generate-claude-remote-build-script.
+# Paste into your routine environment's setup script. Re-runnable and idempotent.
+#
+# GAPS this script cannot fix (configure separately):
+#   - <gaps from analysis, e.g. auto-memory is machine-local and not synced to cloud routines>
+# ENV VARS to set in the environment config (names only — set real values there, not here):
+#   - CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1   # REQUIRED, matches .claude/settings.json
+#   - GH_TOKEN=<token>                          # OPTIONAL, gh auth beyond the repo connection
+# NETWORK: allowlist these domains in the environment if not on full access:
+#   - <allowlistDomains, if any>
+set -uo pipefail
+
+need() { command -v "$1" >/dev/null 2>&1; }
+require() { need "$1" || { echo "FATAL: required tool '$1' missing and install failed" >&2; exit 1; }; }
+
+# --- package manager (REQUIRED) ---
+if ! need bun; then
+  curl -fsSL https://bun.sh/install | bash
+fi
+export PATH="$HOME/.bun/bin:$PATH"
+# NOTE: bun has known proxy package-fetch issues in cloud sessions; retry to survive transient proxy errors.
+for i in 1 2 3; do bun install && break || sleep 5; done
+
+# --- required CLIs ---
+need gh || (sudo apt-get update -y && sudo apt-get install -y gh)
+need jq || sudo apt-get install -y jq
+require gh; require jq
+
+# --- optional, only with --include-optional ---
+# (docker / ruby / chromium / etc., guarded)
+```
+
+## Confirmation policy
+
+Writing the script file is the deliverable — do not ask whether to proceed. Default to writing
+`scripts/claude-remote-setup.sh`, then report the path and next steps. The only legitimate reasons
+to stop are: the analysis could not run, or the `--out` path is not writable.
+
+## Rules
+
+- Always derive the script from a fresh `/lisa:analyze-claude-remote` run — never from a stale or
+  assumed inventory.
+- Never write real secret values into the script or template — names and placeholders only.
+- Never emit an install for a tool the analysis did not surface, and never install `OPTIONAL` tools
+  unless `--include-optional` is set.
+- Keep the script idempotent and detect-before-install so it is safe to re-run and cache.
+- Preserve the inventory's `REQUIRED` vs `OPTIONAL` distinction in both fail-behavior (fatal vs
+  warn) and section placement.
+- Surface, never hide, the `gaps` — a generated script must not imply it makes a repo fully
+  cloud-ready when known constraints remain.

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

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

package/plugins/lisa-copilot/commands/analyze-claude-remote.md

@@ -0,0 +1,6 @@
+---
+description: "Audit whether this repository can run as a Claude Code remote routine (cloud session) and inventory everything Lisa AND the host project must install or configure in the cloud environment — CLIs/binaries, environment variables/secrets, startup hooks, MCP scope/auth, and the user-scoped config and auto-memory gaps that don't replicate remotely. Read-only; emits grouped findings plus a machine-readable inventory."
+argument-hint: "[--section=<name>] [--json]"
+---
+
+Use the /lisa:analyze-claude-remote skill to audit this repository's readiness to run as a Claude Code remote routine and inventory what the cloud environment must install and configure. $ARGUMENTS

package/plugins/lisa-copilot/commands/generate-claude-remote-build-script.md

@@ -0,0 +1,6 @@
+---
+description: "Generate the setup/build script and environment-variable template to paste into a Claude Code remote routine environment so this repo runs in the cloud. Runs /lisa:analyze-claude-remote, then writes an idempotent, detect-before-install bash script that installs the required package manager and CLIs for Lisa and the host project, plus a commented env-var template (names only) and a domain allowlist. Cloud-proxy aware and fits the environment-cache time budget."
+argument-hint: "[--out=<path>] [--include-optional] [--print]"
+---
+
+Use the /lisa:generate-claude-remote-build-script skill to generate the cloud-environment setup script and env-var template for running this repo as a Claude Code remote routine. $ARGUMENTS

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

@@ -0,0 +1,161 @@
+---
+name: analyze-claude-remote
+description: "Audit whether the current repository can run as a Claude Code remote routine (cloud session). Read-only analysis that inventories what Lisa AND the host project need to configure or build in the cloud environment — external CLIs/binaries to install, environment variables and secrets to set, startup hooks and their headless-safety, MCP server scope/transport/auth, user-scoped config and auto-memory gaps that don't replicate to the cloud, and platform constraints (bun proxy, IP allowlist, network tier, no interactivity). Emits grouped findings plus a machine-readable inventory that /lisa:generate-claude-remote-build-script consumes."
+allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
+---
+
+# Analyze Claude Remote: $ARGUMENTS
+
+Run a read-only audit of whether **this repository can run as a Claude Code remote routine**
+(a cloud session that runs on Anthropic-managed infrastructure, not the user's machine), and
+inventory everything that would have to be **installed** or **configured** in the cloud
+environment for both Lisa and the host project to function.
+
+## Purpose
+
+Claude Code routines run in a fresh cloud environment that clones the repo from its default
+branch. Setup scripts (to install tools) and environment variables (to provide config/secrets)
+are configurable per environment — but **only repo-committed Claude Code config reaches the
+cloud**, user-scoped config and machine-local auto-memory do not, and some local affordances
+(interactive auth, stdio MCP, desktop control, statusline) cannot work headless at all.
+
+This skill produces the answer to: *"If I turn this repo into a routine, what do I need to put
+in the environment's setup script and env vars, and what simply won't work?"* It is the
+read-only analysis half; `/lisa:generate-claude-remote-build-script` turns its inventory into an
+actual setup script.
+
+This skill ships in the base Lisa plugin and is distributed to every host project, so it must
+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),
+  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.
+
+## Inputs
+
+- Optional flags in `$ARGUMENTS` to narrow scope (e.g. `--section=tools`, `--json` to print only
+  the machine-readable inventory).
+- The current repository root: `.claude/settings.json`, enabled plugins' `hooks/hooks.json`,
+  `.mcp.json`, `.lisa.config.json` / `.lisa.config.local.json`, `package.json` (or other
+  manifest), lockfiles, `scripts/`, `.github/workflows/`, and committed skills/commands/hooks.
+
+## Confirmation policy
+
+Do **not** ask whether to proceed. Once invoked, run the read-only audit, print the grouped
+findings and the inventory, and stop. Do not mutate any repository, environment, tracker, or
+automation state. The only legitimate reason to stop early is that the working directory cannot
+be resolved to an inspectable repository root.
+
+## Audit contract
+
+Report grouped sections, each check tagged with one status:
+
+- `REQUIRED` — must be installed/set or a routine run cannot do core work.
+- `OPTIONAL` — needed only for a specific integration/stack that is dormant in this repo's config.
+- `GAP` — works locally but **cannot** work in a cloud routine regardless of configuration;
+  the user must change approach (e.g. promote a fact to a repo rule, switch a substrate).
+- `OK` — already cloud-safe; nothing to do.
+- `RISK` — likely to work but with a known cloud caveat the user should verify (e.g. bun proxy).
+
+Group the findings as:
+
+1. **Runtime & package manager** — resolve the package manager from `packageManager`, `engines`,
+   and the lockfile. Identify the install command a `SessionStart` hook or the project would run.
+   Flag `bun` as `RISK` (known cloud-proxy package-fetch issues) and note whether `engines`
+   forbids fallback package managers. Confirm node/runtime version expectations.
+
+2. **Startup hooks** — enumerate `SessionStart` and `SubagentStart` hooks from
+   `.claude/settings.json` and every enabled plugin's `hooks/hooks.json`. For each, state what it
+   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.
+
+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,
+   git, and coreutils are present; `gh` is available but should be installed explicitly if scripts
+   call it. Classify each `REQUIRED` (core path uses it) vs `OPTIONAL` (only a dormant stack/skill
+   uses it). Typical finds: `gh`, `jq`, `docker` (ZAP), `aws`, `acli`, `ruby`/`rubocop`,
+   `python3`, `playwright`/chromium, secret scanners.
+
+4. **Environment variables & secrets** — scan for `process.env.*`, `${VAR}`/`$VAR` in shell,
+   `secrets.*`/`env:` in CI, and config-referenced tokens. Group by integration (GitHub, AWS,
+   Atlassian/JIRA/Confluence, Notion, Linear, Anthropic, notifications, feature flags, other).
+   Cross-reference `.lisa.config.json` `tracker`/`source` to mark which credentials are **active**
+   for this repo vs **dormant** (`OPTIONAL`). Always surface Claude Code feature flags actually set
+   in `.claude/settings.json` (e.g. `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS`) as `REQUIRED` to match
+   local behavior, since the environment `env` block is the reliable place to set them.
+
+5. **MCP servers** — read every committed `.mcp.json`. For each server report transport and auth.
+   Project-scoped HTTP/SSE servers are `OK`. Flag stdio servers as `RISK`/`GAP` (need a local
+   process — only viable if the cloud session can spawn them from the repo). Flag
+   interactively/OAuth-authed servers (e.g. Linear) as `GAP` for first-time auth — they cannot
+   complete a browser flow headless. Note any user-scoped MCP (`~/.claude.json`) as `GAP` — it
+   never reaches the cloud; it must be moved into project `.mcp.json`.
+
+6. **Config scope & memory gaps** — identify reliance on user-scoped config that will not load
+   remotely: `~/.claude/CLAUDE.md`, user `enabledPlugins`, user skills/agents, user MCP. Most
+   importantly, flag **auto-memory** as a `GAP`: the persistent file-based memory directory is
+   machine-local and is not synced to cloud routines, so any learnings stored there are absent in
+   a remote run. Recommend promoting load-bearing memories into committed `.claude/rules/`.
+
+7. **Platform constraints** — surface the non-config constraints as `GAP`/`RISK` so the user is
+   not surprised: routines run with no interactive permission prompts and cannot ask the user
+   mid-run; interactive auth (SSO/OAuth browser, keychain) is unavailable; GitHub org IP
+   allowlisting blocks cloud sessions; outbound traffic is proxied and custom domains need
+   allowlisting; resource limits (~4 vCPU / 16 GB RAM / 30 GB disk); no desktop/computer-use; no
+   statusline/theme rendering.
+
+8. **Host-project app needs** — note any build/test/run command a routine would invoke and any
+   runtime service it depends on (database, queue, external API) that will not exist in a fresh
+   cloud environment, so the user can decide whether the routine's task is even feasible there.
+
+## Output
+
+Render the report grouped exactly as above. Start with one `Summary:` line, then a `Counts:` line
+covering `REQUIRED`, `OPTIONAL`, `GAP`, `RISK`, `OK`. Print each group as `<n>. <title>` and one
+line per check as `- <STATUS> <id>: <summary>`, with optional `Observed:` and `Action:` lines
+beneath that separate fact from advice. Render an empty group as a single `OK`/`SKIP` line with the
+reason rather than omitting it.
+
+End with a fenced, machine-readable inventory block (also printed when `--json` is passed) so
+`/lisa:generate-claude-remote-build-script` can consume it without re-deriving everything:
+
+```json
+{
+  "packageManager": { "name": "bun", "installCmd": "bun install", "risk": "cloud-proxy" },
+  "tools": [
+    { "name": "gh", "required": true, "reason": "github-* skills and scripts shell out to gh" },
+    { "name": "jq", "required": true, "reason": "hooks and scripts parse JSON" }
+  ],
+  "env": [
+    { "name": "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS", "required": true, "secret": false, "reason": "set in .claude/settings.json" },
+    { "name": "GH_TOKEN", "required": false, "secret": true, "reason": "gh CLI auth beyond the routine's repo connection" }
+  ],
+  "mcp": [ { "name": "linear-server", "transport": "http", "authGap": true } ],
+  "gaps": [ "auto-memory not synced to cloud", "bun package fetch behind proxy" ],
+  "allowlistDomains": []
+}
+```
+
+## Delegation and reuse
+
+- Reuse `config-resolution` semantics (local overrides global) when reading `.lisa.config.json` /
+  `.lisa.config.local.json` to decide which integrations are active vs dormant.
+- Complementary to `/lisa:doctor`: doctor answers "is this repo ready to use Lisa locally?";
+  this skill answers "can this repo run as a remote routine, and what must the cloud env provide?"
+  Do not duplicate doctor's local-readiness checks — focus on the local-vs-cloud delta.
+- The companion generator `/lisa:generate-claude-remote-build-script` consumes this skill's
+  inventory block; keep the block shape stable.
+
+## Rules
+
+- Never mutate repository, environment, tracker, or automation state. This skill is read-only.
+- Classify by **evidence in the repo**, not assumption — cite the file that proves each finding.
+- Distinguish active from dormant strictly by the resolved `.lisa.config.json` config; do not mark
+  a dormant tracker's credentials `REQUIRED`.
+- Never report a `GAP` as satisfiable by configuration — a gap is a constraint, and the action must
+  be a change of approach, not "set an env var".
+- Never invent tools or env vars that no committed file references.

package/plugins/lisa-copilot/skills/generate-claude-remote-build-script/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: generate-claude-remote-build-script
+description: "Generate the setup/build script (and env-var template) to paste into a Claude Code remote routine environment so this repo runs in the cloud. Runs /lisa:analyze-claude-remote to inventory needs, then writes an idempotent, detect-before-install bash script that installs the required CLIs/binaries and package manager for both Lisa and the host project, plus a commented environment-variable template (names only, never real secrets) and a list of custom domains to allowlist. The script is fast (fits the ~5-minute environment-cache budget), re-runnable, and cloud-proxy aware."
+allowed-tools: ["Skill", "Bash", "Read", "Write", "Glob", "Grep"]
+---
+
+# Generate Claude Remote Build Script: $ARGUMENTS
+
+Produce the artifacts a user pastes into a **Claude Code remote routine environment** so this repo
+runs in the cloud: a setup/build script that installs everything the environment needs, plus an
+environment-variable template and a network-allowlist list.
+
+## Purpose
+
+A routine's cloud environment lets you configure a **setup script** (runs once, cached) and
+**environment variables**. This skill turns the read-only inventory from
+`/lisa:analyze-claude-remote` into those concrete artifacts so the user doesn't hand-assemble them.
+
+This skill ships in the base Lisa plugin and is distributed to every host project, so the generated
+script must reflect **what this repo actually needs** — Lisa's startup hooks and configured
+tracker/source, plus the host project's own package manager and tooling — not a hardcoded list.
+
+## Inputs
+
+- Optional flags in `$ARGUMENTS`:
+  - `--out=<path>` — where to write the script. Default `scripts/claude-remote-setup.sh`.
+  - `--include-optional` — also install `OPTIONAL` (dormant-stack) tools. Default: required only.
+  - `--print` — print the script to stdout instead of writing a file.
+
+## Procedure
+
+1. **Inventory.** Invoke `/lisa:analyze-claude-remote --json` and parse its machine-readable
+   inventory block (`packageManager`, `tools`, `env`, `mcp`, `gaps`, `allowlistDomains`). If the
+   analysis cannot run, stop and report why — never emit a script from guesses.
+
+2. **Compose the setup script** from the inventory. The script must be:
+   - **Idempotent & detect-before-install** — every install guarded by a `command -v <tool>` check
+     so re-runs are no-ops and already-present tools are skipped.
+   - **Fast** — fits the ~5-minute environment-cache budget; avoid heavyweight installs unless
+     `REQUIRED`. Long/optional installs (docker images, chromium, ruby) go in a clearly-marked
+     optional section gated by `--include-optional`.
+   - **PATH-correct** — export the package manager's bin dir (e.g. `$HOME/.bun/bin`) after install
+     so subsequent steps and the cached environment resolve it.
+   - **Cloud-proxy aware** — when the package manager is flagged `RISK` (bun), add a comment
+     documenting the known proxy package-fetch issue and, where safe, run the install with retries
+     so a transient proxy failure doesn't poison the cache. Do not silently swap package managers if
+     `engines` forbids it; surface the risk as a comment instead.
+   - **Non-fatal on optional tools** — `REQUIRED` tool failures should exit non-zero (so the env
+     build fails loudly); `OPTIONAL` tool failures should warn and continue.
+
+3. **Emit the environment-variable template.** Write a commented block listing every `env` entry
+   from the inventory grouped by integration, marked `REQUIRED`/`OPTIONAL` and `secret`/`plain`,
+   with the reason. **Never write real secret values** — only names and placeholders, because the
+   environment config is visible to anyone who can edit it. Include feature flags actually set in
+   `.claude/settings.json` (e.g. `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS`) so cloud behavior matches
+   local.
+
+4. **Emit the allowlist + gaps notice.** List any custom domains the setup or runtime reaches
+   (from `allowlistDomains`) that the user must add to the environment's network access, and echo
+   the `gaps` from the analysis (auto-memory not synced, interactive-auth/stdio-MCP unavailable,
+   etc.) as a header comment so the user knows what the script **cannot** fix.
+
+5. **Write and report.** Write the script to `--out` (default `scripts/claude-remote-setup.sh`),
+   `chmod +x` it, and print: the path, a one-line summary of what it installs and which env vars to
+   set, and the exact next step (paste its contents — or a `bash scripts/claude-remote-setup.sh`
+   invocation — into the routine environment's setup script, and add the env vars in the
+   environment config). When `--print` is passed, print to stdout and do not write a file.
+
+## Generated script shape
+
+The emitted script should follow this skeleton (populated from the live inventory — this is the
+shape, not a fixed payload):
+
+```bash
+#!/usr/bin/env bash
+# Claude Code remote-routine setup for <repo>. Generated by /lisa:generate-claude-remote-build-script.
+# Paste into your routine environment's setup script. Re-runnable and idempotent.
+#
+# GAPS this script cannot fix (configure separately):
+#   - <gaps from analysis, e.g. auto-memory is machine-local and not synced to cloud routines>
+# ENV VARS to set in the environment config (names only — set real values there, not here):
+#   - CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1   # REQUIRED, matches .claude/settings.json
+#   - GH_TOKEN=<token>                          # OPTIONAL, gh auth beyond the repo connection
+# NETWORK: allowlist these domains in the environment if not on full access:
+#   - <allowlistDomains, if any>
+set -uo pipefail
+
+need() { command -v "$1" >/dev/null 2>&1; }
+require() { need "$1" || { echo "FATAL: required tool '$1' missing and install failed" >&2; exit 1; }; }
+
+# --- package manager (REQUIRED) ---
+if ! need bun; then
+  curl -fsSL https://bun.sh/install | bash
+fi
+export PATH="$HOME/.bun/bin:$PATH"
+# NOTE: bun has known proxy package-fetch issues in cloud sessions; retry to survive transient proxy errors.
+for i in 1 2 3; do bun install && break || sleep 5; done
+
+# --- required CLIs ---
+need gh || (sudo apt-get update -y && sudo apt-get install -y gh)
+need jq || sudo apt-get install -y jq
+require gh; require jq
+
+# --- optional, only with --include-optional ---
+# (docker / ruby / chromium / etc., guarded)
+```
+
+## Confirmation policy
+
+Writing the script file is the deliverable — do not ask whether to proceed. Default to writing
+`scripts/claude-remote-setup.sh`, then report the path and next steps. The only legitimate reasons
+to stop are: the analysis could not run, or the `--out` path is not writable.
+
+## Rules
+
+- Always derive the script from a fresh `/lisa:analyze-claude-remote` run — never from a stale or
+  assumed inventory.
+- Never write real secret values into the script or template — names and placeholders only.
+- Never emit an install for a tool the analysis did not surface, and never install `OPTIONAL` tools
+  unless `--include-optional` is set.
+- Keep the script idempotent and detect-before-install so it is safe to re-run and cache.
+- Preserve the inventory's `REQUIRED` vs `OPTIONAL` distinction in both fail-behavior (fatal vs
+  warn) and section placement.
+- Surface, never hide, the `gaps` — a generated script must not imply it makes a repo fully
+  cloud-ready when known constraints remain.

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

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

package/plugins/lisa-cursor/commands/analyze-claude-remote.md

@@ -0,0 +1,6 @@
+---
+description: "Audit whether this repository can run as a Claude Code remote routine (cloud session) and inventory everything Lisa AND the host project must install or configure in the cloud environment — CLIs/binaries, environment variables/secrets, startup hooks, MCP scope/auth, and the user-scoped config and auto-memory gaps that don't replicate remotely. Read-only; emits grouped findings plus a machine-readable inventory."
+argument-hint: "[--section=<name>] [--json]"
+---
+
+Use the /lisa:analyze-claude-remote skill to audit this repository's readiness to run as a Claude Code remote routine and inventory what the cloud environment must install and configure. $ARGUMENTS

package/plugins/lisa-cursor/commands/generate-claude-remote-build-script.md

@@ -0,0 +1,6 @@
+---
+description: "Generate the setup/build script and environment-variable template to paste into a Claude Code remote routine environment so this repo runs in the cloud. Runs /lisa:analyze-claude-remote, then writes an idempotent, detect-before-install bash script that installs the required package manager and CLIs for Lisa and the host project, plus a commented env-var template (names only) and a domain allowlist. Cloud-proxy aware and fits the environment-cache time budget."
+argument-hint: "[--out=<path>] [--include-optional] [--print]"
+---
+
+Use the /lisa:generate-claude-remote-build-script skill to generate the cloud-environment setup script and env-var template for running this repo as a Claude Code remote routine. $ARGUMENTS