@codyswann/lisa 2.189.7 → 2.189.8

package/plugins/lisa/skills/fix-linter-error/SKILL.md

@@ -1,45 +0,0 @@
----
-name: fix-linter-error
-description: This skill should be used when fixing all violations of one or more ESLint rules across the codebase. It runs the linter, groups violations by rule and file, generates a brief with fix strategies, and creates a plan with tasks to implement the fixes.
-allowed-tools: ["Read", "Bash", "Glob", "Grep"]
-
----
-
-# Fix Linter Errors
-
-Target rules: $ARGUMENTS
-
-If no arguments provided, prompt the user for at least one lint rule name.
-
-## Step 1: Gather Requirements
-
-1. **Parse rules** from $ARGUMENTS (space-separated)
-2. **Run linter** to collect all violations:
-   ```bash
-   bun run lint 2>&1
-   ```
-3. **Group violations** by rule, then by file, noting:
-   - File path and line numbers
-   - Violation count per file
-   - Sample error messages
-
-## Step 2: Compile Brief and Delegate
-
-Compile the gathered information into a structured brief:
-
-```
-Fix ESLint violations for rules: $ARGUMENTS
-
-Violations by rule:
-- [rule-name-1]: X total violations across Y files
-  - [file]: N violations (lines: ...)
-  - ...
-- [rule-name-2]: X total violations across Y files
-  - ...
-
-Fix strategies: extract functions, early returns, apply formatting, add types
-
-Verification: `bun run lint 2>&1 | grep -E "($ARGUMENTS)" | wc -l` → Expected: 0
-```
-
-Invoke `/implement` with this brief to create the implementation plan.

package/plugins/lisa/skills/fix-linter-error/agents/openai.yaml

@@ -1,4 +0,0 @@
-display_name: "Fix Linter Error"
-short_description: "fixing all violations of one or more ESLint rules across the codebase"
-default_prompt:
-  - "Use $fix-linter-error: fixing all violations of one or more ESLint rules across the codebase."

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

@@ -1,224 +0,0 @@
----
-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`, `platform`,
-   `networkAccess`, `allowlistDomains`, `awsProfiles`). 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. Entries flagged `providedBy: settings.json`
-   (the committed `.claude/settings.json` `env` flags, e.g. `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS`) are
-   **already applied from the committed file** — list them under an `# Already provided by committed
-   .claude/settings.json — no UI entry needed` heading, not as values to set. The "set in the
-   environment UI" template is for **secrets only**. For every secret entry that carries
-   `acquireUrl`/`accessScope`/`headlessSubstrate` (the
-   active tracker/source credentials from the analysis's group 4a), render those as comment lines
-   directly above the name — `# Acquire: <url>` and `# Access: <scope>` — so the user knows exactly
-   where to get the token and what permissions it needs. Emit only the **env-var form** of the name
-   that the analysis reported (including any per-account suffixed form like `LINEAR_API_KEY_<slug>`);
-   never emit a keychain instruction — keychain does not exist in a cloud routine.
-   When the entry is `GH_TOKEN`, add a comment from `platform.githubProxy` clarifying that the token
-   is for `gh` CLI commands against the project/Lisa repos, not for raw git clone/fetch/push or
-   sibling repos reachable through the routine's GitHub proxy.
-   For OPTIONAL non-tracker MCP recovery entries discovered by
-   `/lisa:analyze-claude-remote`, preserve the same names-only behavior:
-   include `JAM_PAT`, `SONAR_TOKEN`, or similar documented substrate env vars
-   only as optional secrets, with their acquire/scope comments when the analysis
-   supplied them. Never invent values or promote dormant substrates to required.
-   When AWS entries are present, list `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, optional
-   `AWS_SESSION_TOKEN`, and `AWS_DEFAULT_REGION` exactly as the analysis reported. State that these
-   bootstrap credentials are for STS assume-role only; do not emit or recommend `aws sso login`.
-
-3a. **Emit substrate setup snippets.** When the inventory marks an MCP
-   `headlessUsable: true` through a documented substrate, render the matching
-   wiring guidance as commented, opt-in setup:
-   - CLI substrates: emit the detected install/login commands gated on the
-     optional env var. For Jam, this means `curl -fsSL https://native.jam.dev/install | bash`,
-     `export PATH="$HOME/.local/bin:$PATH"`, `printf '%s' "$JAM_PAT" | jam auth login --token`,
-     and `jam skills install`, all inside `[ -n "${JAM_PAT:-}" ] && ...` guards so missing
-     optional secrets do not fail the environment build.
-   - REST substitute substrates: do not install an MCP. Emit comments naming the
-     REST host and env var (for example `SONAR_TOKEN` with `https://sonarcloud.io/api/`) and
-     rely on the access skill or generated consumer to call the API.
-   - PAT-bearer MCP substrates: print a commented `.mcp.json` `headers` snippet from the
-     inventory's `mcpHeaders`. Use this only when the analysis explicitly says the same MCP
-     transport supports static-token auth. Do not print a Jam `.mcp.json` header snippet because
-     Jam's preferred headless substrate is its PAT-authenticated CLI.
-
-3b. **Emit AWS assume-role profile setup.** When the inventory includes `awsProfiles`, write an
-   idempotent `~/.aws/config` block gated on `[ -n "${AWS_ACCESS_KEY_ID:-}" ]`. The generated block
-   must:
-   - `mkdir -p "$HOME/.aws"` and create or append profile stanzas without writing secrets.
-   - Emit one `[profile <name>]` stanza per inventory profile with `role_arn`,
-     `credential_source = Environment`, `region` when present, and `external_id` when present.
-   - Keep regions and ExternalIds as non-secret project metadata from the inventory; never invent
-     account IDs, role names, profile names, regions, or ExternalIds.
-   - Warn and skip profile writing when AWS profile metadata is absent, while still listing the
-     required `AWS_*` env var names in the secret template.
-   - Include a comment that agents should use `aws --profile <name> ...` and must not run
-     `aws sso login` in headless routines.
-
-4. **Emit the allowlist + gaps notice.** List any custom domains the setup or runtime reaches
-   (from `networkAccess.allowlistDomains`, falling back to legacy `allowlistDomains`) that the user
-   must add when the environment needs Custom network access. Do not include default Trusted domains
-   such as GitHub, npm/PyPI registries, or Docker Hub. Echo the `gaps` from the analysis
-   (auto-memory not synced, interactive-auth/stdio-MCP unavailable, etc.) and the
-   `platform.secretsVisibility` warning 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>
-# Already provided by committed .claude/settings.json (applied automatically — no UI entry needed):
-#   - CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS, ENABLE_LSP_TOOL, BASH_DEFAULT_TIMEOUT_MS, BASH_MAX_TIMEOUT_MS
-# SECRETS to set in the environment config (names only — set real values there, not here):
-#   # --- credentials for the active tracker/source (set in the environment UI) ---
-#   # Acquire: https://github.com/settings/personal-access-tokens
-#   # Access:  fine-grained PAT on target repo: Contents R/W, Issues R/W, Pull requests R/W, Metadata R
-#   # Note: GH_TOKEN is for gh CLI only. Raw git uses Claude's connected-GitHub proxy/identity;
-#   # sibling repos reached only by raw git do not need to be in this token scope.
-#   - GH_TOKEN=<token>                          # REQUIRED, github is the active tracker+source
-#   - AWS_ACCESS_KEY_ID=<access-key-id>          # REQUIRED when AWS inventory is active
-#   - AWS_SECRET_ACCESS_KEY=<secret-access-key>  # REQUIRED when AWS inventory is active
-#   - AWS_SESSION_TOKEN=<session-token>          # OPTIONAL for temporary bootstrap creds
-# NETWORK: set the environment to Custom and allowlist these non-default domains if not on Full:
-#   - <networkAccess.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) ---
-# Resolve the PM from packageManager/engines/lockfiles — emit the manager the
-# `packageManager` inventory field reported, NEVER a hardcoded bun. An npm-only
-# project (engines.bun = "please-use-npm") must install with npm; emitting
-# `bun install` would create a stray bun.lock and break it (the SE-5221
-# regression). Only install/PATH-export the manager actually selected below.
-detect_package_manager() {
-  _field="" _forced="" _forbidden=""
-  if [ -f package.json ] && command -v jq >/dev/null 2>&1; then
-    _field=$(jq -r '(.packageManager // "") | sub("@.*$";"")' package.json 2>/dev/null)
-    _forced=$(jq -r 'first((.engines // {})[] | strings | capture("please-use-(?<pm>bun|npm|yarn|pnpm)")?.pm) // ""' package.json 2>/dev/null)
-    _forbidden=$(jq -r '[(.engines // {}) | to_entries[] | select(((.value|strings) // "") | test("please-use|do-not-use";"i")) | .key] | join(" ")' package.json 2>/dev/null)
-  fi
-  case "$_field" in bun | npm | yarn | pnpm) printf '%s\n' "$_field"; return 0 ;; esac
-  case "$_forced" in bun | npm | yarn | pnpm) printf '%s\n' "$_forced"; return 0 ;; esac
-  _pm_allowed() { case " $_forbidden " in *" $1 "*) return 1 ;; *) return 0 ;; esac; }
-  { [ -f bun.lockb ] || [ -f bun.lock ]; } && _pm_allowed bun && { printf 'bun\n'; return 0; }
-  [ -f pnpm-lock.yaml ] && _pm_allowed pnpm && { printf 'pnpm\n'; return 0; }
-  [ -f yarn.lock ] && _pm_allowed yarn && { printf 'yarn\n'; return 0; }
-  [ -f package-lock.json ] && _pm_allowed npm && { printf 'npm\n'; return 0; }
-  printf 'npm\n'
-}
-PM="$(detect_package_manager)"
-if [ "$PM" = "bun" ] && ! need bun; then
-  curl -fsSL https://bun.sh/install | bash
-  export PATH="$HOME/.bun/bin:$PATH"
-fi
-# NOTE: bun has known proxy package-fetch issues in cloud sessions; retry to survive transient proxy errors.
-for i in 1 2 3; do "$PM" 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
-
-# --- AWS assume-role profiles, when inventory includes awsProfiles ---
-if [ -n "${AWS_ACCESS_KEY_ID:-}" ]; then
-  mkdir -p "$HOME/.aws"
-  # Generated stanzas use credential_source=Environment and contain no secrets.
-  # Agents should run: aws --profile <profile> ...
-  # Do not run aws sso login in headless routines; SSO requires an interactive browser/device flow.
-fi
-
-# --- 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.
-- For active tracker/source credentials, carry the analysis's `Acquire:` URL and `Access:` scope into
-  the template as comments, and emit only the env-var form of the name — never a keychain command.
-- For `GH_TOKEN`, preserve the analysis's GitHub proxy split: it is for `gh` CLI commands only, and
-  raw git/cross-repo clone guidance must not expand the token scope to sibling repositories.
-- Never emit an install for a tool the analysis did not surface, and never install `OPTIONAL` tools
-  unless `--include-optional` is set.
-- When AWS is in the inventory, generate environment-backed assume-role profile stanzas from
-  `awsProfiles`; never emit `aws sso login` as a remote setup step.
-- Prefer `networkAccess.allowlistDomains` over legacy top-level `allowlistDomains`; never emit
-  domains already covered by the routine environment's default Trusted list.
-- 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/skills/generate-claude-remote-build-script/agents/openai.yaml

@@ -1,4 +0,0 @@
-display_name: "Generate Claude Remote Build Script"
-short_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"
-default_prompt:
-  - "Use $generate-claude-remote-build-script: 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."

package/plugins/lisa/skills/git-commit/SKILL.md

@@ -1,48 +0,0 @@
----
-name: git-commit
-description: This skill should be used when creating conventional commits for current changes. It groups related changes into logical commits, ensures all files are committed, and verifies the working directory is clean afterward.
-allowed-tools: ["Bash"]
----
-
-# Git Commit Workflow
-
-Create conventional commits for current changes. Optional hint: $ARGUMENTS
-
-## Workflow
-
-### See what has changed
-
-!git status
-!git diff --stat
-
-### Apply these requirements
-
-1. **Branch Check**: If on `dev`, `staging`, or `main`, create a feature branch named after the changes
-2. **Commit Strategy**: Group related changes into logical conventional commits (feat, fix, chore, docs, etc.)
-3. **Commit ALL Files**: Every file must be assigned to a commit group - no file gets left out or unstaged
-4. **Commit Creation**: Stage and commit each group with clear messages
-5. **Verification**: Run `git status` to confirm working directory is clean - must show "nothing to commit"
-
-### Use conventional commit format
-
-- `feat:` for new features
-- `fix:` for bug fixes
-- `docs:` for documentation
-- `chore:` for maintenance
-- `style:` for formatting
-- `refactor:` for code restructuring
-- `test:` for test additions
-
-### Never
-
-- use `--no-verify` flag
-- attempt to bypass tests or quality checks
-- skip tests or quality checks
-- stash changes - ALL changes must be committed
-- skip or exclude any files from the commit - even if they're unrelated
-- leave uncommitted changes in the working directory
-- ask the user which files to commit - commit everything
-
-## Execute
-
-Execute the workflow now.

package/plugins/lisa/skills/git-commit/agents/openai.yaml

@@ -1,4 +0,0 @@
-display_name: "Git Commit"
-short_description: "creating conventional commits for current changes"
-default_prompt:
-  - "Use $git-commit: creating conventional commits for current changes."

package/plugins/lisa/skills/git-prune/SKILL.md

@@ -1,35 +0,0 @@
----
-name: git-prune
-description: This skill should be used when pruning local branches that have been deleted on the remote. It fetches remote changes, identifies stale local branches, and safely deletes them.
-allowed-tools: ["Bash"]
----
-
-# Git Prune Local Branches
-
-Remove local branches whose upstream tracking branches have been deleted on remote.
-
-## Workflow
-
-### Fetch and prune remote-tracking references
-
-!git fetch --prune
-
-### Find and delete stale local branches
-
-!git branch -vv | grep ': gone]' | awk '{print $1}'
-
-### Apply these requirements
-
-1. **Preview**: Show which branches will be deleted before deleting
-2. **Safe Delete**: Use `-d` (safe delete) which refuses to delete unmerged branches
-3. **Report**: Show summary of deleted branches
-
-### Never
-
-- Force delete (`-D`) without user confirmation
-- Delete the current branch
-- Delete protected branches (dev, staging, main)
-
-## Execute
-
-Execute the workflow now.

package/plugins/lisa/skills/git-prune/agents/openai.yaml

@@ -1,4 +0,0 @@
-display_name: "Git Prune"
-short_description: "pruning local branches that have been deleted on the remote"
-default_prompt:
-  - "Use $git-prune: pruning local branches that have been deleted on the remote."

package/plugins/lisa/skills/git-submit-pr/SKILL.md

@@ -1,113 +0,0 @@
----
-name: git-submit-pr
-description: This skill should be used when pushing changes and creating or updating a pull request. It verifies the branch state, pushes to remote, creates or updates a PR with a comprehensive description, optionally coordinates the resulting Pull Request into the configured GitHub ProjectV2, and enables auto-merge.
-allowed-tools: ["Bash", "Skill", "mcp__github__create_pull_request", "mcp__github__get_pull_request", "mcp__github__update_pull_request"]
----
-
-# Submit Pull Request Workflow
-
-Push current branch and create or update a pull request. Optional hint: $ARGUMENTS
-
-Recognized optional hints:
-
-- `work_item_ref=<ref>` — source tracker item for native development linkage. Examples: `CodySwannGT/lisa#614`, `https://github.com/CodySwannGT/lisa/issues/614`, `ENG-123`, `PROJ-456`.
-- `target_branch=<branch>` or `base=<branch>` — intended PR base branch, used to decide whether a GitHub closing keyword is safe.
-- `tracker_provider=<github|linear|jira|none>` — explicit provider when the ref shape is ambiguous.
-- `pr_url=<url>` — live pull request URL, only needed when updating tracker backlinks from an existing PR context.
-
-## Workflow
-
-### Check current state
-
-!git status
-!git log --oneline -10
-
-### Apply these requirements
-
-1. **Branch Check**: Verify not on `dev`, `staging`, or `main` (cannot create PR from protected branches)
-2. **Commit Check**: Ensure all changes are committed before pushing
-3. **Push**: Push current branch to remote with `-u` flag and the following environment variable - GIT_SSH_COMMAND="ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=5"
-4. **PR Management**:
-   - Check for existing PR on this branch
-   - If exists: Update description with latest changes
-   - If not: Create PR with comprehensive description (not a draft)
-   - Include native development linkage for the source work item when `work_item_ref` can be inferred from `$ARGUMENTS`, the current branch name, an existing PR body, or the issue/ticket context passed by the caller.
-   - After the PR exists, ensure the source work item has a backlink to the PR: invoke `lisa:tracker-sync` with the work item, milestone `pr-ready`, the live `pr_url`, and `tracker_provider` when known. This makes ticket -> PR linkage mandatory, not just a best-effort milestone comment.
-   - After the PR exists, re-resolve the live Pull Request node id and, when `github.projects.v2` is enabled, invoke `lisa:github-project-v2` with `operation: ensure-item` and `content_node_id: <pull-request-node-id>` so linked pull requests join the configured shared Project without replacing the PR as the durable review/merge surface.
-5. **Auto-merge**: Choose merge strategy by PR type:
-   - **Promotion PRs** (env → env, e.g. `dev` → `staging`): use `gh pr merge --auto --merge` (never squash). Squashing flattens the constituent `chore(release): X.Y.Z [skip ci]` commits into one commit titled with the PR title, stripping the `[skip ci]` markers and breaking the release workflow's promotion-detection regex — the destination branch then double-bumps its version. `--merge` keeps each `chore(release)` commit (and its `[skip ci]` marker) intact under a clean merge commit subject the workflow can recognize.
-   - **Feature PRs** (anything → `dev`): use `gh pr merge --auto --merge`.
-6. **Drive to merge**: Opening the PR and enabling auto-merge is not terminal. Delegate the full mergeability loop to the `drive-pr-to-merge` skill — invoke it with the PR number and `merge_method=merge` (and `verify_commit=<pushed head sha>` for the ancestry check). That skill is the single source of truth for clearing every blocker: auto-merge with direct-merge fallback, `BEHIND` re-sync, conflict resolution, failing-check fixes, human + bot (CodeRabbit) review-comment handling with GraphQL thread resolution, stale `CHANGES_REQUESTED` dismissal, and post-merge ancestry verification. It runs inline and uses plain `gh`/`git` so Claude and Codex behave identically. Do not re-implement the loop here.
-
-### Native Development Linkage
-
-Add provider-appropriate linkage to the PR title and/or body without changing the status lifecycle:
-
-- **GitHub Issues**:
-  - If `work_item_ref` is a GitHub issue URL, `org/repo#<n>`, or `#<n>`, add a dedicated issue reference line to the PR body.
-  - Use a closing keyword such as `Closes #<n>` only when merging this PR to the base branch represents terminal delivery for that issue. This is true when the target branch is the repository default branch or the configured production branch from `.lisa.config.json` `deploy.branches.production`.
-  - If the target branch is a non-terminal environment branch such as `dev` or `staging`, use a non-closing reference such as `Refs #<n>` so GitHub links the PR in the issue's Development / linked pull requests surface without prematurely closing the issue.
-  - For cross-repo issue refs, use the fully qualified form, for example `Closes CodySwannGT/lisa#614` or `Refs CodySwannGT/lisa#614`.
-- **Linear**:
-  - Ensure the Linear issue identifier appears in the branch name when the branch is created upstream by `lisa:implement`.
-  - Include the identifier in the PR title or body, for example `Linear: ENG-123`, so Linear's GitHub integration can attach the PR.
-- **JIRA**:
-  - Ensure the JIRA issue key appears in the branch name when the branch is created upstream by `lisa:implement`.
-  - Include the key in the PR title or body, for example `JIRA: PROJ-456`, so the GitHub-JIRA integration can attach the PR.
-- **No supported provider**: Skip this section without error; do not invent references.
-
-When updating an existing PR, preserve any existing linkage line unless the new `work_item_ref` is more specific. Do not duplicate equivalent references.
-
-### Work Item Backlink
-
-After creating or updating the PR, always make the reverse link durable on the source work item when `work_item_ref` is available:
-
-1. Resolve the live PR URL with `gh pr view <pr-number> --json url --jq .url`.
-2. Invoke `lisa:tracker-sync` with the original work item ref, milestone `pr-ready`, `pr_url=<url>`, and `tracker_provider=<provider>` when known.
-3. The vendor sync skill must prefer the provider's native development-link primitive where one is available and verifiable.
-4. If native linkage is unavailable, unconfigured, or cannot be verified, the vendor sync skill must create or update a single managed `[lisa-pr-link]` comment on the work item containing the PR URL. The fallback comment is not optional; it is the ticket-side half of the two-way link.
-5. When the PR later merges, invoke `lisa:tracker-sync` again with milestone `pr-merged`, the same `pr_url`, and the merge SHA when available, so the managed backlink reflects the final state.
-
-Do not report PR submission as fully synced while the PR body references the ticket but the ticket has neither a verified native PR link nor the managed backlink comment.
-
-### GitHub ProjectV2 Coordination
-
-After PR creation or update, resolve the live Pull Request node id:
-
-```bash
-gh pr view <pr-number> --json id,url --jq '{ id, url }'
-```
-
-When `github.projects.v2` is enabled, delegate membership to `lisa:github-project-v2`:
-
-```text
-operation: ensure-item
-content_node_id: <pull-request-node-id>
-```
-
-Branch on the shared utility outcome exactly as GitHub Issue writers do:
-
-- `outcome: disabled` — no Project configured; continue normally.
-- `outcome: added` or `outcome: reused` — PR membership is now present; continue normally.
-- `outcome: warning` with `required: false` — preserve the exact Project error, keep the underlying PR creation/update as the durable success, and continue the normal auto-merge/watch flow.
-- `outcome: blocked` with `required: true` — surface the exact Project failure and treat the submit flow as blocked even if the PR already exists, so operators can fix Project access/config before reporting full success.
-
-Never inline separate `gh api graphql` ProjectV2 mutations here. All Pull Request membership coordination goes through `lisa:github-project-v2` so linked-PR flows and Issue writers stay in parity.
-
-### PR Description Format
-
-Include in the PR description:
-
-- **Summary**: Brief overview of changes (1-3 bullet points)
-- **Test plan**: How to verify the changes work correctly
-- **Issue / Tracker link**: The provider-specific native linkage line when a source work item is available, placed after the summary and before the test plan.
-
-### Never
-
-- use `--force` push without explicit user request
-- create PR from protected branches (dev, staging, main)
-- skip pushing before PR creation
-
-## Execute
-
-Execute the workflow now.

package/plugins/lisa/skills/git-submit-pr/agents/openai.yaml

@@ -1,4 +0,0 @@
-display_name: "Git Submit PR"
-short_description: "pushing changes and creating or updating a pull request"
-default_prompt:
-  - "Use $git-submit-pr: pushing changes and creating or updating a pull request."

package/plugins/lisa/skills/github-add-journey/SKILL.md

@@ -1,115 +0,0 @@
----
-name: github-add-journey
-description: "Add a Validation Journey section to an existing GitHub Issue by analyzing the change type and generating appropriate verification steps with evidence markers. The GitHub counterpart of lisa:jira-add-journey."
-allowed-tools: ["Bash", "Skill"]
----
-
-# Add Validation Journey to Existing GitHub Issue
-
-Read an existing GitHub Issue, analyze the change type, and append a `## Validation Journey` markdown section with appropriate verification steps based on the project's verification patterns.
-
-## Arguments
-
-`$ARGUMENTS`: `<ISSUE_REF>`
-
-- `ISSUE_REF` (required): GitHub issue ref — `org/repo#<number>` or full GitHub issue URL.
-
-## Prerequisites
-
-- `gh` CLI authenticated (`gh auth status`).
-
-## Workflow
-
-### Step 1: Read the Issue
-
-```bash
-gh issue view <number> --repo <org>/<repo> --json number,title,body,labels,assignees,milestone,url
-```
-
-Extract: title, body, type (from `type:` label), components (from `component:` labels), assignees, linked PRs.
-
-### Step 2: Check for Existing Journey
-
-Parse the body for an existing `## Validation Journey` heading. If present and the section contains at least one `[EVIDENCE: <name>]` marker, the issue already has a journey — report this to the user and stop.
-
-### Step 3: Analyze the Change Type
-
-Examine the body, acceptance criteria, and codebase to determine the change type:
-
-1. **API/GraphQL changes** — New or modified endpoints, request/response schemas
-2. **Database migration** — Schema changes, new tables/columns, indexes
-3. **Background job/queue** — New job processors, queue consumers, event handlers
-4. **Library/utility** — Exported functions, shared modules, npm package changes
-5. **Security fix** — Auth, authorization, input validation, OWASP vulnerabilities
-6. **Authentication/authorization** — Role-based access, session management, tokens
-
-Use Explore agents or read the codebase directly to understand which files are affected.
-
-### Step 4: Map Change Type to Verification Pattern
-
-| Change Type | Verification Approach |
-|---|---|
-| API/GraphQL | curl commands verifying endpoints, status codes, response schemas |
-| Database migration | Migration execution + schema verification + rollback check |
-| Background job/queue | Enqueue + process + state change verification |
-| Library/utility | Test execution + build verification + export check |
-| Security fix | Exploit reproduction pre-fix + exploit failure post-fix |
-| Auth/authz | Multi-role verification with explicit status codes |
-
-### Step 5: Draft the Validation Journey
-
-Compose the journey with `[EVIDENCE: name]` markers at key verification points:
-
-```markdown
-## Validation Journey
-
-### Prerequisites
-- List required services, database, env vars
-
-### Steps
-1. Verify current state before changes
-2. Apply the change
-3. Verify expected new state [EVIDENCE: state-name]
-4. Test error/edge cases [EVIDENCE: error-case]
-5. Verify rollback if applicable [EVIDENCE: rollback]
-
-### Assertions
-- Describe what must be true after verification
-```
-
-### Guidelines for Drafting
-
-1. **2–5 evidence markers** — Focus on proving the change works and handles errors.
-2. **Concrete, runnable steps** — `Run \`curl -s localhost:3000/health | jq .status\`` not "Check the endpoint".
-3. **Include environment setup** — Database connection, running services, env vars.
-4. **Evidence names in kebab-case** — `api-response`, `schema-check`, `rate-limit-hit`.
-5. **Assertions are measurable** — `Returns 200 with {status: ok}` not "API works correctly".
-6. **Cover happy path AND error path** — At minimum, one success and one failure marker.
-7. **On a leaf work unit, the markers are binding** — For a Bug / Task / Sub-task / Improvement, every `[EVIDENCE: name]` here is the issue's evidence manifest: validation gate S14 requires at least one, and the issue cannot be closed until each named artifact is captured and attached (see the "Per-Work-Unit Evidence Contract" in the `verification` rule). Name only evidence you intend to capture — and name all of it.
-
-### Step 6: Present to User for Approval
-
-Display the drafted Validation Journey and ask for confirmation before appending it to the issue body. (If invoked from a parent skill running unattended — e.g., `lisa:github-write-issue` Phase 6 step 5 — proceed without the prompt.)
-
-### Step 7: Append to Issue Body
-
-After approval:
-
-```bash
-current_body=$(gh issue view <number> --repo <org>/<repo> --json body --jq '.body')
-# Compose new body: existing + "\n\n## Validation Journey\n..." (or replace if present)
-gh issue edit <number> --repo <org>/<repo> --body-file /tmp/updated-body.md
-```
-
-Preserve every other section verbatim — never re-render the body from parsed fields, since the issue may carry `extra_sections` we don't recognize.
-
-### Step 8: Verify
-
-Re-read the issue and confirm the `## Validation Journey` section is present and includes at least one `[EVIDENCE: <name>]` marker.
-
-## When to Use This Skill
-
-- Issue was created before the Validation Journey convention was established.
-- Issue was created manually without following `lisa:github-create` guidelines.
-- Issue needs a journey added or updated based on implementation progress.
-- Before starting work on an issue, to ensure verification steps are documented.

package/plugins/lisa/skills/github-add-journey/agents/openai.yaml

@@ -1,4 +0,0 @@
-display_name: "Github Add Journey"
-short_description: "Add a Validation Journey section to an existing GitHub Issue by analyzing the change type and generating appropriate verification steps…"
-default_prompt:
-  - "Use $github-add-journey: Add a Validation Journey section to an existing GitHub Issue by analyzing the change type and generating appropriate verification steps…."