plugins/lisa-cursor/skills/generate-claude-remote-build-script/SKILL.md
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.
npx skillsauth add codyswanngt/lisa generate-claude-remote-build-scriptInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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.
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.
$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.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.
Compose the setup script from the inventory. The script must be:
command -v <tool> check
so re-runs are no-ops and already-present tools are skipped.REQUIRED. Long/optional installs (docker images, chromium, ruby) go in a clearly-marked
optional section gated by --include-optional.$HOME/.bun/bin) after install
so subsequent steps and the cached environment resolve it.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.REQUIRED tool failures should exit non-zero (so the env
build fails loudly); OPTIONAL tool failures should warn and continue.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.
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.
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.
The emitted script should follow this skeleton (populated from the live inventory — this is the shape, not a fixed payload):
#!/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)
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.
/lisa:analyze-claude-remote run — never from a stale or
assumed inventory.OPTIONAL tools
unless --include-optional is set.REQUIRED vs OPTIONAL distinction in both fail-behavior (fatal vs
warn) and section placement.gaps — a generated script must not imply it makes a repo fully
cloud-ready when known constraints remain.documentation
Onboard a user to the project via its LLM Wiki. Interviews the user about themselves in relation to the project, captures that to project-scoped memory only, then gives a guided tour of what the project is and sample questions they can ask. Use when someone is new to the project or asks to be onboarded. Read-mostly — it does not open PRs or write PII into the wiki.
documentation
Migrate an existing, hand-rolled wiki implementation onto the lisa-wiki kernel — phased and compatibility-first, with a strict no-loss guarantee. Use when adopting lisa-wiki in a repo that already has its own wiki/, ingest skills, docs, or roles. Renaming things into the canonical shape is fine; losing functionality or data is not. Ends by running /doctor.
development
Health-check the LLM Wiki. Reports orphan pages, contradictions, stale claims, broken internal links, missing index/log coverage, structure-manifest violations, and secret/tenant leaks. Use periodically or before hardening a wiki. Read-only — it reports findings, it does not fix them.
testing
Ingest source material into the LLM Wiki. With an argument (URL, file path, or prompt) it ingests that one source; with no argument it runs a full ingest across every enabled non-external-write source. Routes to the right connector, then runs the ordered pipeline (source note → synthesis → index → log → verify → state → commit/PR). Use whenever new knowledge should enter the wiki.