plugins/lisa-cursor/skills/lisa-jam-access/SKILL.md
Vendor-neutral access layer for Jam. Jam triage rules and skills MUST delegate through this skill rather than calling Jam MCP tools directly. Per the credential-substrate-precedence contract, resolves the JAM_PAT-authenticated Jam CLI first when the PAT is present and identity-matched, then falls back to the Jam MCP.
npx skillsauth add codyswanngt/lisa lisa-jam-accessInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security scan pending...
This skill is queued for security scanning. Results will appear when the scan completes.
Single chokepoint for Jam operations. Caller skills and rules MUST NOT call
mcp__Jam__* tools directly.
operation: get-trace url:<jam-url-or-id>
operation: get-recording url:<jam-url-or-id>
operation: get-bug-report url:<jam-url-or-id>
Return parsed JSON or a concise structured summary in a <result> block.
Probe in order — the ordering is the shared credential-substrate-precedence
contract, not a Jam-local choice. The first tier that is ready and
identity-matches the configured Jam account is used; one authenticated elsewhere
is skipped, never used.
JAM_PAT,
resolved through lisa-secrets-access.JAM_PAT, no CLI
adapter for the operation, or a Jam outage.Jam documents a PAT-authenticated CLI that is cleaner for remote routines than
editing .mcp.json headers, and it is the same substrate interactively and
headlessly — which is why it leads. The CLI tier uses:
curl -fsSL https://native.jam.dev/install | bash
export PATH="$HOME/.local/bin:$PATH"
# Resolve the PAT through the chokepoint before giving up on the environment.
# `$JAM_PAT` is the documented fallback, not the only rung: without this, a
# project that keeps its credentials in Bitwarden, Doppler, or AWS has no tier 1
# path at all and silently resolves through the interactive MCP — the exact
# divergence `credential-substrate-precedence` exists to remove.
read_jam_pat() {
[ -n "${JAM_PAT:-}" ] && { echo "$JAM_PAT"; return; }
#
# Ordered across trusted machine-managed substrates, ending at the installed
# package. Checkout-local paths are deliberately absent: a familiar generated
# destination is still repository-controlled executable code. The plugin
# rungs are the floor: `resolve-secret.mjs` ships beside this skill, so a rung
# pointing at it is reachable from anywhere the plugin itself is installed.
# Without one, a consumer repository that vendors none of the leading paths
# never reaches a resolver at all — the ladder exits without having asked
# anything, which is what pushed agents into improvising their own credential
# lookups. This LADDER is identical in every skill that resolves a credential
# and `credential-resolver-ladder` fails if any copy diverges. Only what
# happens AFTER the ladder may differ between them.
# Execute only machine-managed plugin/package resolvers. Checkout-local
# candidates are repository-controlled code, not trusted merely by path.
local candidates=()
if [ -n "${CLAUDE_PLUGIN_ROOT:-}" ]; then
candidates+=("$CLAUDE_PLUGIN_ROOT/skills/lisa-secrets-access/scripts/resolve-secret.mjs")
fi
if [ -n "${PLUGIN_ROOT:-}" ]; then
candidates+=("$PLUGIN_ROOT/skills/lisa-secrets-access/scripts/resolve-secret.mjs")
fi
# Last rung deliberately needs no environment variable: an agent that was
# never handed a plugin root still has the installed package to fall back on.
candidates+=(node_modules/@codyswann/lisa/plugins/lisa/skills/lisa-secrets-access/scripts/resolve-secret.mjs)
local resolver
local tried=()
for resolver in "${candidates[@]}"; do
tried+=("$resolver")
if [ -f "$resolver" ]; then
local via_lisa
via_lisa=$(node "$resolver" get JAM_PAT 2>/dev/null) \
&& [ -n "$via_lisa" ] && { echo "$via_lisa"; return; }
# Empty/error means this substrate had no answer; try the next trusted one.
fi
done
# Name every path. A bare `return 1` sends the next reader hunting for a
# resolver they cannot see the absence of; the enumeration turns that into a
# seconds-long diagnosis. Paths and store coordinates only — never any
# resolved value, on any path.
echo "Error: could not resolve JAM_PAT through lisa-secrets-access." >&2
echo "Tried, in order (relative paths are from $PWD):" >&2
printf ' %s\n' "${tried[@]}" >&2
return 1
}
# Piped, never written to disk and never passed as an argv token: a PAT on a
# command line is readable from the process table by every user on the host.
read_jam_pat | jam auth login --token
jam skills install
If neither tier works, fail with:
Error: no Jam access substrate available. Authenticate the Jam MCP, set JAM_PAT, or store JAM_PAT in this project's secrets provider.
Every operation in the Invocation Contract is read-only — fetching a trace,
a recording, or a bug report. So the credential-substrate-precedence guarded
fallback for mutating operations (write, read back, assert the tenant from the
response, roll back on mismatch) is not engaged here, and a failed tier is
simply skipped. A future operation that mutates Jam state — commenting on or
deleting a Jam — is a write and MUST reconcile by read-back before any retry.
credential-substrate-precedence: JAM_PAT CLI first, Jam MCP as
a preserved first-class fallback. Do not retry a failed tier blindly.lisa-secrets-access, with the bare JAM_PAT
environment variable as the documented fallback. Never read a second
credential store directly..mcp.json or any generated setup artifact.native.jam.dev for the installer and
api.jam.dev for CLI/API calls in any custom remote network allowlist.development
Prepare a machine — a fresh laptop or a throwaway container — to run coding agents, before any repository exists. Detects which of Lisa's supported agents (Claude Code, Codex, Cursor, OpenCode, Antigravity, Copilot) are already installed, asks which credential manager the machine uses (Bitwarden, 1Password, Doppler, Vault, AWS, or none), and installs only what is missing, each by its vendor's own preferred method. Idempotent, headless by default, and emits a Dockerfile for a spin-up/spin-down environment. Run it on a new machine, in a container, or before cloning anything.
tools
Provision and verify a remote execution environment for a host project — Codex Cloud today, other remote surfaces as they are added. Generates a repository-owned setup script that installs the declared toolchain, materializes secrets through lisa-secrets-access, and runs the project's own hook. Provisions by API where one exists, by driving the vendor console where one does not, and by emitting exact config otherwise — then proves the result with the same read-back regardless of which tier did the work. Use before dispatching any work with executionEnv.
tools
Bring a developer's machine in line with the toolchain the project declares. Reports every tool in remoteEnv.tools that is missing, outdated, or unpinned for this platform, and installs the missing ones into ~/.local/bin from the same pinned, checksummed entries the remote surfaces use — but only when asked. Same manifest, same pins, same installers as lisa-setup-remote-env; what differs is consent and that the pin is a floor rather than an equality. Run it on a fresh checkout, after a manifest change, or when a tool fails at the moment of use.
tools
Route one unit of work to a remote execution surface. Reads the executionEnv parameter (local by default, codex-cloud or claude-web today), verifies the environment is provisioned and bound to this repository, submits a thin skill invocation, records the task identifier to .lisa/remote-dispatch.json, and exits without polling. Routing only — the remote runs the identical skill from the identical repository. Composable and inline: other skills invoke it via the Skill tool rather than users calling it directly.