@codyswann/lisa 2.317.4 → 2.317.6

package/package.json

@@ -115,7 +115,7 @@
     "brace-expansion": ">=5.0.8"
   },
   "name": "@codyswann/lisa",
-  "version": "2.317.4",
+  "version": "2.317.6",
   "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.317.4",
+  "version": "2.317.6",
   "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.317.4",
+  "version": "2.317.6",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/.codex-plugin/skills/lisa-setup-remote-env/SKILL.md

@@ -10,17 +10,27 @@ Prepare a remote surface so a host project can execute there. Today that means *
 
 ## What lives where
 
-The remote environment's own configuration fields stay **two one-line calls into the repository**. Nothing is pasted into a vendor UI.
+The remote environment's own configuration fields stay **one line into the repository, preceded by the project's dependency install**. Nothing else is pasted into a vendor UI.
 
 ```text
-setup:       bash scripts/lisa-remote-env/setup.sh
-maintenance: bash scripts/lisa-remote-env/setup.sh
+setup:       <install> && bash scripts/lisa-remote-env/setup.sh
+maintenance: <install> && bash scripts/lisa-remote-env/setup.sh
 ```
 
-They are the same script. A container may be built fresh or resumed from cache; every step is idempotent and version-aware, so running it twice is correct, and running it on resume is what picks up a rotated value, an edited note, or a changed version pin.
+`<install>` is whatever the project already uses — `bun install`, `npm ci`, `pnpm install`. Substitute it; do not invent one.
+
+They are the same command. A container may be built fresh or resumed from cache; every step is idempotent and version-aware, so running it twice is correct, and running it on resume is what picks up a rotated value, an edited note, or a changed version pin.
 
 The complete logic is repository-owned so it is reviewed, versioned, tested, and reusable. A large inline installer in a settings field is none of those things.
 
+### Why the install has to come first
+
+**A clone does not contain the skills on the harnesses that matter here.** OpenCode and Antigravity have them written into the checkout by `lisa apply`. Claude and Codex receive them as an *installed plugin*, which lives in the user's home directory — so a container that has just cloned the repository has never seen it.
+
+`node_modules/@codyswann/lisa` is therefore the only copy present on a fresh container, and it is a good one: it is the version that project pins, which is the version its setup should run. The entrypoint searches the agent directories first and falls back to it.
+
+Omitting the install does not degrade gracefully. The entrypoint exits before the toolchain, secrets, and hook phases have done anything, so the environment looks provisioned and fails on first dispatch.
+
 ## The three phases
 
 1. **Toolchain** — assert what must already be present, install what is not.
@@ -110,8 +120,11 @@ When emitting, produce exactly:
 ```text
 Environment name:  <project> remote executor
 Repository:        <org>/<repo>        (must be the default checkout)
-Setup script:      bash scripts/lisa-remote-env/setup.sh
-Maintenance:       bash scripts/lisa-remote-env/setup.sh
+Setup script:      <install> && bash scripts/lisa-remote-env/setup.sh
+Maintenance:       <install> && bash scripts/lisa-remote-env/setup.sh
+                   (<install> is the project's own: bun install, npm ci, ...
+                   It must precede the script — on a fresh container
+                   node_modules is the only copy of the skills present.)
 Environment vars:  LISA_SECRETS_SURFACE=codex-cloud
                    BWS_ACCESS_TOKEN=<from the provider; an environment
                    variable, not a task secret — setup and cache-resume
@@ -136,7 +149,7 @@ Checked when setup runs, not at 3am:
 
 - the environment exists and is bound to **this** repository as its default checkout;
 - the bootstrap credential resolves;
-- Lisa has been applied to the repository, so its skills are present in that checkout.
+- either a checkout-local Lisa skill is present, or the project dependency install has made the pinned `@codyswann/lisa` package available under `node_modules`.
 
 Fail with a message naming what is missing. Never provision-and-hope.
 

package/plugins/lisa/.codex-plugin/skills/lisa-setup-remote-env/assets/setup.sh

@@ -23,13 +23,26 @@ if ! command -v node >/dev/null 2>&1; then
   exit 1
 fi
 
-# The skill ships under whichever agent directory this project uses. Search
-# rather than hardcode, so one entrypoint serves every supported harness.
+# Where the skill lives depends on how this project's harness receives it, and
+# the two delivery models differ in a way that matters here.
+#
+# OpenCode and Antigravity get skills written INTO the checkout by `lisa apply`,
+# so a clone already carries them. Claude and Codex receive them as an installed
+# plugin, which lives in the user's home directory and is emphatically NOT part
+# of a clone. A fresh remote container is the second case every time: it clones
+# the repository and has never run a plugin install.
+#
+# So the agent directories are searched first — they are the cheapest hit and
+# need nothing installed — and the npm package is the fallback that makes the
+# plugin-delivered harnesses work at all. Lisa is a dependency of every project
+# it is applied to, so `node_modules` carries the same skill at the version that
+# project pins, which is the version its setup should run.
 runner=""
 for candidate in \
   ".claude/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
   ".agents/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
-  ".codex/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs"; do
+  ".codex/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
+  "node_modules/@codyswann/lisa/plugins/lisa/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs"; do
   if [ -f "$candidate" ]; then
     runner="$candidate"
     break
@@ -37,8 +50,19 @@ for candidate in \
 done
 
 if [ -z "$runner" ]; then
-  echo "Cannot find the lisa-setup-remote-env skill in this checkout." >&2
-  echo "Run 'lisa apply' so the skills are present, then re-run setup." >&2
+  echo "Cannot find the lisa-setup-remote-env skill." >&2
+  echo >&2
+  echo "Searched the agent skill directories and node_modules. On a remote" >&2
+  echo "container the usual cause is that dependencies have not been installed" >&2
+  echo "yet: Claude and Codex receive Lisa skills as an installed plugin, which" >&2
+  echo "is not part of a clone, so node_modules is the only copy present." >&2
+  echo >&2
+  echo "Install dependencies before this script runs. The environment's setup" >&2
+  echo "command should be the install and this script together, for example:" >&2
+  echo "  bun install && bash scripts/lisa-remote-env/setup.sh" >&2
+  echo >&2
+  echo "If dependencies are installed, run 'lisa apply' so the skills are" >&2
+  echo "present, then re-run setup." >&2
   exit 1
 fi
 

package/plugins/lisa/hooks/enforce-team-first.sh

@@ -51,8 +51,14 @@ TEAM_FLAG="${STATE_DIR}/${SESSION_ID}.team"
 # Best-effort cleanup of stale state files. Errors are ignored.
 find "$STATE_DIR" -maxdepth 1 -type f -mmin +1440 -delete 2>/dev/null || true
 
+# Lifecycle skills are named with either separator depending on the call path:
+# the Skill tool invokes plugin skills as `lisa:implement` (plugin:skill), while
+# the skill's own slug is `lisa-implement`. Normalize `:` to `-` before matching
+# so BOTH forms resolve — matching only the hyphen form made the "skill load is
+# always allowed" branch below dead code for every real plugin-skill call, which
+# blocked the very Skill call that loads the orchestration preamble.
 is_lifecycle_skill() {
-  case "$1" in
+  case "${1//:/-}" in
     lisa-research|lisa-plan|lisa-implement|lisa-intake|lisa-debrief) return 0 ;;
     *) return 1 ;;
   esac
@@ -200,7 +206,15 @@ If you are running Lisa in a non-Claude harness, this Claude enforcement hook
 should not be installed; follow the runtime-aware orchestration preamble in the
 skill instead.
 
-Re-read the orchestration preamble in /${ACTIVE_SKILL} and start by spawning the
-bounded input-resolver with the \`Agent\` tool.
+Start by spawning the bounded input-resolver with the \`Agent\` tool.
+
+THEN CALL \`Skill\` FOR /${ACTIVE_SKILL} AGAIN. This block is a precondition, not a
+substitute for the skill — nothing in this message replaces its contents. If you
+proceed straight from the input-resolver into the work, you will improvise a
+lifecycle that only resembles the real one: the skill's own steps (auto-merge on
+the PR, driving it to merged, usage accounting, two-way tracker linkage,
+non-closing work-item refs, remote verification, config-bound status
+transitions) are nowhere in this text and will be silently skipped. That failure
+is invisible in the output — the work still looks finished.
 EOF
 exit 2

package/plugins/lisa/skills/lisa-setup-remote-env/SKILL.md

@@ -10,17 +10,27 @@ Prepare a remote surface so a host project can execute there. Today that means *
 
 ## What lives where
 
-The remote environment's own configuration fields stay **two one-line calls into the repository**. Nothing is pasted into a vendor UI.
+The remote environment's own configuration fields stay **one line into the repository, preceded by the project's dependency install**. Nothing else is pasted into a vendor UI.
 
 ```text
-setup:       bash scripts/lisa-remote-env/setup.sh
-maintenance: bash scripts/lisa-remote-env/setup.sh
+setup:       <install> && bash scripts/lisa-remote-env/setup.sh
+maintenance: <install> && bash scripts/lisa-remote-env/setup.sh
 ```
 
-They are the same script. A container may be built fresh or resumed from cache; every step is idempotent and version-aware, so running it twice is correct, and running it on resume is what picks up a rotated value, an edited note, or a changed version pin.
+`<install>` is whatever the project already uses — `bun install`, `npm ci`, `pnpm install`. Substitute it; do not invent one.
+
+They are the same command. A container may be built fresh or resumed from cache; every step is idempotent and version-aware, so running it twice is correct, and running it on resume is what picks up a rotated value, an edited note, or a changed version pin.
 
 The complete logic is repository-owned so it is reviewed, versioned, tested, and reusable. A large inline installer in a settings field is none of those things.
 
+### Why the install has to come first
+
+**A clone does not contain the skills on the harnesses that matter here.** OpenCode and Antigravity have them written into the checkout by `lisa apply`. Claude and Codex receive them as an *installed plugin*, which lives in the user's home directory — so a container that has just cloned the repository has never seen it.
+
+`node_modules/@codyswann/lisa` is therefore the only copy present on a fresh container, and it is a good one: it is the version that project pins, which is the version its setup should run. The entrypoint searches the agent directories first and falls back to it.
+
+Omitting the install does not degrade gracefully. The entrypoint exits before the toolchain, secrets, and hook phases have done anything, so the environment looks provisioned and fails on first dispatch.
+
 ## The three phases
 
 1. **Toolchain** — assert what must already be present, install what is not.
@@ -110,8 +120,11 @@ When emitting, produce exactly:
 ```text
 Environment name:  <project> remote executor
 Repository:        <org>/<repo>        (must be the default checkout)
-Setup script:      bash scripts/lisa-remote-env/setup.sh
-Maintenance:       bash scripts/lisa-remote-env/setup.sh
+Setup script:      <install> && bash scripts/lisa-remote-env/setup.sh
+Maintenance:       <install> && bash scripts/lisa-remote-env/setup.sh
+                   (<install> is the project's own: bun install, npm ci, ...
+                   It must precede the script — on a fresh container
+                   node_modules is the only copy of the skills present.)
 Environment vars:  LISA_SECRETS_SURFACE=codex-cloud
                    BWS_ACCESS_TOKEN=<from the provider; an environment
                    variable, not a task secret — setup and cache-resume
@@ -136,7 +149,7 @@ Checked when setup runs, not at 3am:
 
 - the environment exists and is bound to **this** repository as its default checkout;
 - the bootstrap credential resolves;
-- Lisa has been applied to the repository, so its skills are present in that checkout.
+- either a checkout-local Lisa skill is present, or the project dependency install has made the pinned `@codyswann/lisa` package available under `node_modules`.
 
 Fail with a message naming what is missing. Never provision-and-hope.
 

package/plugins/lisa/skills/lisa-setup-remote-env/assets/setup.sh

@@ -23,13 +23,26 @@ if ! command -v node >/dev/null 2>&1; then
   exit 1
 fi
 
-# The skill ships under whichever agent directory this project uses. Search
-# rather than hardcode, so one entrypoint serves every supported harness.
+# Where the skill lives depends on how this project's harness receives it, and
+# the two delivery models differ in a way that matters here.
+#
+# OpenCode and Antigravity get skills written INTO the checkout by `lisa apply`,
+# so a clone already carries them. Claude and Codex receive them as an installed
+# plugin, which lives in the user's home directory and is emphatically NOT part
+# of a clone. A fresh remote container is the second case every time: it clones
+# the repository and has never run a plugin install.
+#
+# So the agent directories are searched first — they are the cheapest hit and
+# need nothing installed — and the npm package is the fallback that makes the
+# plugin-delivered harnesses work at all. Lisa is a dependency of every project
+# it is applied to, so `node_modules` carries the same skill at the version that
+# project pins, which is the version its setup should run.
 runner=""
 for candidate in \
   ".claude/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
   ".agents/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
-  ".codex/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs"; do
+  ".codex/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
+  "node_modules/@codyswann/lisa/plugins/lisa/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs"; do
   if [ -f "$candidate" ]; then
     runner="$candidate"
     break
@@ -37,8 +50,19 @@ for candidate in \
 done
 
 if [ -z "$runner" ]; then
-  echo "Cannot find the lisa-setup-remote-env skill in this checkout." >&2
-  echo "Run 'lisa apply' so the skills are present, then re-run setup." >&2
+  echo "Cannot find the lisa-setup-remote-env skill." >&2
+  echo >&2
+  echo "Searched the agent skill directories and node_modules. On a remote" >&2
+  echo "container the usual cause is that dependencies have not been installed" >&2
+  echo "yet: Claude and Codex receive Lisa skills as an installed plugin, which" >&2
+  echo "is not part of a clone, so node_modules is the only copy present." >&2
+  echo >&2
+  echo "Install dependencies before this script runs. The environment's setup" >&2
+  echo "command should be the install and this script together, for example:" >&2
+  echo "  bun install && bash scripts/lisa-remote-env/setup.sh" >&2
+  echo >&2
+  echo "If dependencies are installed, run 'lisa apply' so the skills are" >&2
+  echo "present, then re-run setup." >&2
   exit 1
 fi
 

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/skills/lisa-setup-remote-env/SKILL.md

@@ -10,17 +10,27 @@ Prepare a remote surface so a host project can execute there. Today that means *
 
 ## What lives where
 
-The remote environment's own configuration fields stay **two one-line calls into the repository**. Nothing is pasted into a vendor UI.
+The remote environment's own configuration fields stay **one line into the repository, preceded by the project's dependency install**. Nothing else is pasted into a vendor UI.
 
 ```text
-setup:       bash scripts/lisa-remote-env/setup.sh
-maintenance: bash scripts/lisa-remote-env/setup.sh
+setup:       <install> && bash scripts/lisa-remote-env/setup.sh
+maintenance: <install> && bash scripts/lisa-remote-env/setup.sh
 ```
 
-They are the same script. A container may be built fresh or resumed from cache; every step is idempotent and version-aware, so running it twice is correct, and running it on resume is what picks up a rotated value, an edited note, or a changed version pin.
+`<install>` is whatever the project already uses — `bun install`, `npm ci`, `pnpm install`. Substitute it; do not invent one.
+
+They are the same command. A container may be built fresh or resumed from cache; every step is idempotent and version-aware, so running it twice is correct, and running it on resume is what picks up a rotated value, an edited note, or a changed version pin.
 
 The complete logic is repository-owned so it is reviewed, versioned, tested, and reusable. A large inline installer in a settings field is none of those things.
 
+### Why the install has to come first
+
+**A clone does not contain the skills on the harnesses that matter here.** OpenCode and Antigravity have them written into the checkout by `lisa apply`. Claude and Codex receive them as an *installed plugin*, which lives in the user's home directory — so a container that has just cloned the repository has never seen it.
+
+`node_modules/@codyswann/lisa` is therefore the only copy present on a fresh container, and it is a good one: it is the version that project pins, which is the version its setup should run. The entrypoint searches the agent directories first and falls back to it.
+
+Omitting the install does not degrade gracefully. The entrypoint exits before the toolchain, secrets, and hook phases have done anything, so the environment looks provisioned and fails on first dispatch.
+
 ## The three phases
 
 1. **Toolchain** — assert what must already be present, install what is not.
@@ -110,8 +120,11 @@ When emitting, produce exactly:
 ```text
 Environment name:  <project> remote executor
 Repository:        <org>/<repo>        (must be the default checkout)
-Setup script:      bash scripts/lisa-remote-env/setup.sh
-Maintenance:       bash scripts/lisa-remote-env/setup.sh
+Setup script:      <install> && bash scripts/lisa-remote-env/setup.sh
+Maintenance:       <install> && bash scripts/lisa-remote-env/setup.sh
+                   (<install> is the project's own: bun install, npm ci, ...
+                   It must precede the script — on a fresh container
+                   node_modules is the only copy of the skills present.)
 Environment vars:  LISA_SECRETS_SURFACE=codex-cloud
                    BWS_ACCESS_TOKEN=<from the provider; an environment
                    variable, not a task secret — setup and cache-resume
@@ -136,7 +149,7 @@ Checked when setup runs, not at 3am:
 
 - the environment exists and is bound to **this** repository as its default checkout;
 - the bootstrap credential resolves;
-- Lisa has been applied to the repository, so its skills are present in that checkout.
+- either a checkout-local Lisa skill is present, or the project dependency install has made the pinned `@codyswann/lisa` package available under `node_modules`.
 
 Fail with a message naming what is missing. Never provision-and-hope.
 

package/plugins/lisa-agy/skills/lisa-setup-remote-env/assets/setup.sh

@@ -23,13 +23,26 @@ if ! command -v node >/dev/null 2>&1; then
   exit 1
 fi
 
-# The skill ships under whichever agent directory this project uses. Search
-# rather than hardcode, so one entrypoint serves every supported harness.
+# Where the skill lives depends on how this project's harness receives it, and
+# the two delivery models differ in a way that matters here.
+#
+# OpenCode and Antigravity get skills written INTO the checkout by `lisa apply`,
+# so a clone already carries them. Claude and Codex receive them as an installed
+# plugin, which lives in the user's home directory and is emphatically NOT part
+# of a clone. A fresh remote container is the second case every time: it clones
+# the repository and has never run a plugin install.
+#
+# So the agent directories are searched first — they are the cheapest hit and
+# need nothing installed — and the npm package is the fallback that makes the
+# plugin-delivered harnesses work at all. Lisa is a dependency of every project
+# it is applied to, so `node_modules` carries the same skill at the version that
+# project pins, which is the version its setup should run.
 runner=""
 for candidate in \
   ".claude/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
   ".agents/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
-  ".codex/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs"; do
+  ".codex/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
+  "node_modules/@codyswann/lisa/plugins/lisa/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs"; do
   if [ -f "$candidate" ]; then
     runner="$candidate"
     break
@@ -37,8 +50,19 @@ for candidate in \
 done
 
 if [ -z "$runner" ]; then
-  echo "Cannot find the lisa-setup-remote-env skill in this checkout." >&2
-  echo "Run 'lisa apply' so the skills are present, then re-run setup." >&2
+  echo "Cannot find the lisa-setup-remote-env skill." >&2
+  echo >&2
+  echo "Searched the agent skill directories and node_modules. On a remote" >&2
+  echo "container the usual cause is that dependencies have not been installed" >&2
+  echo "yet: Claude and Codex receive Lisa skills as an installed plugin, which" >&2
+  echo "is not part of a clone, so node_modules is the only copy present." >&2
+  echo >&2
+  echo "Install dependencies before this script runs. The environment's setup" >&2
+  echo "command should be the install and this script together, for example:" >&2
+  echo "  bun install && bash scripts/lisa-remote-env/setup.sh" >&2
+  echo >&2
+  echo "If dependencies are installed, run 'lisa apply' so the skills are" >&2
+  echo "present, then re-run setup." >&2
   exit 1
 fi
 

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

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

package/plugins/lisa-copilot/skills/lisa-setup-remote-env/SKILL.md

@@ -10,17 +10,27 @@ Prepare a remote surface so a host project can execute there. Today that means *
 
 ## What lives where
 
-The remote environment's own configuration fields stay **two one-line calls into the repository**. Nothing is pasted into a vendor UI.
+The remote environment's own configuration fields stay **one line into the repository, preceded by the project's dependency install**. Nothing else is pasted into a vendor UI.
 
 ```text
-setup:       bash scripts/lisa-remote-env/setup.sh
-maintenance: bash scripts/lisa-remote-env/setup.sh
+setup:       <install> && bash scripts/lisa-remote-env/setup.sh
+maintenance: <install> && bash scripts/lisa-remote-env/setup.sh
 ```
 
-They are the same script. A container may be built fresh or resumed from cache; every step is idempotent and version-aware, so running it twice is correct, and running it on resume is what picks up a rotated value, an edited note, or a changed version pin.
+`<install>` is whatever the project already uses — `bun install`, `npm ci`, `pnpm install`. Substitute it; do not invent one.
+
+They are the same command. A container may be built fresh or resumed from cache; every step is idempotent and version-aware, so running it twice is correct, and running it on resume is what picks up a rotated value, an edited note, or a changed version pin.
 
 The complete logic is repository-owned so it is reviewed, versioned, tested, and reusable. A large inline installer in a settings field is none of those things.
 
+### Why the install has to come first
+
+**A clone does not contain the skills on the harnesses that matter here.** OpenCode and Antigravity have them written into the checkout by `lisa apply`. Claude and Codex receive them as an *installed plugin*, which lives in the user's home directory — so a container that has just cloned the repository has never seen it.
+
+`node_modules/@codyswann/lisa` is therefore the only copy present on a fresh container, and it is a good one: it is the version that project pins, which is the version its setup should run. The entrypoint searches the agent directories first and falls back to it.
+
+Omitting the install does not degrade gracefully. The entrypoint exits before the toolchain, secrets, and hook phases have done anything, so the environment looks provisioned and fails on first dispatch.
+
 ## The three phases
 
 1. **Toolchain** — assert what must already be present, install what is not.
@@ -110,8 +120,11 @@ When emitting, produce exactly:
 ```text
 Environment name:  <project> remote executor
 Repository:        <org>/<repo>        (must be the default checkout)
-Setup script:      bash scripts/lisa-remote-env/setup.sh
-Maintenance:       bash scripts/lisa-remote-env/setup.sh
+Setup script:      <install> && bash scripts/lisa-remote-env/setup.sh
+Maintenance:       <install> && bash scripts/lisa-remote-env/setup.sh
+                   (<install> is the project's own: bun install, npm ci, ...
+                   It must precede the script — on a fresh container
+                   node_modules is the only copy of the skills present.)
 Environment vars:  LISA_SECRETS_SURFACE=codex-cloud
                    BWS_ACCESS_TOKEN=<from the provider; an environment
                    variable, not a task secret — setup and cache-resume
@@ -136,7 +149,7 @@ Checked when setup runs, not at 3am:
 
 - the environment exists and is bound to **this** repository as its default checkout;
 - the bootstrap credential resolves;
-- Lisa has been applied to the repository, so its skills are present in that checkout.
+- either a checkout-local Lisa skill is present, or the project dependency install has made the pinned `@codyswann/lisa` package available under `node_modules`.
 
 Fail with a message naming what is missing. Never provision-and-hope.
 

package/plugins/lisa-copilot/skills/lisa-setup-remote-env/assets/setup.sh

@@ -23,13 +23,26 @@ if ! command -v node >/dev/null 2>&1; then
   exit 1
 fi
 
-# The skill ships under whichever agent directory this project uses. Search
-# rather than hardcode, so one entrypoint serves every supported harness.
+# Where the skill lives depends on how this project's harness receives it, and
+# the two delivery models differ in a way that matters here.
+#
+# OpenCode and Antigravity get skills written INTO the checkout by `lisa apply`,
+# so a clone already carries them. Claude and Codex receive them as an installed
+# plugin, which lives in the user's home directory and is emphatically NOT part
+# of a clone. A fresh remote container is the second case every time: it clones
+# the repository and has never run a plugin install.
+#
+# So the agent directories are searched first — they are the cheapest hit and
+# need nothing installed — and the npm package is the fallback that makes the
+# plugin-delivered harnesses work at all. Lisa is a dependency of every project
+# it is applied to, so `node_modules` carries the same skill at the version that
+# project pins, which is the version its setup should run.
 runner=""
 for candidate in \
   ".claude/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
   ".agents/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
-  ".codex/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs"; do
+  ".codex/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
+  "node_modules/@codyswann/lisa/plugins/lisa/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs"; do
   if [ -f "$candidate" ]; then
     runner="$candidate"
     break
@@ -37,8 +50,19 @@ for candidate in \
 done
 
 if [ -z "$runner" ]; then
-  echo "Cannot find the lisa-setup-remote-env skill in this checkout." >&2
-  echo "Run 'lisa apply' so the skills are present, then re-run setup." >&2
+  echo "Cannot find the lisa-setup-remote-env skill." >&2
+  echo >&2
+  echo "Searched the agent skill directories and node_modules. On a remote" >&2
+  echo "container the usual cause is that dependencies have not been installed" >&2
+  echo "yet: Claude and Codex receive Lisa skills as an installed plugin, which" >&2
+  echo "is not part of a clone, so node_modules is the only copy present." >&2
+  echo >&2
+  echo "Install dependencies before this script runs. The environment's setup" >&2
+  echo "command should be the install and this script together, for example:" >&2
+  echo "  bun install && bash scripts/lisa-remote-env/setup.sh" >&2
+  echo >&2
+  echo "If dependencies are installed, run 'lisa apply' so the skills are" >&2
+  echo "present, then re-run setup." >&2
   exit 1
 fi
 

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

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