@codyswann/lisa 2.23.2 → 2.25.0

package/.claude-plugin/marketplace.json

@@ -43,6 +43,12 @@
       "source": "./plugins/lisa-rails",
       "description": "Ruby on Rails skills, rules, and conventions",
       "category": "productivity"
+    },
+    {
+      "name": "lisa-wiki",
+      "source": "./plugins/lisa-wiki",
+      "description": "LLM Wiki — git-native markdown knowledge base: ingest, query, lint, onboard (Claude + Codex)",
+      "category": "productivity"
     }
   ]
 }

package/package.json

@@ -82,7 +82,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.23.2",
+  "version": "2.25.0",
   "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.23.2",
+  "version": "2.25.0",
   "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.23.2",
+  "version": "2.25.0",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/commands/setup/github.md

@@ -0,0 +1,7 @@
+---
+description: "Set up GitHub Issues as the tracker and/or PRD source for this project. Verifies the gh CLI, resolves org/repo, scaffolds the `status:*` (build) and/or `prd-*` (PRD) label namespaces, writes the `github` section of `.lisa.config.json`, and offers to set top-level `tracker: \"github\"` / `source: \"github\"`. No /lisa:setup:atlassian prerequisite."
+allowed-tools: ["Skill"]
+argument-hint: "[--repo=<org/repo>]"
+---
+
+Use the /lisa:setup-github skill to configure GitHub as the tracker and/or PRD source. $ARGUMENTS

package/plugins/lisa/commands/setup/linear.md

@@ -0,0 +1,7 @@
+---
+description: "Set up Linear as the tracker and/or PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in keychain), resolves the workspace slug and team key, scaffolds the `status:*` issue-label (build) and/or `prd-*` project-label (PRD) namespaces, writes the `linear` section of `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` / `source: \"linear\"`. No /lisa:setup:atlassian prerequisite."
+allowed-tools: ["Skill"]
+argument-hint: "[--workspace=<slug>] [--team=<KEY>]"
+---
+
+Use the /lisa:setup-linear skill to configure Linear as the tracker and/or PRD source. $ARGUMENTS

package/plugins/lisa/skills/setup-github/SKILL.md

@@ -0,0 +1,199 @@
+---
+name: setup-github
+description: "Configure GitHub Issues as the destination tracker and/or the PRD source for this project. Verifies the gh CLI is installed and authenticated, resolves `org/repo`, scaffolds the build-queue label namespace (`status:*`) when GitHub is the tracker and/or the PRD-lifecycle label namespace (`prd-*` + sentinel) when GitHub is the PRD source, writes the `github` section into `.lisa.config.json`, and offers to set top-level `tracker: \"github\"` and/or `source: \"github\"`. Idempotent — re-running updates the existing section and reuses existing labels rather than duplicating. No /lisa:setup:atlassian prerequisite (GitHub auth is standalone)."
+allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill", "AskUserQuestion"]
+---
+
+# Setup GitHub: $ARGUMENTS
+
+Make GitHub Issues a tracker, a PRD source, or both for this project. After this skill, `.lisa.config.json` contains `github.org` + `github.repo`, the configured repo carries the lifecycle label namespaces lisa needs, and (optionally) `tracker` / `source` point at GitHub.
+
+Unlike `setup-jira` / `setup-confluence`, this skill has **no `setup-atlassian` dependency** — GitHub auth runs through the `gh` CLI directly.
+
+## Workflow
+
+### Step 0 — Decide what GitHub is for
+
+Ask via `AskUserQuestion` (multiSelect):
+
+> What should lisa use this GitHub repo for?
+>
+> 1. **Destination tracker** — lisa writes Epics / Stories / Sub-tasks here as Issues, and the build queue (`/lisa:intake`, `/lisa:implement`) runs off the `status:*` label namespace. Sets `tracker: "github"`.
+> 2. **PRD source** — humans drop PRDs here as Issues labeled `prd-ready`; `/lisa:intake` scans and ticketes them off the `prd-*` label namespace. Sets `source: "github"`.
+
+The answer drives which label namespaces get scaffolded in Step 3: **tracker → `status:*`**, **source → `prd-*` + sentinel**. Self-host (both) is supported — the two namespaces never overlap (see the `config-resolution` rule's "Self-host edge case").
+
+If the user selects neither, stop — there's nothing to configure.
+
+### Step 1 — Ensure the gh CLI is installed and authenticated
+
+```bash
+if ! command -v gh >/dev/null 2>&1; then
+  if command -v brew >/dev/null 2>&1; then
+    brew install gh
+  else
+    cat >&2 <<'EOF'
+Error: gh (GitHub CLI) not found and Homebrew unavailable. Install it:
+  https://github.com/cli/cli#installation
+Then re-run /lisa:setup:github.
+EOF
+    exit 1
+  fi
+fi
+
+# Auth: prefer an interactive login; CI/headless uses GH_TOKEN.
+if ! gh auth status >/dev/null 2>&1; then
+  if [ -n "$GH_TOKEN" ] || [ -n "$GITHUB_TOKEN" ]; then
+    echo "gh not logged in interactively, but GH_TOKEN/GITHUB_TOKEN is set — gh will use it."
+  else
+    cat >&2 <<'EOF'
+Error: gh is not authenticated. Run:
+  gh auth login           # interactive (developer machines)
+or set GH_TOKEN as a secret (CI / headless), then re-run /lisa:setup:github.
+EOF
+    exit 1
+  fi
+fi
+```
+
+Confirm the authenticated identity can write Issues and labels — `gh auth status` shows the token scopes; `repo` scope (or fine-grained Issues: read-write + metadata: read) is required to create labels and issues. If the scopes look read-only, surface it and instruct `gh auth refresh -s repo`.
+
+### Step 2 — Resolve `org/repo`
+
+Honor any `--repo=org/repo` argument. Otherwise default-detect from the current repo's `origin` remote, then confirm — the tracker/PRD repo is frequently a *different* repo than the code repo (e.g. a dedicated `product-prds` repo):
+
+```bash
+DEFAULT_REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner 2>/dev/null)
+```
+
+Present the detected value via `AskUserQuestion`:
+
+> Use `<DEFAULT_REPO>` as the GitHub repo for lisa's issues/PRDs, or specify a different `org/repo`?
+
+Once resolved, split into `ORG` and `REPO` and confirm reachability + write access:
+
+```bash
+gh repo view "$ORG/$REPO" --json name,viewerPermission \
+  --jq 'if (.viewerPermission | IN("ADMIN","MAINTAIN","WRITE")) then "ok" else error("insufficient permission: \(.viewerPermission)") end'
+```
+
+If permission is `READ` / `TRIAGE`, stop — lisa cannot create labels or issues. Surface and exit.
+
+### Step 3 — Scaffold the lifecycle label namespaces
+
+Read role → label mappings with the same default-fallback ladder the intake skills use, so the labels created here exactly match what they look for. Only the namespaces selected in Step 0 are scaffolded.
+
+```bash
+read_role() {  # $1=namespace (build|prd) $2=role $3=default
+  local ns="$1" role="$2" default="$3" local_v global_v
+  local_v=$(jq -r ".github.labels.${ns}.${role} // empty" .lisa.config.local.json 2>/dev/null)
+  global_v=$(jq -r ".github.labels.${ns}.${role} // empty" .lisa.config.json 2>/dev/null)
+  echo "${local_v:-${global_v:-$default}}"
+}
+
+# Idempotent label creator: create if missing, leave untouched if present.
+ensure_label() {  # $1=name $2=hex-color $3=description
+  local name="$1" color="$2" desc="$3"
+  if gh label list --repo "$ORG/$REPO" --limit 200 --json name --jq '.[].name' | grep -qxF "$name"; then
+    echo "  = $name (exists)"
+  else
+    gh label create "$name" --repo "$ORG/$REPO" --color "$color" --description "$desc" \
+      && echo "  + $name (created)"
+  fi
+}
+```
+
+#### 3a. Build-queue labels (only if GitHub is the tracker)
+
+Defaults from `config-resolution`. The `done` role is **env-keyed** — create all three by default; a project whose terminal state is env-independent can later collapse `github.labels.build.done` to a single string.
+
+```bash
+ensure_label "$(read_role build ready    status:ready)"        FBCA04 "Ready for build (human signal)"
+ensure_label "$(read_role build claimed  status:in-progress)"  0E8A16 "Build in progress (agent owns)"
+ensure_label "$(read_role build review   status:code-review)"  5319E7 "PR open, awaiting review"
+ensure_label "$(read_role build blocked  status:blocked)"      D93F0B "Blocked — human attention required"
+ensure_label "$(read_role build done.dev        status:on-dev)" 1D76DB "Deployed to dev"
+ensure_label "$(read_role build done.staging    status:on-stg)" 1D76DB "Deployed to staging"
+ensure_label "$(read_role build done.production status:done)"   0E8A16 "Shipped to production"
+```
+
+#### 3b. PRD-lifecycle labels (only if GitHub is the PRD source)
+
+```bash
+ensure_label "$(read_role prd draft     prd-draft)"            C5DEF5 "PRD in progress (product owns)"
+ensure_label "$(read_role prd ready     prd-ready)"            FBCA04 "PRD ready for ticketing"
+ensure_label "$(read_role prd in_review prd-in-review)"        5319E7 "Claude is reviewing this PRD"
+ensure_label "$(read_role prd blocked   prd-blocked)"          D93F0B "PRD blocked — see comments"
+ensure_label "$(read_role prd ticketed  prd-ticketed)"         0E8A16 "Tickets created — see comments"
+ensure_label "$(read_role prd shipped   prd-shipped)"          1D76DB "Work delivered (product owns)"
+ensure_label "$(read_role prd sentinel  prd-intake-feedback)"  EDEDED "Marker for PRD-intake feedback issues"
+```
+
+#### 3c. Handle name collisions / renames
+
+If a project already uses a differently-named label for a role (e.g. `ready-for-dev` instead of `status:ready`), do NOT create a duplicate. Present the repo's existing labels via `AskUserQuestion` and let the user map the role to the existing label — that mapping becomes an override written in Step 4. Renaming-in-place (keeping lisa's defaults) is also fine if the user prefers; just surface the choice.
+
+### Step 4 — Write `.lisa.config.json`
+
+`github.org` / `github.repo` are project-wide → committed. Write **only label keys that differ from the documented defaults** — never echo the full default map into config (keeps it lean; missing keys inherit defaults at runtime).
+
+```bash
+touch .lisa.config.json
+[ -s .lisa.config.json ] || echo '{}' > .lisa.config.json
+
+jq --arg org "$ORG" --arg repo "$REPO" \
+   '.github = ((.github // {}) | .org = $org | .repo = $repo)' \
+   .lisa.config.json > .lisa.config.json.tmp && mv .lisa.config.json.tmp .lisa.config.json
+
+# Conditionally write label overrides (only roles the user mapped to non-default names).
+# $LABEL_OVERRIDES_JSON is e.g. {"build":{"ready":"ready-for-dev"}} — {} if all defaults.
+if [ -n "$LABEL_OVERRIDES_JSON" ] && [ "$LABEL_OVERRIDES_JSON" != "{}" ]; then
+  jq --argjson o "$LABEL_OVERRIDES_JSON" \
+     '.github.labels = ((.github.labels // {}) * $o)' \
+     .lisa.config.json > .lisa.config.json.tmp && mv .lisa.config.json.tmp .lisa.config.json
+fi
+```
+
+No secrets go in config — the GitHub token lives in `gh`'s own store (`~/.config/gh/`) or the `GH_TOKEN` env var, never in `.lisa.config.json`.
+
+### Step 5 — Offer to set top-level `tracker` / `source`
+
+For each role selected in Step 0, offer the matching top-level flag (skip if already set to GitHub).
+
+If **tracker** was selected and `.tracker` is unset or not `"github"`, ask via `AskUserQuestion`:
+
+> Repo `<org>/<repo>` configured. Set top-level `tracker: "github"` so all vendor-neutral skills write Issues here?
+
+If yes: `jq '.tracker = "github"' ...`
+
+If **source** was selected and `.source` is unset or not `"github"`, ask:
+
+> Set top-level `source: "github"` so `/lisa:intake` (with no args) scans this repo for `prd-ready` PRDs?
+
+If yes: `jq '.source = "github"' ...`
+
+Both are project-wide switches that change every downstream skill's default — never set either without explicit confirmation.
+
+### Step 6 — Verify
+
+```bash
+jq -e '.github.org and .github.repo' .lisa.config.json >/dev/null
+gh label list --repo "$ORG/$REPO" --limit 200 --json name --jq '.[].name' \
+  | grep -E 'status:|prd-' || true   # show the scaffolded namespaces
+```
+
+Report success with the resolved `org/repo`, which label namespaces were scaffolded (and which labels already existed vs. were created), any non-default label overrides written, and whether `tracker` / `source` were set. Direct the user to `/lisa:intake` to test.
+
+## Idempotency
+
+- Re-running merges the `github` section's fields rather than appending — `jq` merge semantics throughout.
+- `ensure_label` is find-or-create: existing labels are left exactly as they are (color/description not overwritten), so a re-run never churns labels a human customized.
+- Re-running does not re-prompt for `tracker` / `source` if they already point at GitHub.
+
+## Rules
+
+- Never write the GitHub token to `.lisa.config.json`. It stays in `gh`'s store or `GH_TOKEN`.
+- Never create a duplicate label for a role that already has a (differently-named) label — map the role to the existing label and record it as a config override instead.
+- Never overload one label across both the PRD and build namespaces — a single issue is either a PRD or a build ticket, never both (see `config-resolution`).
+- Never set `tracker` / `source` without explicit user confirmation — they're project-wide and switch every downstream skill's behavior.
+- Never invent an `org/repo`. Default-detect from the remote and confirm; if detection fails, ask the user to supply it.

package/plugins/lisa/skills/setup-linear/SKILL.md

@@ -0,0 +1,217 @@
+---
+name: setup-linear
+description: "Configure Linear as the destination tracker and/or the PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in OS keychain), resolves the workspace slug and team key, scaffolds the build-queue issue-label namespace (`status:*`) when Linear is the tracker and/or the PRD-lifecycle project-label namespace (`prd-*` + issue-level sentinel) when Linear is the PRD source, writes the `linear` section into `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` and/or `source: \"linear\"`. Idempotent — re-running updates the existing section and reuses existing labels. No /lisa:setup:atlassian prerequisite."
+allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill", "AskUserQuestion", "mcp__linear-server__authenticate", "mcp__linear-server__complete_authentication", "mcp__linear-server__list_teams", "mcp__linear-server__list_issue_labels", "mcp__linear-server__create_issue_label", "mcp__linear-server__list_project_labels", "mcp__linear-server__create_project_label"]
+---
+
+# Setup Linear: $ARGUMENTS
+
+Make Linear a tracker, a PRD source, or both for this project. After this skill, `.lisa.config.json` contains `linear.workspace` (+ `linear.teamKey` when Linear is the tracker), the team carries the lifecycle label namespaces lisa needs, and (optionally) `tracker` / `source` point at Linear.
+
+Linear's data model splits labels into two **kinds** that matter here: **issue labels** (drive the build queue, `status:*`) and **project labels** (drive the PRD lifecycle, `prd-*`). They are distinct namespaces in Linear and are NOT interchangeable — the build lifecycle lives on Issues, the PRD lifecycle lives on Projects. The sentinel feedback marker is an **issue** label even though it belongs to the PRD flow (Linear's MCP has no project-level comments — see `linear-prd-intake`).
+
+## Workflow
+
+### Step 0 — Pick a setup path AND what Linear is for
+
+Ask two things via `AskUserQuestion`.
+
+**Access path:**
+
+> How should lisa talk to Linear for this project?
+>
+> 1. **MCP-only (simplest)** — authenticate the Linear MCP once via browser OAuth; lisa uses it for every operation. Best for single-workspace developers on a personal laptop.
+> 2. **MCP + API key (recommended for teams)** — MCP for interactive dev, a personal API key in keychain for headless / CI. Continue through key-store steps.
+> 3. **API-key-only (headless / CI)** — store a personal API key in the OS keychain; lisa uses curl against the Linear GraphQL API. Best for pipelines / containers.
+
+**Role** (multiSelect):
+
+> What should lisa use Linear for?
+>
+> 1. **Destination tracker** — lisa writes Epics→Projects, Stories→Issues, Sub-tasks→Sub-issues; the build queue runs off the `status:*` issue-label namespace. Sets `tracker: "linear"`. (Requires a team key.)
+> 2. **PRD source** — humans flag Linear **projects** with `prd-ready`; `/lisa:intake` scans and ticketes them off the `prd-*` project-label namespace. Sets `source: "linear"`.
+
+The role answer drives Step 3 (which label namespaces to scaffold) and whether `teamKey` is required (tracker → yes).
+
+### Step 1 — Establish Linear access
+
+#### MCP path (1 or 2)
+
+Verify the Linear MCP is authenticated to the right workspace by listing teams:
+
+```text
+mcp__linear-server__list_teams({})
+```
+
+If it errors / returns nothing, run `mcp__linear-server__authenticate` and have the user complete OAuth in the browser, then `mcp__linear-server__complete_authentication`, then re-list. A non-empty team list confirms the MCP is authed to a readable workspace.
+
+#### API-key path (2 or 3)
+
+Linear personal API keys are created at **Linear → Settings → Security & access → Personal API keys** (or `https://linear.app/<workspace>/settings/account/security`). Store the key in the OS keychain keyed by the workspace slug, using the clipboard-pipe pattern (key never enters chat), mirroring `setup-notion`:
+
+```bash
+case "$(uname -s)" in
+  Darwin)
+    cat <<EOF
+1. Copy the Linear API key (starts with 'lin_api_').
+2. Run this single line (leading space keeps it out of zsh history):
+
+    security delete-generic-password -s lisa-linear -a "$WORKSPACE" 2>/dev/null;  TOK="\$(pbpaste)"; security add-generic-password -U -s lisa-linear -a "$WORKSPACE" -w "\$TOK"; unset TOK
+EOF
+    ;;
+  Linux)
+    cat <<EOF
+secret-tool clear service lisa-linear account "$WORKSPACE" 2>/dev/null; printf '%s' "\$(wl-paste 2>/dev/null || xclip -selection clipboard -o 2>/dev/null || xsel --clipboard --output 2>/dev/null)" | secret-tool store --label="Lisa Linear ($WORKSPACE)" service lisa-linear account "$WORKSPACE"
+(no clipboard tool? the command reads stdin — paste, then Ctrl-D. Or env-var fallback: export LINEAR_API_KEY_$(echo "$WORKSPACE" | tr '[:upper:]-' '[:lower:]_')="<key>")
+EOF
+    ;;
+  MINGW*|MSYS*|CYGWIN*)
+    cat <<EOF
+PowerShell: \$tok = Get-Clipboard; cmdkey /generic:"lisa-linear-$WORKSPACE" /user:"$WORKSPACE" /pass:"\$tok"; Remove-Variable tok
+EOF
+    ;;
+esac
+```
+
+**Never accept the key via this skill's chat or stdin.** After the user confirms storage, retrieve via the lookup ladder (env → workspace-suffixed env → keychain) and validate against the GraphQL API:
+
+```bash
+read_linear_key() {  # $1=workspace slug
+  local ws="$1"
+  [ -n "$LINEAR_API_KEY" ] && { echo "$LINEAR_API_KEY"; return; }
+  local slug; slug=$(echo "$ws" | tr '[:upper:]-' '[:lower:]_')
+  local varname="LINEAR_API_KEY_${slug}"
+  [ -n "${!varname}" ] && { echo "${!varname}"; return; }
+  case "$(uname -s)" in
+    Darwin)  security find-generic-password -s lisa-linear -a "$ws" -w 2>/dev/null ;;
+    Linux)   command -v secret-tool >/dev/null && secret-tool lookup service lisa-linear account "$ws" 2>/dev/null ;;
+    MINGW*|MSYS*|CYGWIN*) cmdkey /list:"lisa-linear-${ws}" 2>/dev/null | grep Password | awk '{print $NF}' ;;
+  esac
+}
+
+KEY=$(read_linear_key "$WORKSPACE")
+[ -z "$KEY" ] && { echo "Error: key not retrievable from any source. Re-run the store step." >&2; exit 1; }
+
+# Validate: viewer query. Personal API keys go in the Authorization header verbatim (no 'Bearer').
+VIEWER=$(curl -s -X POST https://api.linear.app/graphql \
+  -H "Authorization: $KEY" -H "Content-Type: application/json" \
+  -d '{"query":"{ viewer { id name } organization { urlKey name } }"}')
+if ! echo "$VIEWER" | jq -e '.data.viewer.id' >/dev/null 2>&1; then
+  echo "Error: API key failed the Linear viewer probe. Response: $VIEWER" >&2
+  exit 1
+fi
+echo "Linear key validated. Org: $(echo "$VIEWER" | jq -r '.data.organization.urlKey')"
+```
+
+### Step 2 — Resolve workspace slug + team key
+
+- **Workspace slug**: honor `--workspace=<slug>`. Otherwise derive from the validated identity — the GraphQL `organization.urlKey` (API path) or the team list's workspace (MCP path). Confirm with the user; this slug is the keychain `account` key and the multi-workspace disambiguator.
+- **Team key** (required when Linear is the **tracker**): honor `--team=<KEY>`. Otherwise enumerate teams via `mcp__linear-server__list_teams({})` (or the GraphQL `teams` query) and present them via `AskUserQuestion` (label = team key, description = team name) for the user to pick the team that owns lisa's destination Issues. If Linear is source-only, `teamKey` is optional — skip unless the user wants to pin a team scope.
+
+### Step 3 — Scaffold the lifecycle label namespaces
+
+Read role → label with the default-fallback ladder the intake skills use, so scaffolded labels match exactly what they query.
+
+```bash
+read_role() {  # $1=namespace (build|prd) $2=role $3=default
+  local ns="$1" role="$2" default="$3" local_v global_v
+  local_v=$(jq -r ".linear.labels.${ns}.${role} // empty" .lisa.config.local.json 2>/dev/null)
+  global_v=$(jq -r ".linear.labels.${ns}.${role} // empty" .lisa.config.json 2>/dev/null)
+  echo "${local_v:-${global_v:-$default}}"
+}
+```
+
+#### 3a. Build-queue labels — ISSUE labels (only if Linear is the tracker)
+
+Probe with `mcp__linear-server__list_issue_labels` (scoped to the team). For each role's resolved name, create it via `mcp__linear-server__create_issue_label` only if absent. The `done` role is env-keyed — create all three defaults; collapse to a single string in config later if the project's terminal state is env-independent.
+
+| Role | Default | 
+|------|---------|
+| `ready` | `status:ready` |
+| `claimed` | `status:in-progress` |
+| `review` | `status:code-review` |
+| `blocked` | `status:blocked` |
+| `done.dev` | `status:on-dev` |
+| `done.staging` | `status:on-stg` |
+| `done.production` | `status:done` |
+
+#### 3b. PRD-lifecycle labels — PROJECT labels (only if Linear is the PRD source)
+
+Probe with `mcp__linear-server__list_project_labels`. Create missing ones via `mcp__linear-server__create_project_label`. These are a **separate label kind** from issue labels — creating an issue label of the same name will NOT work for the PRD flow.
+
+| Role | Default | Kind |
+|------|---------|------|
+| `draft` | `prd-draft` | project label |
+| `ready` | `prd-ready` | project label |
+| `in_review` | `prd-in-review` | project label |
+| `blocked` | `prd-blocked` | project label |
+| `ticketed` | `prd-ticketed` | project label |
+| `shipped` | `prd-shipped` | project label |
+| `sentinel` | `prd-intake-feedback` | **issue** label (marks the sentinel feedback issue — create via `create_issue_label`) |
+
+#### 3c. Handle name collisions / renames
+
+If the team already uses a differently-named label for a role, do not create a duplicate — present the existing labels via `AskUserQuestion`, map the role to the existing label, and record the mapping as a config override (Step 4).
+
+### Step 4 — Write `.lisa.config.json`
+
+`linear.workspace` (and `linear.teamKey` when tracker) are project-wide → committed. Write **only label keys that differ from defaults**.
+
+```bash
+touch .lisa.config.json
+[ -s .lisa.config.json ] || echo '{}' > .lisa.config.json
+
+jq --arg ws "$WORKSPACE" \
+   '.linear = ((.linear // {}) | .workspace = $ws)' \
+   .lisa.config.json > .lisa.config.json.tmp && mv .lisa.config.json.tmp .lisa.config.json
+
+# teamKey only when Linear is the tracker (or the user pinned a team scope).
+if [ -n "$TEAM_KEY" ]; then
+  jq --arg tk "$TEAM_KEY" '.linear.teamKey = $tk' \
+     .lisa.config.json > .lisa.config.json.tmp && mv .lisa.config.json.tmp .lisa.config.json
+fi
+
+# Conditionally write label overrides (only non-default role names).
+if [ -n "$LABEL_OVERRIDES_JSON" ] && [ "$LABEL_OVERRIDES_JSON" != "{}" ]; then
+  jq --argjson o "$LABEL_OVERRIDES_JSON" \
+     '.linear.labels = ((.linear.labels // {}) * $o)' \
+     .lisa.config.json > .lisa.config.json.tmp && mv .lisa.config.json.tmp .lisa.config.json
+fi
+```
+
+No secrets in config — the API key stays in keychain / `LINEAR_API_KEY`, the MCP session in its own store.
+
+### Step 5 — Offer to set top-level `tracker` / `source`
+
+For each role selected in Step 0, offer the matching top-level flag (skip if already pointing at Linear).
+
+If **tracker** selected and `.tracker` ≠ `"linear"`: ask "Set top-level `tracker: \"linear\"` so vendor-neutral skills write Issues here?" → `jq '.tracker = "linear"'`.
+
+If **source** selected and `.source` ≠ `"linear"`: ask "Set top-level `source: \"linear\"` so `/lisa:intake` (no args) scans this workspace for `prd-ready` projects?" → `jq '.source = "linear"'`.
+
+Both are project-wide — never set without explicit confirmation.
+
+### Step 6 — Verify
+
+```bash
+jq -e '.linear.workspace' .lisa.config.json >/dev/null
+# If tracker: also require teamKey.
+[ "$(jq -r '.tracker // empty' .lisa.config.json)" = "linear" ] && jq -e '.linear.teamKey' .lisa.config.json >/dev/null
+```
+
+Confirm the scaffolded labels are present (`list_issue_labels` for `status:*` + the sentinel; `list_project_labels` for `prd-*`). Report success with the resolved workspace, team key (if any), which namespaces were scaffolded (created vs. already existed), any non-default overrides, and whether `tracker` / `source` were set. Direct the user to `/lisa:intake` to test.
+
+## Idempotency
+
+- Re-running merges the `linear` section's fields rather than appending — `jq` merge throughout.
+- Label creation is find-or-create per kind; existing labels are left untouched, so re-runs never churn human-customized labels.
+- Re-running does not re-prompt for `tracker` / `source` if they already point at Linear. The keychain store in Step 1 is the user's manual action — they re-run the same `security` / `secret-tool` / `cmdkey` command.
+
+## Rules
+
+- Never write the API key to `.lisa.config.json`. It stays in keychain or `LINEAR_API_KEY`.
+- Never accept the API key via this skill's stdin/chat — always the platform clipboard-pipe pattern, so the value never enters the LLM context.
+- Never conflate the two label kinds: build labels are **issue** labels, PRD labels are **project** labels. The sentinel is an issue label. Creating the wrong kind silently breaks the corresponding intake flow.
+- Never create a duplicate label for a role that already has a (differently-named) label — map and record an override instead.
+- Never set `tracker` / `source` without explicit confirmation — they're project-wide switches.
+- Never invent a workspace slug or team key. Derive from the validated identity / team list and confirm; if resolution fails, ask the user.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.23.2",
+  "version": "2.25.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.23.2",
+  "version": "2.25.0",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.23.2",
+  "version": "2.25.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.23.2",
+  "version": "2.25.0",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.23.2",
+  "version": "2.25.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.23.2",
+  "version": "2.25.0",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.23.2",
+  "version": "2.25.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.23.2",
+  "version": "2.25.0",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.23.2",
+  "version": "2.25.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.23.2",
+  "version": "2.25.0",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.23.2",
+  "version": "2.25.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.23.2",
+  "version": "2.25.0",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -0,0 +1,8 @@
+{
+  "name": "lisa-wiki",
+  "version": "2.25.0",
+  "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
+  "author": {
+    "name": "Cody Swann"
+  }
+}

package/plugins/lisa-wiki/.codex-plugin/plugin.json

@@ -0,0 +1,32 @@
+{
+  "name": "lisa-wiki",
+  "version": "2.25.0",
+  "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
+  "author": {
+    "name": "Cody Swann"
+  },
+  "keywords": [
+    "wiki",
+    "knowledge-base",
+    "ingest",
+    "documentation",
+    "llm-wiki"
+  ],
+  "skills": "./skills/",
+  "interface": {
+    "displayName": "LLM Wiki",
+    "shortDescription": "LLM Wiki knowledge base",
+    "longDescription": "A config-driven, git-native LLM Wiki: ingest sources (git, PRs, project-scoped memory, Jira, Slack, docs, …) into durable markdown, query with citations, lint integrity, onboard users, absorb existing documentation, and scaffold domain-expert role subagents. Distributed for both Claude Code and Codex.",
+    "developerName": "Cody Swann",
+    "category": "Productivity",
+    "capabilities": [
+      "Interactive",
+      "Write"
+    ],
+    "defaultPrompt": [
+      "Onboard me to this project",
+      "Ingest the latest sources into the wiki",
+      "Query the wiki"
+    ]
+  }
+}